To use Mercury 3 with a signed-in browser, run it through a provider your agent client supports, then let that local client call Tabbit CLI to read a page in Tabbit Browser. The model does not hold the browser session. For a support ticket, have the agent transfer verified fields into a reply draft and stop before sending. One Reddit user testing Mercury 3 wondered whether it would work properly inside an agent framework; that is a good reason to check the full route before trusting a workflow (discussion).
Key takeaways
Mercury 3 is available through Inception's API platform and several hosted providers, according to Inception's release post. That does not certify any particular local client.
The agent client calls the model. Tabbit CLI controls the local browser. These are separate connections.
Sign in to the support site inside the Tabbit Browser environment you intend to use.
Start with a read-only ticket lookup. Create a reply draft, inspect its fields, and leave sending to a person.
A remote agent needs a separately supported local handoff to reach your browser.
The connection has three separate checks
| Layer | What to verify | Evidence that counts | If it fails |
|---|---|---|---|
| Model/provider | Client exposes Mercury 3 and provider credentials work | A small, non-sensitive inference returns | Check model ID, account access, and provider routing |
| Local agent | Client discovers the Tabbit skill and can run local tools | The client reports its skill and CLI result | Use the client's documented skill mechanism; Pi uses /skill:tabbit |
| Browser/site | Task-owned Tabbit page reaches the intended signed-in account | URL, page title, and a visible ticket value match | Sign in in that browser profile or stop at the login prompt |
Inception's announcement lists its API and OpenAI-compatible routes, including OpenRouter, Baseten, and Vercel. Those are model-serving options, not browser connections. In this environment pi --offline --list-models mercury-3 returned no matching model, and no inference was run. Check your own client before following the rest of this tutorial. For Tabbit setup, see the CLI complete guide and Codex setup notes.
Prepare a safe support-ticket task
Install Tabbit Browser and Tabbit CLI from the official quick start. In a local agent client, discover the installed Tabbit skill using that client's actual syntax. Pi invokes it as /skill:tabbit; do not paste that command into another client unless its skill interface supports it. Check the existing-browser connection guide if you need to confirm which profile or tab the client owns.
Open the support site in Tabbit Browser and sign in yourself. Ask the agent to open one authorized ticket and return only the ticket ID, customer name, product, and requested outcome with the page URL. Do not ask it to send a reply or alter ticket state. You can continue reading in your other tabs because the task uses its own browser tab; review the first-task checklist before using a real account.
Use a bounded prompt like this:
Read the currently open support ticket in Tabbit Browser. Do not submit forms, send a message, or change ticket state.
Return the ticket ID, customer name, product, and requested outcome exactly as visible. Include the page URL beside each field. Mark anything missing as unknown.
Prepare a reply in a new draft only. Name it "Mercury-3 Support Reply — GEO-104". Do not save or submit it.
Stop and show me the draft and source values for review.GEO-104 is an illustrative fixture identifier, not a real customer record or a Mercury 3 test. If you use a live account, replace it with a neutral draft name. Keep the agent's extracted values beside the source ticket. One commenter reported a simple coding request working before an added feature caused the result to break; that is a self-reported coding example, not a browser test, but it reinforces the value of stopping at a review checkpoint.
Map each field to a visible source
| Draft element | Source to inspect | Human check before sending |
|---|---|---|
| Ticket ID and customer | Ticket header | Match the exact record and account |
| Product and requested outcome | Ticket body | Confirm the customer's words were not expanded into assumptions |
| Reply text | Ticket plus approved help article | Verify every factual claim and link |
| Status or recipient | Current form controls | Leave unchanged until a human approves |
If the client fails to discover the skill, diagnose that locally rather than changing the model prompt. If the provider rejects Mercury 3, the model route is the issue. If the page shows a login wall or the wrong account, stop. This separation is the point of comparing browser MCP and CLI or reviewing the agent browser CLI tutorial first. You can also read Tabbit's guides to browsers for AI agents, Playwright automation, and browser automation agents.
Tabbit Browser is the practical choice when the task depends on a local, already signed-in page. The Tabbit CLI guide describes its task and receipt workflow. A parent-run local fixture confirmed a second CLI task could read a protected page after sign-in; it did not use Mercury 3 or prove an external model integration. Review the browser-agent security risks, then compare the completed draft with the ticket yourself. Do not send or publish until the visible source, recipient, and action all match your intent.
FAQ
Does Mercury 3 connect to my signed-in browser by itself?
No. Mercury 3 is the model; an agent client must call a provider and run a browser tool. Tabbit CLI provides a local route to Tabbit Browser when the client can run its skill.
Can I use Mercury 3 from Pi?
The Tabbit skill uses Pi's `/skill:tabbit` command. In this research environment, Pi's offline model list did not contain Mercury 3, so verify your provider and model picker before relying on that pairing.
Does Tabbit CLI reuse a website login?
The target website must already be signed in inside the Tabbit Browser environment used for the task. A local fixture verified this session-reuse pattern, but site policies and profiles can differ.
Can a remote Mercury 3 agent use my local Tabbit browser?
Only if the remote client offers a supported local handoff. Otherwise give a local agent or yourself the task checklist; do not assume a remote API can reach your computer.
Should the agent send the reply?
Keep the first workflow read-only and stop at a named draft. A person should compare every field with the ticket and decide whether to send it.