MiMo-V2.5-Pro Model Available on OpenRouter for Claude Code, OpenCode & Kilo: Non-Quantized Provider

MiMo-V2.5-Pro is available on OpenRouter as xiaomi/mimo-v2.5-pro, and that makes it usable in OpenCode and Kilo Code through their OpenRouter integrations. It is not, however, a non-quantized provider option in the strict sense: Xiaomi’s official downloadable MiMo-V2.5-Pro checkpoint is FP8 (E4M3) mixed precision, while Anthropic explicitly says Claude Code does not support routing to non-Claude models through third-party gateways.

That distinction matters because this query combines four separate questions—whether the model exists on a router, whether coding agents can invoke it, whether Claude Code is a supported path, and whether the deployed model is unquantized. The short answer is yes for OpenRouter, OpenCode, and Kilo; no for an official non-quantized checkpoint; and no for officially supported Claude Code use.

Is MiMo-V2.5-Pro available on OpenRouter?

Yes. OpenRouter lists Xiaomi’s MiMo-V2.5-Pro under the exact API model ID xiaomi/mimo-v2.5-pro. Its listing reports a 1 million-token context window and current token pricing, which is enough to establish that this is a routable, paid API model rather than merely an announced release or a downloadable checkpoint. The model page also exposes a providers view, reflecting OpenRouter’s normal design: OpenRouter presents one model ID and routes requests to an available inference backend according to the routing policy you choose.

For an agent workflow, use the full model ID, not a display label such as “MiMo 2.5 Pro.” Model IDs are the contract between your client and the router. If a tool’s picker does not show it immediately, add xiaomi/mimo-v2.5-pro to that tool’s OpenRouter model configuration, then select it from the tool’s model list.

# OpenRouter API model ID
xiaomi/mimo-v2.5-pro

Is MiMo-V2.5-Pro non-quantized?

No—not according to Xiaomi’s official model release. The official MiMo-V2.5-Pro model card labels the downloadable Pro checkpoint as “FP8 (E4M3) Mixed.” It is a large mixture-of-experts model with 1.02 trillion total parameters and 42 billion active parameters, but its published weights are still FP8 mixed precision rather than BF16, FP16, or another commonly meant “non-quantized” format.

This is where the phrase “non-quantized provider” becomes misleading. There are two separate things people call quantization: the precision of the released weight files and the precision used by an API provider while serving the model. The former is publicly documented by Xiaomi and is FP8 mixed. The latter is generally not a stable promise from an API gateway: a provider may use different hardware, kernels, cache formats, or inference optimizations over time. An OpenRouter model listing is therefore evidence that you can call the model, not evidence that you are receiving BF16 or FP16 inference.

If unquantized weights are a hard requirement—for reproducible research, your own deployment controls, or a particular numerical behavior—do not infer that property from an API route. Check the exact checkpoint’s model card and the serving provider’s explicit precision documentation. For MiMo-V2.5-Pro, the official release does not satisfy a request for non-quantized downloadable weights.

How to use MiMo-V2.5-Pro with OpenCode

OpenCode has a documented OpenRouter integration. Connect an OpenRouter API key with /connect, choose OpenRouter, and use /models to see available models. OpenCode says many OpenRouter models are preloaded, but it also supports adding a model directly in opencode.json. That second route is useful when a newly released model has not yet appeared in a local catalog or when you want the repository or user configuration to make the intended model explicit.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openrouter": {
      "models": {
        "xiaomi/mimo-v2.5-pro": {}
      }
    }
  },
  "model": {
    "providerID": "openrouter",
    "model": "xiaomi/mimo-v2.5-pro"
  }
}

After configuring it, run /models and verify the selected provider is OpenRouter and the selected model is xiaomi/mimo-v2.5-pro. Do a small, bounded task first: ask the agent to inspect one module, propose a plan, run one test, and stop. This tests the entire integration path—authentication, model lookup, tool calls, streaming, and your project’s permission model—without letting a first experiment turn into a long and expensive autonomous session.

OpenCode can also pass OpenRouter provider-routing options per model. That is useful if you need a specific backend, want to disable fallbacks, or want routing behavior that is predictable during evaluation. But do not use provider pinning as a substitute for a precision guarantee. Provider choice and advertised checkpoint precision are different controls.

How to use MiMo-V2.5-Pro with Kilo Code

Kilo Code officially supports OpenRouter as an AI gateway. In the user interface, add OpenRouter under Providers, paste an OpenRouter API key, and select MiMo-V2.5-Pro if it appears in the model picker. Kilo’s documentation also supports direct configuration through kilo.json, with model IDs written as provider_id/model_id.

{
  "provider": {
    "openrouter": {
      "models": {
        "xiaomi/mimo-v2.5-pro": {}
      }
    }
  },
  "model": "openrouter/xiaomi/mimo-v2.5-pro"
}

Keep the OpenRouter key in a trusted global Kilo configuration rather than a project file committed to Git. Kilo deliberately does not resolve environment-variable and file secret references from an ordinary repository-level configuration, because an untrusted repository could otherwise redirect your client to an attacker-controlled base URL. That is a useful security boundary for any coding agent—not a MiMo-specific quirk.

Kilo also forwards OpenRouter provider routing fields from its model options. Use that only when you have a concrete operational reason, such as selecting a particular provider, preferring throughput over price, or applying a data-retention policy. Start with the default route if your goal is simply to establish whether MiMo-V2.5-Pro works well on your codebase.

Can Claude Code use MiMo-V2.5-Pro through OpenRouter?

Not as an officially supported Claude Code configuration. Anthropic documents how Claude Code can connect to an LLM gateway, but its current documentation specifically says Anthropic does not support routing Claude Code to non-Claude models through any gateway. MiMo-V2.5-Pro is a Xiaomi model, so it falls directly into that unsupported category.

That wording is important. “Unsupported” does not mean that nobody can construct an unofficial proxy, spoof an API shape, or publish a shell integration. It means you should not treat such a setup as a reliable Claude Code feature, expect Anthropic support for it, or assume new Claude Code releases will preserve compatibility. Gateways also need to forward new client capabilities as Claude Code evolves; otherwise, features can silently degrade or break.

If your practical goal is an agentic coding workflow powered by MiMo-V2.5-Pro, use a client that natively supports OpenRouter—such as OpenCode or Kilo Code—or use an OpenAI-compatible client against Xiaomi’s own API. Xiaomi documents both OpenAI-compatible and Anthropic-compatible API protocols for its service, but that does not override Claude Code’s stated support boundary for non-Claude upstream models.

What should you test before using it for real work?

Treat the model’s public benchmark claims as a reason to evaluate it, not as proof that it is right for your repository. MiMo-V2.5-Pro is positioned by Xiaomi for complex reasoning, long-context work, tool calling, structured output, and coding-agent tasks. Those are relevant capabilities, but a coding agent succeeds or fails on the full stack: tool-call formatting, terminal behavior, file-edit discipline, retries, test feedback, prompt templates, and the model’s willingness to stop when it lacks enough evidence.

1. Run a read-only codebase question and verify that cited files and symbols are real.
2. Ask for a small, isolated multi-file change with a clear test command.
3. Compare the produced diff against your project conventions rather than accepting the agent’s summary.
4. Measure total input, cache, and output tokens on a representative task; long contexts are useful but not free.
5. Keep human approval on for commands, edits, migrations, and deploy-related operations until you have observed repeatable behavior.

Use Cline when you want model choice without changing your coding workflow

If you reached this point because you want to test MiMo-V2.5-Pro in an agent rather than merely send API requests, Cline is an open-source coding agent for the editor, terminal, and SDK. Its site describes coordinated multi-file edits, terminal command execution, a Plan-and-Act workflow, repository rules, MCP and plugin extensibility, plus CLI use in scripts and CI pipelines.

For this exact provider question, the relevant claim is simpler: Cline says it supports OpenRouter, local Ollama and LM Studio models, and any OpenAI-compatible API, while letting you bring your own API key, endpoint, or weights. Its public product page does not state a separate per-seat or per-token price for this bring-your-own-provider path; in practice, the MiMo usage cost is determined by the provider account you connect. That makes it useful when you want to try a router-hosted model such as MiMo-V2.5-Pro while keeping the same agent interface, review habits, and project rules.