MiMo-V2.5-Pro on OpenRouter: Claude Code, OpenCode & Kilo

OpenRouter MiMo-V2.5-Pro model available Claude Code OpenCode Kilo non quantized provider: yes, xiaomi/mimo-v2.5-pro is available through OpenRouter and is usable from all three coding-agent environments. But do not treat “non-quantized” as a selectable provider guarantee: Xiaomi’s official MiMo-V2.5-Pro release is FP8 (E4M3) mixed precision, and OpenRouter’s provider routing can filter by advertised precision only when an endpoint actually offers it.

That distinction matters because four separate things often get collapsed into one question: the model checkpoint Xiaomi released, the precision a hosting provider uses in production, the OpenRouter route that receives your request, and the coding-agent harness that turns a model response into file edits and shell commands. You can choose the model and, sometimes, the provider. You generally cannot infer exact serving precision just from a model name, a benchmark chart, or the fact that a provider is listed.

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

Yes. The OpenRouter model ID is xiaomi/mimo-v2.5-pro. OpenRouter lists a 1M-token context window and multiple upstream hosts for the model, then load-balances or routes requests according to the routing policy you choose. It supports the OpenAI Chat Completions and Responses formats as well as an Anthropic Messages-compatible endpoint, which is why it can fit into several agent tools without writing a bespoke SDK adapter.

MiMo-V2.5-Pro is a very large mixture-of-experts model: Xiaomi describes 1.02T total parameters with 42B active parameters per token. That scale is a practical reason to use an API provider rather than attempt a casual local deployment. It is aimed at long-running coding and agent work, but the right expectation is not “it will autonomously finish any repository task.” Treat it as a capable coding model whose result is shaped heavily by the harness, tool permissions, context management, provider behavior, and your review process.

Is there a non-quantized MiMo-V2.5-Pro provider on OpenRouter?

Not as a claim you should make based on the public model listing. The official MiMo-V2.5-Pro download table identifies the released model as FP8 (E4M3) mixed precision. FP8 is already a lower-precision floating-point format than FP16, BF16, or FP32; it is not an untouched full-precision checkpoint in the everyday sense developers mean by “non-quantized.” The Hugging Face repository exposes several tensor types in its files, but Xiaomi’s published download specification remains FP8 mixed precision.

OpenRouter does let callers constrain routing with a provider.quantizations field. Its documented values include options such as int4, int8, fp4, fp8, fp16, and bf16. That is useful only if the live endpoints for this model publish a matching precision. Filtering for fp16 or bf16 is therefore a request constraint, not evidence that such a MiMo-V2.5-Pro endpoint exists today. If precision is a hard requirement, inspect the live provider page or API endpoint metadata immediately before deployment, then pin an allowed provider and disable fallbacks. Otherwise, a fallback can satisfy availability while changing the serving path you thought you selected.

There is also a useful correction to the premise: precision is not a complete quality specification. Two hosts can both report FP8 and still differ in inference engine version, tensor parallelism, speculative decoding, maximum output limits, tool-call handling, caching, regional latency, and system-side sampling defaults. For coding agents, correct tool use and stable long-context behavior often matter more than a simplistic “quantized versus non-quantized” label.

How do I use MiMo-V2.5-Pro with Claude Code through OpenRouter?

Claude Code can talk to OpenRouter through OpenRouter’s Anthropic-compatible endpoint. Configure the OpenRouter token and endpoint, clear any conflicting Anthropic credential, then set Claude Code’s role model overrides to the MiMo model. OpenRouter explicitly cautions that its Claude Code integration is guaranteed only for Anthropic’s first-party models, so regard a non-Anthropic model such as MiMo as a compatibility experiment that deserves a real repository test before team-wide adoption.

export OPENROUTER_API_KEY="sk-or-v1-..."
export ANTHROPIC_BASE_URL="https://openrouter.ai/api"
export ANTHROPIC_AUTH_TOKEN="$OPENROUTER_API_KEY"
export ANTHROPIC_API_KEY=""

# Start by routing the primary coding role to MiMo.
export ANTHROPIC_DEFAULT_SONNET_MODEL="xiaomi/mimo-v2.5-pro"
export CLAUDE_CODE_SUBAGENT_MODEL="xiaomi/mimo-v2.5-pro"

claude

After starting Claude Code, run /status and confirm that it is using ANTHROPIC_AUTH_TOKEN and the OpenRouter base URL. If you previously authenticated Claude Code directly, run /logout, restart the terminal, and try again. Keep the first trial intentionally bounded: ask the agent to diagnose a failing test, make a small patch, run the relevant command, and explain the diff. That tests the actual interaction you care about—reasoning plus tools plus edits—rather than just whether the model can answer a chat prompt.

How do I use MiMo-V2.5-Pro with OpenCode?

OpenCode has a first-class OpenRouter provider flow. The simplest setup is /connect, choose OpenRouter, paste an API key, then use /models to select xiaomi/mimo-v2.5-pro if it is present in the catalog. If a just-released model is not preloaded, add it under the OpenRouter provider in opencode.json. OpenCode also exposes provider-specific options, so you can pin or order upstream providers instead of relying on default routing.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openrouter": {
      "models": {
        "xiaomi/mimo-v2.5-pro": {
          "options": {
            "provider": {
              "order": ["xiaomi"],
              "allow_fallbacks": false
            }
          }
        }
      }
    }
  }
}

Do not copy the provider slug blindly from this example: OpenRouter’s model page is the source of truth for currently available provider IDs and variants. For normal exploratory use, allow fallbacks and let OpenRouter optimize uptime. For a reproducible evaluation, pin a provider, record the date, model ID, routing policy, output cap, and tool settings. Without that record, a later result may look like the model changed when the route changed instead.

How do I use MiMo-V2.5-Pro with Kilo Code?

Kilo Code supports OpenRouter as an AI gateway, and its custom-model system can expose a model before it appears in a built-in picker. Connect OpenRouter with your API key, choose the model if it is listed, or define it in trusted global configuration. For a custom entry, set realistic context and output limits and enable tool calling; otherwise a coding agent may fail in a way that resembles weak model quality but is actually bad client metadata or disabled tools.

{
  "$schema": "https://app.kilo.ai/config.json",
  "provider": {
    "openrouter": {
      "models": {
        "xiaomi/mimo-v2.5-pro": {
          "name": "MiMo-V2.5-Pro",
          "tool_call": true,
          "limit": {
            "context": 1000000,
            "output": 32000
          }
        }
      }
    }
  }
}

The output number above is a client-side operating limit, not a promise that every OpenRouter provider will accept or return that many tokens. Start lower for interactive work and raise it only when the agent genuinely needs room for a long implementation or a large reasoning-and-tool sequence. Also keep secrets out of repository configuration. Kilo’s documentation notes that environment-variable references in project-level config are intentionally not resolved, which prevents a committed config file from silently becoming a credential mechanism.

Which MiMo-V2.5-Pro provider should I choose?

Choose based on the failure mode you are trying to avoid. For everyday coding, default routing is reasonable: it can choose among healthy providers and recover from an upstream error. For stable latency, compare the current provider page’s time-to-first-token and throughput data, then use an ordered provider list. For cost control, set a maximum price and monitor cached versus uncached input. For data handling or contractual requirements, use OpenRouter’s provider constraints such as zero-data-retention eligibility where available, rather than assuming every host has the same policy.

• Use default routing for personal experimentation and low-stakes agent sessions.
• Pin one provider with fallbacks disabled when comparing models, debugging a regression, or enforcing a specific data path.
• Use a quantization filter only after confirming that a compatible endpoint is live for the model.
• Test the exact agent and task you will ship: repository navigation, tool calls, patch quality, tests, retries, and cost per completed task.
• Log model ID, provider route, date, prompt/tool policy, and commit outcome for every serious evaluation.

Why Cline.bot is relevant to MiMo-V2.5-Pro and OpenRouter

Cline.bot is relevant because Cline is another coding-agent environment where model choice, gateway configuration, and tool execution meet. Its OpenRouter integration lets developers select OpenRouter in Cline, provide one API key, and choose a model from the provider’s catalog; Cline also supports generic OpenAI-compatible endpoints. That makes it a practical alternative when you want to evaluate MiMo-V2.5-Pro against other models without rebuilding your editor workflow around each vendor.

What makes Cline good here is not a claim that one agent wrapper magically improves every model. It is the useful engineering flexibility: bring your own provider, switch models through a common interface, use local or hosted endpoints when appropriate, and keep the agent’s file, terminal, and approval workflow visible to the developer. For MiMo-V2.5-Pro specifically, Cline gives you another way to test whether the model’s coding ability survives the real constraints that matter—tool calls, context, permissions, diffs, and tests—rather than judging it from a leaderboard alone.