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.
| Mode | Best for | Model calls | Stops and asks |
|---|---|---|---|
| Chat | One page, a question, a short job | One per tool call | When it is unsure |
| Fast | Forms, search boxes, repeated clicks | One decision per step | On a missing value |
| Research | A question that needs several sources | Per source and per round | Never: it reports gaps |
| Tasks | A goal that takes many steps | Per step, across subtasks | For 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
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]orTYPE_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
DONEclaim 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-decideon 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.
- Plan. The model writes two to four search queries that cover the question from different angles.
- 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.
- Read. The most promising results, different sites first, open in parallel background tabs. Each page is condensed into a short summary plus exact quotes.
- Fill gaps. Standard and Deep runs check what is missing or resting on one source, then search again.
- 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.
| Depth | Rounds | Sources read |
|---|---|---|
| Quick | 1 | about 4 |
| Standard | 2 | about 6 |
| Deep | 3 | about 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.
- Plan. The model splits the goal into three to fifteen concrete subtasks, and can add more as it discovers them.
- 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.
- Remember. Notes about progress, URLs and answers carry across subtasks. Progress is saved after every step.
- 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.
- 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.