Blog · 2026-08-08 · Vynaris Team

MiMo-V2.5's up-to-99% price cut: what 93% cache hits actually prove

MiMo-V2.5's cache-hit economics audited: 93% sensitivity cuts a long-context task bill 87.6%, but public data cannot explain the full 99%.

MiMo-V2.5's “up to 99%” price cut is real at the sticker, but public evidence cannot attribute a 99% task-cost cut to its inference stack. On our 200k-input/4k-output workload, a 93% billed-token hit sensitivity cuts MiMo-V2.5 from $29.1200 to $3.6008 per 1,000 tasks, 87.6%. Xiaomi does not publish the denominator needed to tie that result to provider cost.

Prices verified 2026-08-08.

TL;DR

• MiMo-V2.5 charges $0.0028 per 1M cache-hit input tokens, $0.14 per 1M cache-miss input tokens, and $0.28 per 1M output tokens. Its hit rate is 50x cheaper than its miss rate.
• MiMo-V2.5-Pro charges $0.0036/$0.435/$0.87 per 1M hit/miss/output tokens. Its hit rate is 120.8x cheaper than its miss rate.
• Xiaomi's paper reports a 93% average server-side KV cache hit rate. It does not say that 93% of customer input tokens receive the cache-hit billing rate. We model 93% as sensitivity, not fact.
• The paper's roughly 7x lower attention compute and KV storage, 25% higher L2 hit rate, and 30% higher per-node input throughput are separate engineering measurements. They are not a derivation of the 99% price cut.

Verdict table

Question                                             Public answer                                   Billing consequence
---------------------------------------------------  ----------------------------------------------  --------------------------------------------------------------------
Is the cache-hit sticker unusually low?              Yes: $0.0028/MTok on V2.5; $0.0036/MTok on Pro  50x and 120.8x below each model's miss rate
What does a 93% billed-token sensitivity cost?       V2.5: $3.6008/1k tasks; Pro: $10.2396/1k        87.6% and 88.7% below all-miss bills
Does the 93% paper metric equal billed-token share?  Not established                                 Instrument actual hit-billed tokens before forecasting savings
Does 7x lower KV cost mean 7x lower provider cost?   No                                              Model weights, MoE, networking, idle capacity and output remain
Can public data explain the full up-to-99% cut?      No                                              GPU inventory, utilization, pre/post unit cost and margin are absent

The right conclusion is narrow. Xiaomi published enough engineering detail to make a steep cache-hit discount credible. It did not publish enough financial detail to decompose the price cut.

The workload we priced

We use a long-context agent continuation. Think of a coding or research agent that repeatedly sends a stable repository snapshot, instructions and prior tool trace. This shape rewards prompt caching without pretending every token hits.

Assumption               Value                         Why it is editable
-----------------------  ----------------------------  --------------------------------------------------------------------
Input tokens per task    200,000                       A long continuation, still inside MiMo's published 1M context window
Output tokens per task   4,000                         A substantial answer or tool plan
Tasks in reporting unit  1,000                         Turns small per-call prices into an operating number
Cache-hit token share    0%, 25%, 50%, 75%, 93%, 100%  Sensitivity; 93% is not asserted as the billing share
Models                   MiMo-V2.5, MiMo-V2.5-Pro      Both appear on Xiaomi's current model and pricing page

The cost equation is:

task cost = input tokens × (hit share × hit price + miss share × miss price) / 1M + output tokens × output price / 1M

For MiMo-V2.5 at the 93% sensitivity:

200,000 × (0.93 × $0.0028 + 0.07 × $0.14) / 1M + 4,000 × $0.28 / 1M = $0.0036008/task

The same arithmetic produces $3.6008 per 1,000 tasks. Change the token shape in the LLM cost calculator when your trace is shorter, more output-heavy or less repetitive.

The input token cost uses the weighted hit/miss rate. The output token cost never receives that discount.

Cost per long-context task

Model          Billed-token hit share  Effective input $/1M  $/task      $/1,000 tasks  Saving vs all miss
-------------  ----------------------  --------------------  ----------  -------------  ------------------
MiMo-V2.5      0%                      $0.140000             $0.0291200  $29.1200       0%
MiMo-V2.5      50%                     $0.071400             $0.0154000  $15.4000       47.1%
MiMo-V2.5      93% sensitivity         $0.012404             $0.0036008  $3.6008        87.6%
MiMo-V2.5      100%                    $0.002800             $0.0016800  $1.6800        94.2%
MiMo-V2.5-Pro  0%                      $0.435000             $0.0904800  $90.4800       0%
MiMo-V2.5-Pro  50%                     $0.219300             $0.0473400  $47.3400       47.7%
MiMo-V2.5-Pro  93% sensitivity         $0.033798             $0.0102396  $10.2396       88.7%
MiMo-V2.5-Pro  100%                    $0.003600             $0.0042000  $4.2000        95.4%

The headline breaks on output. At 93%, output is 31.1% of the V2.5 task bill and 34.0% of the Pro bill. Even a perfect input-cache hit cannot cut this workload by 99%: the maximum modeled reductions are 94.2% and 95.4%. That is why cost per task beats a single discounted token sticker.

Our earlier prompt-caching production audit makes the same operational point across providers: cache eligibility, retention and billing evidence must all line up. A stable prefix in your application does not guarantee a server-side hit.

What the inference paper actually proves

Xiaomi's paper is unusually detailed for a provider serving stack. It gives us mechanisms and measurements, not a cost ledger.

Hybrid attention lowers a specific part of the bill

MiMo-V2.5-Pro has 70 layers: 10 full-attention layers and 60 sliding-window layers with a window of 128 tokens. The paper estimates Hybrid Sliding Window Attention at roughly one-seventh of full attention for attention compute and KV storage. That is an 85.7% reduction in those two components: 1 - 1/7.

This does not make total inference 85.7% cheaper. Sparse mixture-of-experts compute, model-weight reads, network transfers and unused capacity still exist. The paper says actual cost ratios do not strictly follow KV-size ratios, especially on short sequences.

Cache capacity and cache reuse are different levers

The SWA-aware cache system constrains sliding-window storage and reports roughly 7x better capacity efficiency. Decode-side changes raise effective KV capacity by about 5x. More capacity extends cache retention, which makes reused prefixes more likely to survive.

That chain supports the reported 93% average server-side hit rate under mainstream agent harnesses. Heavy sustained users reportedly exceed 95%. It still does not establish the customer-side share of tokens billed at $0.0028 or $0.0036. The paper does not publish that invoice field.

Affinity routing improves throughput, conditionally

Xiaomi's cache-affinity scheduler reports approximately 25% higher L2 hit rate and 30% higher per-node input throughput. If node-hour cost and utilization stayed fixed, 1.30x throughput would reduce capacity cost per input token by 1 - 1/1.30 = 23.1%.

That 23.1% is a conditional derivation, not an observed provider saving. We lack the baseline L2 hit rate, L3 miss penalty, utilization and node cost. We also cannot stack the 30% throughput result with the paper's 40% end-to-end gain from halving expert parallelism. The experiments can overlap.

The scheduler also trades cache affinity against load. Pure affinity can create hot workers; pure balancing destroys reuse. This throughput-versus-latency tradeoff is why a cache router needs both prefix match and normalized load in its score.

What the paper cannot prove about the 99% cut

The missing fields are the commercial denominator:

• Original price by token category. The announcement states a maximum cut up to 99%, but its live text does not expose a machine-readable pre/post table we can recompute today.
• Absolute GPU and storage cost per 1M tokens before and after the stack changes.
• GPU type, node count, fleet utilization and mix of input versus output traffic.
• How cache-hit billing maps to the paper's server-side hit metric.
• Gross margin before and after the price change.

Without those fields, “7x KV reduction + 30% throughput = 99% price cut” is false arithmetic. Provider price includes strategy, demand stimulation and margin, not only compute.

This is also why our long-context surcharge analysis treats context window thresholds and cache behavior separately. Long context can improve cache economics while still increasing uncached attention work.

How to verify cache billing before committing spend

Run a controlled replay with a byte-stable prefix and a changing suffix. Save the provider's raw usage response beside each request. Do not rename a generic “cached” field into dollars until the billing documentation defines it. Some serving metrics count requests with any prefix reuse; a bill needs token quantities by price category.

Next, repeat the same request after your normal idle interval. A warm back-to-back test can overstate the hit share your real workload receives. Compare the replay's calculated cost with the provider usage export for the same time window. The invoice is the reconciliation layer.

Finally, segment by workload. Repository agents, shared system prompts and repeated document analysis may produce different hit shares even on one account. A global 93% average can hide a cold workload paying the miss rate. Budget from the lower tail of your own billed-token distribution, then treat better cache performance as upside. This test costs less than discovering a forecast error after launch.

Routing decision: measure the invoice field

Use three counters per model and workload: fresh input tokens, cache-hit input tokens and output tokens. Then compute the weighted rate from the equation above. Do not copy 93% into a budget spreadsheet unless Xiaomi's usage response confirms the same definition.

Choose MiMo-V2.5-Pro only when your evaluations show that its quality avoids enough retries or human review to cover the 2.84x modeled task premium at 93%: $10.2396 / $3.6008. Sticker price alone picks V2.5. Outcome quality may pick Pro.

For eligible coding-tool workloads, the separate MiMo Token Plan break-even audit shows why the monthly Max subscription beats these pay-go rates only above 87.1% quota use on mimo-v2.5.

For multi-call agents, cache share is only one term. Growing history and retries can dominate even after the stable prefix hits. Our agent workflow cost forecast shows how call count and triangular history change the bill before model choice.

Honest tradeoff: when cache affinity is not worth chasing

Do not engineer application-level affinity for low-reuse prompts. One-shot extraction, unrelated user chats and rapidly changing prefixes have little shared KV to recover. A cheaper miss rate or smaller model matters more. Extra stickiness can also overload one worker and worsen time to first token.

For repeated coding-agent sessions, shared system prompts and recurring tool traces, the opposite holds. Cache-hit pricing is too different to ignore. Measure hit-billed tokens, keep prefixes byte-stable and alert when the hit share drops.

FAQ

Did Xiaomi cut all MiMo-V2.5 prices by 99%?

No. Xiaomi says the maximum reduction was up to 99%. A MiMo team member says the deepest cut applied to cache-hit input. Current hit, miss and output rates remain separate.

Does a 93% cache hit rate reduce the API bill by 93%?

Not necessarily. On our 200k-input/4k-output task, a 93% billed-token sensitivity cuts total cost by 87.6% on V2.5 and 88.7% on Pro. Output does not receive the input-cache discount.

Is the paper's 93% hit rate the same as the API billing metric?

The public paper does not establish that equivalence. Treat it as server-side evidence. Use the API's usage fields for customer billing.

Does 7x lower KV storage mean 7x cheaper inference?

No. It reduces one storage and memory-bandwidth component. Model weights, MoE compute, networking, output decode and idle capacity remain.

What should we monitor in production?

Fresh input tokens, cache-hit input tokens, output tokens, retries and latency by workload. Recompute dollars per task from those counters each day.

Sources

• MiMo-V2.5 Series price adjustment announcement, captured 2026-08-08: current model names and rates; announcement says the maximum price reduction was up to 99% and became effective 2026-05-27.
• Full-Pipeline Inference Optimization for MiMo-V2.5 Series, captured 2026-08-08: Hybrid SWA ratios, 93% server-side cache hit rate, affinity-routing measurements and serving-system caveats.
• Fuli Luo's MiMo price-cut note, captured 2026-08-08: the deepest up-to-99% cut applied to cache-hit input and was attributed to hierarchical SWA KV-cache work.

All workload arithmetic is in the accompanying Python script. No Vynaris traffic, customer or routing data is used.