You cannot start a new Xiaomi API task on the original MiMo-V2-Omni model: Xiaomi retired the exact mimo-v2-omni ID on June 30, 2026. Keep a dashboard-check prompt as a historical recipe, choose a currently available model in a local agent, and use Tabbit Browser plus Tabbit CLI only after confirming that client can reach the signed-in browser. Xiaomi's replacement chain matters: Omni first routed to V2.5, and the V2.5 endpoint was later routed to V2.6 Flash before its October retirement. A replacement alias does not prove the original model still runs. Xiaomi's deprecation schedule
A Reddit user comparing models in OpenClaw said MiMo Omni and Pro were good replacements for MiniMax M2.7. That is a dated personal comparison, not evidence that Omni remains available or that it can control a browser. Read the original discussion
Key takeaways
The first-party Xiaomi ID
mimo-v2-omniis retired; do not advertise it as a live browser agent model.Xiaomi's published route changed twice after Omni: first to V2.5, then to V2.6 Flash. Recheck the current model ID before each new task.
Preserve prompts, expected fields, and fixture records as a historical baseline, not as proof of a current Omni run.
Tabbit CLI is an independent local browser connector. A local agent, its selected model route, the CLI launcher, and the signed-in website profile are separate checks.
For a live dashboard task, ask the agent to list changes and evidence, then stop at a named draft for review.
MiMo-V2-Omni route status
| Check | Evidence reviewed November 10, 2026 | Practical consequence |
|---|---|---|
| First-party API ID | mimo-v2-omni was replaced by mimo-v2.5 from June 1, then deprecated June 30, 2026 | The old ID no longer identifies a live first-party Omni route |
| Replacement route | Xiaomi later routed V2.5 calls to mimo-v2.6-flash from October 14 and deprecated V2.5 on October 21 | Choose and verify the current model explicitly; do not infer behavior from the old name |
| Models.dev label | xiaomi/mimo-v2-omni is a catalog-style identifier, not proof that Xiaomi accepts the request today | Treat catalog entries as discovery only |
| Tabbit CLI | Separate local connection to Tabbit Browser | It cannot restore a retired endpoint or verify which model answered |
Xiaomi's official table distinguishes replacement time from retirement time. That distinction is useful when reading old logs: a request made after a system switch may have reached a newer model even if an old ID remains in a saved prompt. The original model listing or a previous successful request is not a current availability check.
Keep a dashboard recipe without claiming a model test
The example below is a proposed workflow, not a completed MiMo-V2-Omni run. Use a test dashboard or a page you are authorized to read. Keep the model choice visible in the task record, and do not include private account data in the prompt.
The MiMo-V2-Omni API route is retired. Do not claim to be running MiMo-V2-Omni.
Using the currently selected local agent and Tabbit skill, open the dashboard page I name in a separate task tab.
Read the visible cards and compare them with the baseline I provide.
For every change, report the card title, old value, new value, timestamp, and source URL.
If the baseline or a field is missing, write "unknown" and explain what I need to check.
Do not click controls that change data. Save a draft named "Omni dashboard change review: GEO-192" and stop for my review.
Expected output: model route and version, page title and URL, one row per observed change, source links, unknowns, and a draft link.GEO-192 and the draft name are illustrative labels, not real dashboard records. Before using a live site, confirm your agent's model selector resolves to a current endpoint. The MiMo-V2.6 Flash browser guide covers the successor family's workflow; it does not imply identical behavior to Omni. For the browser side, see the Tabbit CLI guide, connecting an agent to an existing browser, and the first browser task checklist.
Route the work through a local browser task
Install Tabbit Browser, sign in to the dashboard in the profile you intend to use, and check the local client in three parts. First, confirm its documented skill entry point and that it has discovered the Tabbit skill. Pi uses /skill:tabbit; other clients may use /tabbit, /skills, or automatic skill loading. Second, confirm the client's process can invoke the installed tabbit-cli launcher on the same computer. Third, confirm the dashboard itself is signed in within the Tabbit profile the task will control. A skill being present does not prove the launcher is reachable, and a reachable launcher does not prove the target site is signed in. See the CLI versus MCP comparison and Codex setup notes.
In our local fixture check, the test page returned HTTP 401 before a short-lived test cookie was set. A separate named CLI task then opened the same page in its own task tab and returned HTTP 200, the heading Release notes review, and fixture record GEO-104. The cookie and scratch tabs were cleaned up afterward. This verifies that a separate Tabbit CLI task can reuse the signed-in Tabbit browser environment in this test setup. It does not test MiMo-V2-Omni, a public dashboard, or an external model integration.
The separate task tab lets you keep working in other browser tabs while the agent reads the selected page. It does not isolate the agent from information the selected Tabbit profile can access, so choose the profile and page carefully. The signed-in browser connection guide and agentic browser overview explain that boundary.
Decide whether to run, hand off, or stop
| What you can verify | Next step |
|---|---|
Only an archived mimo-v2-omni prompt remains | Keep it as a historical recipe; do not run it under a different model name |
| A current Xiaomi model ID is listed | Select that exact ID in a supported client and verify its route before enabling browser tools |
| The model works, but the agent cannot run the local CLI | Hand the task to a local agent or do the browser steps yourself |
| Tabbit CLI reaches the intended signed-in dashboard | Read the named page, capture its title and URL, and draft a sourced change list |
| A field is hidden, ambiguous, or could trigger a write | Mark it unknown and ask a person to check before proceeding |
Keep the first task read-only. The browser agent safety guide covers the risk of giving an agent a signed-in session; for a general choice between automation routes, use the browser MCP versus CLI guide. The useful result is a short, reviewable change list tied to visible evidence, not an unsupported claim that an archived model performed the work.
FAQ
Can I still run MiMo-V2-Omni on Xiaomi's API?
No. Xiaomi's notice says `mimo-v2-omni` was routed to `mimo-v2.5` on June 1, 2026 and deprecated on June 30. The V2.5 replacement was later routed to V2.6 Flash and deprecated in October, so the old ID is not a stable way to run Omni.
Can Tabbit CLI restore the retired model?
No. Tabbit CLI connects a local agent to a Tabbit Browser task; it does not provide or revive a model endpoint. Select a currently available model and verify the route separately.
Can I keep my old dashboard prompt?
Yes, as a historical task recipe. Label it with the model ID and date, preserve the expected output fields, and do not describe a new result as MiMo-V2-Omni output.
How can a local agent use my signed-in website?
Sign in to the site in the intended Tabbit Browser profile, then use a local client that can discover the Tabbit skill and run the local CLI. Confirm the client, launcher, and browser session separately.
What should the dashboard report?
Ask it to list visible changes with source URLs, timestamps, and the field that changed. Anything hidden, ambiguous, or unavailable should be marked unknown for a person to check.
Can a remote agent use my Tabbit login?
Only if its runtime can reach the same machine and Tabbit browser controller. A hosted session should not be assumed to share your desktop browser profile or cookies.