[Feature Request] Add Xiaomi MiMo Web Cookie Provider (for MiMo-V2.5-Pro)

[xspylol]

Description

I would like to request a new Web Cookie Provider specifically for the Xiaomi MiMo Studio ecosystem (https://aistudio.xiaomimimo.com).

This would allow users to extract their browser session cookies from the MiMo Studio playground and use them to route mimo-v2.5-pro through OmniRoute for high-volume, local API access.

Why is this needed?

Xiaomi’s newly released MiMo-V2.5-Pro is a massive 1-trillion parameter MoE model with a 1-million token context window. It is specifically optimized for long-horizon agentic workflows and complex software engineering tasks (such as end-to-end compiler design).

While the official platform.xiaomimimo.com developer API has strict rate limits during its beta period, the web-based MiMo Studio (aistudio.xiaomimimo.com) is completely free to use with incredibly generous, browser-based boundaries.

Adding a Web Cookie proxy for MiMo Studio would allow independent developers to route this powerhouse model directly into agentic CLIs (like Kilo Code, OpenCode, or Claude Code) via OmniRoute without hitting early token caps or requiring official corporate API verification.

How it could work:

1. New Provider Option: Add "Xiaomi MiMo Web" under the Web Cookie Providers panel.
2. Session Authentication: Allow users to paste their browser session cookies (such as the authentication or session tokens extracted from aistudio.xiaomimimo.com).
3. Model ID Mapping: Expose the model target as mimo-v2.5-pro (with support for the 1M context endpoints).
4. Endpoint translation: Route OmniRoute's incoming /v1/chat/completions request structure to match MiMo's web-socket/SSE streaming format.

Thank you for the incredible work on OmniRoute! Having first-class web-session support for Xiaomi's massive new MoE models would be an amazing addition to the local development toolkit.

[diegosouzapw]

Hey @xspylol! Massive thanks for these five well-written requests — Qwen, Kimi, Z.ai/GLM, Xiaomi MiMo, and MiniMax. Bundling my reply since the architecture is the same for all of them.

Quick status:

• API-based providers already exist for Qwen (qwen), Kimi (kimi), GLM (glm/glmt), and MiniMax (minimax) — you can already use these today with their official developer API keys.
• Web-cookie variants do not exist yet for any of the five — the only web-cookie providers OmniRoute ships are chatgpt-web, deepseek-web, grok-web, gemini-web, perplexity-web, muse-spark-web, and adapta-web.

Adding each web-cookie provider is straightforward in principle but non-trivial in practice — each frontend uses a different streaming format (WS vs SSE), most use a PoW/captcha layer that needs reverse-engineering (the DeepSeek one already gave us a bug — see #2680 / #2724), and the cookie-extraction UX needs documentation per site.

I have opened umbrella issue #2725 covering all five so we can prioritize them by upstream stability / model quality and tackle them one at a time. Suggested order there is Qwen Web → Kimi Web → GLM Web first (highest leverage given how generous their free web tiers are), then MiMo and MiniMax. If you have a different preference, drop a comment on #2725.

[xspylol]

Hey! Thanks so much for the detailed breakdown and for opening the umbrella issue (#2725). I completely understand the technical hurdles with the PoW/captcha layers and different streaming formats that makes total sense.
The suggested priority order (Qwen → Kimi → GLM) sounds perfect to me, especially since their free web tiers are so generous. I'll keep an eye on #2725 and would be more than happy to help test the web-cookie variants or provide cookie/captcha examples when you start working on them. Thanks again for all the hard work!

[diegosouzapw]

Thanks @xspylol! Xiaomi MiMo will land after the Qwen/Kimi/GLM trio per the order in #2725, but when it gets close I'll ping you here for MiMo Studio cookie samples -- real-account testing is the slowest part. Following #2725 is the right thread to watch.

[richardchen874-sys]

This would be a powerful provider, but I agree with the maintainer that the web-cookie path is probably more fragile than a normal API provider.

For agentic CLI workflows like Kilo Code, OpenCode, or Claude Code, the hard part is not only mapping MiMo Studio into /v1/chat/completions. The provider also needs to stay reliable across:

• cookie/session expiry
• PoW or captcha changes
• WS vs SSE streaming translation
• rate-limit behavior that may not be documented
• long-context requests
• tool-loop retries
• partial stream failures
• account safety / ToS risk

MiMo-V2.5-Pro sounds very interesting for long-context software engineering tasks, but coding agents are also very sensitive to instability. One broken stream or expired session can waste a whole multi-step run.

So I’d probably treat a MiMo Web provider as an experimental route first, and test it separately from official API providers with metrics like time to first token, streaming stability, retry rate, and cost/reliability per completed agent task.

The umbrella issue approach makes sense here. Qwen/Kimi/GLM first also seems reasonable because provider stability and real-account testing will matter more than just adding another model ID.