Pricing
Xiaomi MiMo: what you get for the money
A 1M-context omnimodal model at roughly a fiftieth of frontier pricing. Where that trade is worth making, and where it very much is not.
- Published
- 11 Aug 2026
- Reading
- 10 min
- Class
- pricing
half-life 45dfrom 11 Aug 2026
Disclosure
The MiMo Open Platform link in this piece is a referral link carrying an invite code — signing up through it gets you $2 in API credits and 10% off your first plan, and gets this site credit. Prices below are from third-party model directories rather than Xiaomi's own page, which renders client-side and could not be read directly. Confirm the current rate before you budget against it.
The interesting thing about Xiaomi's MiMo line is not that it is cheap. Plenty of models are cheap. It is that it is cheap and omnimodal and ships a 1M-token context window — a combination that until recently meant frontier pricing.
Whether that is a bargain or a false economy depends entirely on what you are pointing it at. This is an attempt to be specific about which.
What it costs
Published rates vary by provider, which is itself worth knowing — MiMo is served through several routing platforms and they do not agree.
| Model | Input / MTok | Output / MTok | Context |
|---|---|---|---|
| MiMo V2.5 | ~$0.11–0.14 | ~$0.22–0.28 | 1M |
| MiMo V2.5-Pro | ~$0.43 | ~$0.87 | 1M |
| Claude Sonnet 5 (reference) | $2.00 | $10.00 | 1M |
| Claude Fable 5 (reference) | $10.00 | $50.00 | 1M |
Standard V2.5 lands somewhere around a fortieth of Sonnet 5's output price and close to a two-hundredth of Fable 5's. Even the Pro tier is roughly an order of magnitude under Sonnet.
There is also aggressive cache pricing — reported cache-hit input rates are a rounding error against the cache-miss rate. If your workload has a large stable prefix, that changes the arithmetic considerably, and it rewards exactly the context discipline that good context engineering demands anyway: stable content first, volatile content last.
Where the money actually goes
Here is the part that gets skipped. In an agent loop, cost is not dominated by the per-token rate. It is dominated by how many turns the loop takes, and that is a capability question.
A cheaper model that needs three extra tool calls to get to the same place, and re-reads a large context on each one, can cost more in absolute terms than the expensive model that got it right first time. It will also take longer in wall-clock, and the failures it does produce arrive later in the process where they are more annoying to unpick.
Load-bearing
Do not compare price per token. Compare price per completed task on your own workload. A fortieth of the token price is not a fortieth of the bill if the loop runs four times as long, and on agentic work it often does.
Where MiMo is a straightforwardly good deal
- High-volume, low-stakes classification. Routing tickets, tagging content, first-pass triage. Enormous volume, cheap to verify, cheap to get wrong.
- Bulk extraction over documents. The 1M window plus a very low input rate is a genuinely strong combination for pulling structured data out of large piles of text.
- Omnimodal work at volume. Image and video understanding at this price point is the part with the fewest close substitutes.
- Anything you were not going to build at frontier prices. The most honest case: features whose value never justified $10/MTok become viable at $0.14. That is a new product, not a cost saving.
Where it is a false economy
- Long-horizon agentic work. Multi-step tool use where one bad decision on turn four poisons everything after it. This is where capability differences compound rather than average out.
- Anything writing to production. The cost of a wrong action is not measured in tokens.
- Work you cannot cheaply verify. If checking the output takes a human ten minutes, you have moved the cost from the API bill to the payroll and made it larger.
How to actually decide
Do not take anyone's benchmark, including this one. The evaluation is cheap because the model is cheap:
- Take forty real cases from your own system, weighted toward the ones that have gone wrong before. Your existing regression set is exactly this, if you built one.
- Run them on your current model. Record pass rate, total tokens, total turns, wall-clock.
- Run the same set on MiMo V2.5. Then V2.5-Pro.
- Compare cost per passing case, not cost per token.
At these prices the whole exercise costs less than the hour you will spend arguing about it. If MiMo passes 90% of what your current model passes at a fortieth of the price, the answer is obvious. If it passes 60%, the answer is also obvious, and you have saved yourself finding out in production.
The routing answer
The framing of "which model should we use" is usually wrong. Most mature systems end up with several: something very cheap for the high-volume edges, something strong in the middle where the real work happens, and an escalation path for the cases that fail. MiMo is a strong candidate for the first of those and a plausible one for the second, depending on your workload.
What it is not is a drop-in replacement for a frontier model in an agent loop, and anyone telling you otherwise is quoting token prices at you rather than task completion rates.
MiMo is available through the MiMo Open Platform — that link carries an invite code for $2 in API credits and 10% off a first plan, which is more than enough to run the forty-case evaluation described above.