Three new models. A 1T+ parameter flagship, an open-source MoE, and a ~10x faster variant of the flagship. All three take text, image, video, and audio with 1M context.

OpenRouter says Xiaomi’s new model family splits the decision between flagship depth, a leaner open MoE and faster output from the same Pro checkpoint. The practical question is not which name sounds biggest, but which constraint matters most.

OpenRouter says Xiaomi MiMo-V2.6 is live with three variants: Pro, Flash and Pro-UltraSpeed. Its framing is unusually direct: a 1T+ flagship, an open-source mixture-of-experts model, and a faster-serving version of the flagship.
That makes this less interesting as a race for a single headline model and more useful as a routing decision. We may need depth for a long, demanding job, a smaller active model for a different operating constraint, or more output speed from the same Pro checkpoint. The available specifications and performance framing come from OpenRouter’s X thread and have not been independently verified.
The family only becomes legible once we separate the work that needs flagship depth from the work constrained by model shape or output speed.

OpenRouter’s launch language gives each variant a distinct role, but it does not settle the outcome for any particular workload. A long multimodal task may make the Pro positioning relevant; it does not prove stronger reasoning or reliable long-context recall in our use case.
Flash is the leaner option by the figures OpenRouter publishes. Pro-UltraSpeed changes a different variable: the rate at which the Pro checkpoint produces output. Those are useful starting points for evaluation, not a substitute for testing representative work.
OpenRouter’s thread supplies the model definitions and shared input claim. It does not provide independent benchmark, cost or quality validation.


The shared multimodal and one-million-token claim is important because it keeps the choice focused on the family’s stated operating differences rather than on incompatible input formats. It does not tell us how well any variant will handle a specific video, audio or long-context workload.
For now, OpenRouter is the evidence boundary. We can use its descriptions to form a testable hypothesis, but not to make stronger claims about benchmark leadership, cost or production reliability.
OpenRouter says Pro-UltraSpeed uses the same Pro checkpoint and changes output speed rather than the underlying model identity.
This is the distinction that prevents the launch from becoming three separate intelligence claims. Pro-UltraSpeed may be the same checkpoint served for faster output, which changes the operational trade-off without establishing that it is a new or smarter model.
If we are choosing between Pro and Pro-UltraSpeed, the first question is therefore whether output speed is the limiting factor in the actual workflow. We still need to test total task time, quality and failure modes ourselves.
the same Pro checkpoint at ~10x the output speed
OpenRouter
OpenRouter’s visual can show what it chose to present. It cannot, on its own, validate the chart’s methodology, comparisons or commercial implications.
Three new models. A 1T+ parameter flagship, an open-source MoE, and a ~10x faster variant of the flagship. All three take text, image, video, and audio with 1M context.

A published chart is still useful as a record of how OpenRouter frames the release. It is not independent validation of any benchmark position, price point, methodology or comparison shown within it.
That distinction protects the practical value of the story. We can inspect the release framing, then decide what our own tests must establish before the family is used for consequential work.
Start with the constraint that affects the work, then validate the chosen variant on representative inputs before making a production decision.

We should not treat model selection as a brand preference. Start with the job: what inputs it uses, whether it is long-running, how much output it needs and what must be checked before a result can be relied on.
Only then does the family framing become actionable. OpenRouter’s descriptions can guide the first comparison; representative evaluation determines whether the choice holds in our environment.
The launch supplies a starting hypothesis. A small, repeatable validation path turns that hypothesis into a decision we can defend.

Our first pass should be deliberately narrow: one representative task, a clear success condition and a record of where the chosen variant succeeds or fails. That avoids turning launch language into an untested production assumption.
The same discipline applies to the shared 1M-context and multimodal claims. They may widen the set of tasks worth testing, but they do not remove the need to validate recall, handling and output quality on the work we actually have.
OpenRouter’s framing is most useful when we read it as a choice among operating trade-offs while keeping the evidence limit in view.
Three new models: a flagship, an open-source MoE, and a faster variant of the flagship.
OpenRouter X launch thread
MiMo-V2.6 is not compelling because it gives us three names to compare. It is compelling because OpenRouter has framed one family around three different constraints: depth, a leaner MoE shape and output speed from the Pro checkpoint.
The cautious conclusion is also the useful one. The source pack supports a deployment hypothesis, not a verdict on intelligence. We can use that hypothesis to design better tests, then let the work—not the launch framing—decide.
We are assessing Xiaomi MiMo-V2.6 for this task: [describe the task, inputs, output volume, time constraint and validation requirements]. Compare MiMo-V2.6 Pro, Flash and Pro-UltraSpeed only against our stated constraints. Treat Pro as the option OpenRouter describes for agentic coding and long-horizon work; Flash as the 309B MoE with 15B active parameters; and Pro-UltraSpeed as the same Pro checkpoint served at roughly ten times the output speed. Do not infer quality, cost, end-to-end latency or reliability from those descriptions. Recommend the variant to test first, explain the trade-off, and give a small validation plan using representative inputs before production use.Ready to copy
OpenRouter says further details of Xiaomi’s training run will be open-sourced over the coming weeks. Until those details arrive, treat the current material as a bounded release record rather than a complete technical case.
For a real deployment decision, compare the variants on representative tasks and record quality, task time, failure modes and review effort. That is the evidence we need.
Try the prompt