Docs · Behaviour

Modes: chat, fast, research and tasks

Four modes, one browser. They share the same tools and the same tab, and Chat will hand work to Research or Tasks when the job calls for it.

Pick a mode in the composer under the chat box, or let Chat choose. Switching modes does not move you to another browser or another profile: it changes how the model is asked to work.

ModeBest forModel callsStops and asks
ChatOne page, a question, a short jobOne per tool callWhen it is unsure
FastForms, search boxes, repeated clicksOne decision per stepOn a missing value
ResearchA question that needs several sourcesPer source and per roundNever: it reports gaps
TasksA goal that takes many stepsPer step, across subtasksFor logins, payments, CAPTCHAs

Chat

Chat is a full tool-calling agent for the tab you are looking at. It reads the page as numbered refs, clicks, types, takes screenshots and, when it has to, runs JavaScript. It shows every call it makes, so you can see which element it used.

  • Works with any provider you configure: Anthropic, OpenAI, OpenRouter, Gemini, Together, Groq, DeepSeek, Ollama, LM Studio or any OpenAI-compatible endpoint.
  • Hands a question that needs the web to Research, and a long job to Tasks, or you can turn either on yourself.
  • Can remember a fact you ask it to keep: your city, your units, which account you use on a site. A page cannot plant a memory; only your own message can.
  • Answers follow-up questions using the results already on screen, without starting over.

Fast (ultrafast)

Fast is built for the boring part: a search box, a date picker, a form with eight fields. Instead of a long conversation about what to do, the page becomes an indexed table of elements and the model answers one question: which operation, on which element.

page → indexed elements → ONE decision request → execute → observe
Fig. 01 one decision of the ultrafast loop step 01 / 05
Example search field
answer nothing read yet
observe 14 elements on screen
op —
target —
value —
01 observe · 14 elements
02 decision · pending
03 type · 0 chars
04 click [3] · ok
05 done · verified

A diagram of one step, rebuilt from the loop in docs/architecture.md. The model never writes selectors, coordinates or code: it picks an operation and an element index.

  • The model never writes selectors, coordinates or code. It returns an operation and an observed element index, such as CLICK [3] or TYPE_TEXT [7].
  • Before every input the executor re-checks that the page and the target are unchanged. If they moved, it retries the decision, not the action.
  • A DONE claim gets a second yes/no check before the run reports success.
  • Questions end with an answer read from the final page. If the page does not say, the answer says so instead of guessing.
  • It can open a site only when your goal names it: a URL, a domain, or a well-known name such as YouTube or Wikipedia.
  • Text to type can come straight from your goal, so most typing steps need no text-helper call.

Five decision backends

  • Decision API (default) — the system-one request format used by Jev: operation plus a speculative target per operation, in one round trip. Point it at any compatible decision model.
  • OpenRouter decision model — yes/no scoring models served on OpenRouter's decisions endpoint. Every candidate action becomes one yes/no question in a single request, and scores under 0.2 execute nothing.
  • Inception decision model — mercury-decide on Inception's own API, with native multi-choice questions and probabilities.
  • Letter-choice model — small classifiers that answer one letter per question. The operation question and each target question run in parallel.
  • Any LLM — one JSON call per step that returns the operation, the target and the text to type. A fast model is enough.

Settings → Ultrafast is where you pick the backend and add its key. Leave the text helper empty when a coding agent passes values through run_task.

Research

Research answers a question that needs more than one page. The important difference from a search API is where the reading happens: in background tabs of your browser, so pages that need JavaScript or a login still open.

  1. Plan. The model writes two to four search queries that cover the question from different angles.
  2. Search. Each query runs on DuckDuckGo by default, with Bing, Google or any search URL as a fallback if an engine shows a CAPTCHA or nothing useful.
  3. Read. The most promising results, different sites first, open in parallel background tabs. Each page is condensed into a short summary plus exact quotes.
  4. Fill gaps. Standard and Deep runs check what is missing or resting on one source, then search again.
  5. Write. The report answers first and then gives detail. Every claim cites a numbered source, and citations to sources that do not exist are removed.
DepthRoundsSources read
Quick1about 4
Standard2about 6
Deep3about 10

Tabs are closed when the run finishes. The report can be copied, downloaded as Markdown, or repeated on a schedule. Research cannot read PDFs yet, so a question whose only sources are PDFs will come back thinner than it should.

Tasks

Tasks is for jobs too long for one context window: completing a course, checking a list of pages, working through an inbox. The plan is explicit and the progress survives interruptions.

  1. Plan. The model splits the goal into three to fifteen concrete subtasks, and can add more as it discovers them.
  2. Work. Each subtask runs with a fresh context: the overall goal, the plan with done marks, and saved notes. Context does not balloon, so a task can keep going for hundreds of steps.
  3. Remember. Notes about progress, URLs and answers carry across subtasks. Progress is saved after every step.
  4. Ask. For a login, a payment, a CAPTCHA or an answer it is unsure about, it stops in the panel and continues with your reply.
  5. Retry. A failed subtask is retried once with the issue noted. If it fails again it asks how to proceed, or you can tell it to skip.

Closing the panel or restarting Chrome pauses the task rather than losing it: look for the Resume banner. Steps per subtask and total steps before checking in are budgets in Settings → Tasks. Every task stays in the task list, so you can start another while one is paused.

Which one to use

“What does this page say?”
Chat. One tab, one answer, no plan needed.
“Search flights and fill the form.”
Fast. A short, well-defined sequence of inputs where the page is the only thing that changes.
“Compare these plans across three providers.”
Research, Standard. Several sources, and you want the quotes and links.
“Finish the onboarding modules on this course.”
Tasks. Many steps, likely interruptions, and you want to resume tomorrow.

What each one costs

HailBrowser is free and MIT licensed. You pay your model provider, and only for the calls a run actually makes. The shape of the cost is different per mode:

  • Chat calls your chat model once per tool call, with the conversation so far. Long chats cost more per step than short ones.
  • Fast makes one decision request per step. That is the cheapest way to drive a form, which is why it exists.
  • Research pays for query planning, one summarisation per source, and the final report. Depth is the dial.
  • Tasks pays per step across every subtask. The step budgets in Settings are the ceiling, not a target.

No hidden meter

There is no HailBrowser subscription and no proxy in the middle. Keys stay in chrome.storage.local and requests go straight to the provider you chose.

Driving it from a coding agent?

Set a decision model, leave the text helper empty, and let your agent call run_task with the goal and the values. The guide below has the exact arguments.

Connect an agent