As of November 9, 2026, do not start a new signed-in browser workflow on inception/mercury-2.5. Inception says Mercury 2 and 2.5 are closed to new users, with pre-October 19 customers keeping access through November 15. OpenRouter’s live model endpoint for inception/mercury-2.5 returned an empty endpoints list during this research. If you already have eligible legacy access, a local agent can use Tabbit CLI only while its model provider and client still work. For new Inception access, check the separate Mercury 3 route. Mercury 3 is not the Mercury 2.5 alias.
A Reddit user who tested Mercury 2.5 Preview in Pi called it “Great for lightweight scout/searcher subagents” but said they had “found it weak on tool calling.” Another user ran the Preview against 39 MindTrial text tasks with a Python executor and reported mixed results. Both are community reports about the Preview, not proof of current Mercury 2.5 availability or a controlled browser-agent evaluation. They do support one practical rule: verify the model and tool path in the exact client before opening a logged-in account.
Key takeaways
Mercury 2.5 is in a deprecation window. Check provider availability before building around the alias.
OpenRouter’s current endpoint record returned no endpoints for
inception/mercury-2.5; do not copy old examples and assume they still run.Inception says existing qualifying customers retain Mercury 2.5 access through November 15, 2026. New users cannot onboard to it.
Mercury 3 is a separate model with a different API ID. Follow Inception’s migration guidance rather than silently swapping model strings.
Browser access comes from the local agent and Tabbit CLI, not from Mercury itself.
Mercury 2.5 availability at a glance
| Route checked on Nov 9, 2026 | What the source says | How to proceed |
|---|---|---|
| Inception API | Mercury 2 and 2.5 are unavailable to new users; eligible existing accounts keep access until Nov 15 | If already eligible, test the exact account and endpoint before using it |
OpenRouter inception/mercury-2.5 | Its model endpoint returned endpoints: [] | Treat the alias as unavailable through this route |
| Inception Mercury 3 | Separate current model, released Oct 16 with a 1M context listing | Check the new ID, client compatibility, limits, and migration instructions |
| Local browser control | Tabbit CLI is the browser connection used by a local agent | Confirm launcher reachability and site login separately from model selection |
Verify the alias, not the model name in an old config
Inception’s current model page says Mercury 2 and Mercury 2.5 are no longer available to new users. It preserves access for customers whose usage predates October 19 until November 15, 2026, with enterprise agreements handled separately. The OpenRouter model page remains readable, but its live model-endpoints API response returned an empty endpoint list on November 9. A readable description is not proof that requests can still be routed.
The current Mercury 3 page lists a different release, ID, and context window. Inception’s launch announcement for Mercury 2.5 describes 260K context and the model’s launch capabilities; do not carry those specs over to Mercury 3. The safe migration sequence is: identify which provider serves the old ID, read its current availability, select a currently supported ID, then test a harmless request and a tool call in the intended client.
Put the browser and model in separate boxes
If you already have permitted Mercury 2.5 access, the local agent still has to meet two independent conditions. It must be able to call the selected model endpoint, and it must be able to run the Tabbit CLI launcher on the machine where Tabbit Browser is open. A model directory’s “tool calling” flag does not install the Tabbit skill, create a local process bridge, or sign into a website.
On clients that discover Tabbit’s installed skill, use the documented /tabbit entry after checking that the agent can see the skill. Pi documents /skill:tabbit; other clients may show a Skills menu or /skills. Tabbit’s CLI quick start documents launcher setup for its supported clients. From the same machine, run tabbit-cli diagnose. Finally, open the target site in the intended Tabbit profile and confirm the signed-in account. A remote agent runner will not inherit a desktop browser session unless it has a separately verified local connection.
| Gate | A simple check | If it fails |
|---|---|---|
| Client skill discovery | Search the agent’s available skills for tabbit or use that client’s documented skill command | Restart the client or follow its skill-install instructions |
| Tabbit launcher | Run tabbit-cli diagnose locally and check controller status | Repair the local CLI/browser connection before asking the model to act |
| Model provider | Check current model ID and live endpoint; send a harmless test request | Change provider or model only after checking the error and migration path |
| Website login | Inspect the target page in the intended Tabbit profile | Sign in manually, then verify the account before a read task |
A local Tabbit CLI fixture check in this environment confirmed that a task could read a page after an earlier task established its test login. That verifies only Tabbit’s browser-session flow here. It did not verify Mercury 2.5, an external model client, or the continued availability of any provider.
Reconcile one record across two signed-in pages
The stable use case in this guide is reconciling one record in two browser systems, such as the same ticket in a support queue and a release tracker. Use a stable record ID, not a name or title that might be duplicated. Start with read-only access and have the agent report the page title and ID before it compares values.
Ask the agent to confirm whether the exact Mercury 2.5 provider is still selectable. If it is unavailable, stop; do not let an old API alias trigger retries or silently switch models.
In Tabbit Browser, sign into both approved sites. Ask the agent to open each site in a named, task-owned tab and search for the same stable ID.
Have it return the two observed values with page titles, URLs, and the time checked. It should list mismatches, not resolve or write them.
Review both pages yourself. Then ask the local agent to save a draft such as
Record GEO-104 cross-check, with a visible review checkpoint.Correct the draft manually. Do not update either source system until you approve the specific change.
A prompt for a safe reconciliation pass:
Use Tabbit CLI to read the two pages I named in this task. Read only the record with stable ID GEO-104. Do not submit, edit, send, or delete anything. Before comparing, return each page title, URL, and the visible record ID. If both IDs match, draft a table with field, page A value, page B value, and needs-review. If either ID does not match or a field is missing, stop and report it. Save a draft named "Record GEO-104 cross-check" and stop at the review checkpoint.GEO-104 is an illustrative fixture ID, not a real customer record. Replace the test ID and page names only after you select the approved task. Do not include customer secrets in a prompt.
What the community evidence does and does not say
The Reddit Preview user who ran the model in Pi liked it as a lightweight scout but called tool calling a weakness. A second user compared the Preview across a fixed text task set using a local Python executor and reported that results varied by puzzle type and output setup. The first is a subjective early user impression; the second is a specific but non-controlled benchmark report, and both concern the Preview. Neither changes the current API status. If the active Mercury 2.5 route is gone for your account, migrate before setting up a browser flow.
Use Tabbit Browser when the job depends on a site where you are already signed in. The Tabbit CLI complete guide explains the local connection. The agent-to-browser connection guide and browser MCP vs CLI comparison explain access options. Before the first action, use the browser-agent first-task checklist. You can also read Codex setup, the Tabbit Browser overview, its best-practices guide, and what an agentic browser is.
A Mercury 2.5 workflow is possible only for a short time and only for eligible legacy access. For a new setup, check Mercury 3 as a separate model and validate its provider and client tools. In either case, the browser part remains local: Tabbit CLI connects the agent to the signed-in Tabbit Browser, and you review the named draft before any edit is made.
FAQ
Can new users still get Mercury 2.5?
No. Inception says Mercury 2 and 2.5 are no longer available to new users. Existing customers who used the service before October 19, 2026 keep access only through November 15, 2026.
Does inception/mercury-2.5 still work on OpenRouter?
The OpenRouter model details endpoint returned an empty endpoints list on November 9, 2026. Treat that alias as unavailable there and check the live endpoint before relying on old configuration.
Is Mercury 2.5 the same model as Mercury 3?
No. They are separate models with different API IDs and release details. Inception lists Mercury 3 as the current model and says to contact its representative or documentation for migration guidance.
Can Mercury 2.5 itself open a logged-in browser?
No. The model endpoint and browser are separate components. A compatible local agent must call Tabbit CLI, and the selected model/provider must still be available and configured to use the agent’s tools.
What should I do if a Mercury 2.5 agent stops working?
Check the exact provider, model ID, endpoint response, and error before changing anything. If the old endpoint is gone, migrate to an explicitly available model such as Mercury 3 only after checking client support and testing the workflow.
Can I keep working while a Tabbit task runs?
Yes. Tabbit CLI uses task-owned tabs, so other browser windows remain available for review. Confirm the target page and account before the agent reads or changes anything.