For two weeks, Claude planned and reviewed my code changes and Xiaomi's MiMo-V2.6-Pro wrote them. That was 95 work orders across 14 of my repos, and 62 of them merged. At list prices, MiMo's side of those 62 changes cost $14.22. The same tokens at Claude Opus 5.5 prices come to $355.
The catch is time. A merged change took 52 minutes from order to merge (median). MiMo was working for less than half of that.
The setup
A dispatcher I wrote (about 10,000 lines of stdlib Python) runs each order in its own git worktree and branch, inside a macOS seatbelt sandbox that can only write to that worktree. Claude writes the order, MiMo implements it and runs the project's checks, Claude reviews the diff and either sends it back with feedback or merges it locally. Nothing gets pushed without me.
Every order leaves a state file and the worker's full event log, with timestamps and token counts for each model call. All the numbers below come from those files, for orders created 11 to 23 October 2026.
Where the time went
I could rebuild the full timeline for 33 merged orders (four more sat overnight and I left them out).
| Stage | Share of wall-clock | Median |
|---|---|---|
| Waiting in the queue | 5% | 0.1 min |
| MiMo working | 49% | 30.7 min |
| Between rounds (review, feedback, waiting) | 27% | 6.4 min |
| Last round finished → merged | 20% | 11.2 min |
The orders that passed on the first round make it plain. MiMo worked for 16 minutes (median) and the order took 42 minutes end to end.
Most of the extra 26 minutes is the orchestrator not looking. Its instructions said to check the queue with sleep 595, then review, then merge. The long interval was there to save Claude tokens. It also left up to ten minutes of dead time every time a worker finished. The merge step adds more: it rebases onto whatever landed in the meantime and reruns the full test suite.
None of this is the model's fault. It's plumbing.
Is the model itself slower?
Less than I expected. I compared MiMo's turns with Claude Opus 5.5 turns from my own Claude Code transcripts. They're different tasks, so read this as a rough comparison, not a benchmark.
| Per model call | MiMo-V2.6-Pro | Claude Opus 5.5 |
|---|---|---|
| Calls measured | 6,640 | 4,537 |
| Seconds per call, median | 6.7 | 7.9 |
| Seconds per call, mean | 21.8 | 13.2 |
| Output speed | 47 tok/s | 81 tok/s |
| Context per call, median | 153K | 467K |
The typical call is as fast. The slow ones are slower, which pulls the mean up. A MiMo attempt ran 37 calls and 15 minutes (median).
The context column matters later. MiMo starts every order from a fresh worktree, so it carries about a third of the context my long Claude sessions do.
The real gap: rework
Only 24 of the 62 merged orders (39%) went through on the first round. The rest needed one to six more. Each round means another attempt, another review and another wait, and the token bill climbs fast:
| Rounds to merge | Orders | Median tokens |
|---|---|---|
| 1 | 24 | 3.6M |
| 2 | 20 | 8.9M |
| 3 | 8 | 14.8M |
| 4 or more | 10 | 31.0M |
I read the review feedback that sent orders back. Nearly all of it falls into five groups:
- Failing silently: a missing column, a join that matched zero rows or a button that wasn't found, all treated as success.
- Data edge cases: duplicate rows, a date that's
objecton one side andstron the other, and tickers likeNAandNULLthat pandas quietly reads as NaN. - Tests that can't fail. One asserted that a static header string was present in the output. Another wrote into the repo's real output folder. One took 113 seconds against a 60-second limit.
- New behaviour with no test, or a runbook left describing the old behaviour.
- Matching too loosely: a substring check for
selectedthat also hitsunselected, or "click the first OK button on the page".
None of these are hard to get right. They weren't in the order, and the worker didn't go looking for them. A stronger model goes looking more often. That's most of what you pay Claude for.
The cost math
Here's the token mix across the 62 merged orders: 97.8% cache reads, 0.56% output. An agent re-reads its whole context on every call, so the token count is roughly calls × context size. It has little to do with how much code gets written.
That makes the cache-read price the one to compare, and the headline price misleads:
| Per 1M tokens | MiMo-V2.6-Pro | Claude Opus 5.5 | Ratio |
|---|---|---|---|
| Input | $0.435 | $4.00 | 9× |
| Cache read | $0.0036 | $0.20 | 56× |
| Output | $0.87 | $20.00 | 23× |
On my mix the blended ratio is 25×. A merged change cost MiMo $0.17 at list price (median) against $3.83 for the same tokens at Opus prices. Even the orders that took four or more rounds stayed far cheaper than handing the job to Claude. And Claude doing the work inside my planning session would carry three times the context per call, so its real bill would be higher still.
I pay for both through subscriptions, not per token, so list prices are a yardstick here, not my invoice. Xiaomi's Token Plan page doesn't say how cache hits count against the monthly quota. Check that before you rely on a ratio.
The money that actually leaks is on the orchestrator side. Every time Claude wakes up to poll, it re-reads its own large context. Ten polls on a 300K-token session is 3M Claude tokens spent on checking whether anything happened.
What I'm changing
Three changes, all dispatched to MiMo this morning (yes, through the same queue):
- A
waitcommand that blocks until an order changes state and returns at once. It's read-only, so the orchestrator can run it over a mounted path from a VM. That replacessleep 595. - An automatic review as soon as an order's checks pass, run by Claude Sonnet in headless restricted mode. That means no shell, file reads confined to the review worktree and no MCP servers. The verdict is waiting by the time the orchestrator looks.
- A self-review section in every implementation prompt built from the five groups above, plus an order template with a mandatory "Failure modes" section. Cheap tokens make a self-check worth running.
Two of the three merged after two review rounds. The reviewer change took nine. It runs outside the sandbox, and for four rounds in a row a reviewer found another way a file planted in the repo could get executed through PATH. In the end I dropped the PATH lookup instead of patching it again. That one order used 127M tokens, about $1.02 at MiMo list prices. At Opus prices the same tokens would have cost more than all 62 orders above did on MiMo.
The aim is to get first-round merges from 39% to about 60% and take 20 to 25 minutes off a typical order. I'll post the before and after once there are enough orders to compare.
Limits
- One person, 14 repos, two weeks, mostly Python. Your mix of work will differ.
- The Claude timing comes from different tasks than MiMo's, so it says something about speed and nothing about quality.
- Rounds are counted from the worker's event logs. The wall-clock breakdown covers the 33 orders with complete timestamps.
- Prices are list prices checked on 25 October 2026: Xiaomi's rates as listed on OpenRouter, Anthropic's from its pricing page.
If you're splitting work between a planner model and a cheaper worker, measure the gaps between steps before you shop for a faster model. I do this kind of measurement as a routing audit (info@zhuojun.li). If you've measured your own split, I'd like to compare numbers.
Top comments (4)
The rework table is the whole story and I'm glad you broke it out — 39% first-round merge, and the token bill roughly doubling per extra round, matches what we see on a near-identical planner/implementer split. The counterintuitive part for anyone copying this: making the cheap model "try harder" barely moves the first-round rate, because most of your five failure buckets (silent failures, pandas reading
NA/NULLas NaN, tests that can't fail) aren't capability gaps — they're missing-context gaps. The implementer starts from a fresh worktree with ~1/3 your context, so it never had the information to get it right the first time.The lever that worked for us was front-loading that context into the order itself — having the planner attach the specific invariants it expects the diff to preserve ("this join must match >0 rows", "assert the column exists") so the review criteria are visible before implementation, not after. It pushed first-round merges up without touching the model.
Separately: that
sleep 595polling interval is pure dead time — have you tried an event/callback from the worker on completion instead of fixed polling? That alone looked like it'd reclaim most of your 27% "between rounds" slice.The sleep 595 line is the one I recognised. Our orchestrator holds a realtime socket connection to the ticket service, so it wakes on the change instead of on a timer, and the waiting is plain code, not Claude tokens. Your merge step reads the same way to me: rebase, rerun the suite, merge are steps a script does identically every time. Once the wait command lands, does the 11-minute finished-to-merged stage shrink too, or is most of it the test suite?
Great data, especially the 97.8% cache-read share. That's the number most price comparisons skip.
On the orchestrator leak, the interval itself matters as much as the polling. Anthropic's default prompt cache lasts about 5 minutes, so with sleep 595 almost every wake-up arrives after the cache has expired, and Claude re-writes the whole 300K context instead of reading it. At the Opus prices in your table, a 5-minute cache write is 1.25x input, so about $1.50 per cold wake-up vs about $0.06 for a warm read, roughly 25x.
That has a consequence for the wait command too. It removes the dead time, but if it blocks for 20 minutes, the next Claude turn is still cold. A cheaper pattern can be to cap each wait at about 4.5 minutes and re-issue it: a few warm reads at about $0.06 each cost less than one cold write. That's rough, it ignores the small output per call, and it's quota rather than dollars on a subscription.
Easy to check from your existing logs: put cache_creation_input_tokens next to cache_read_input_tokens for each orchestrator turn, bucketed by the gap since the previous turn. If the big writes all come after gaps of more than 5 minutes, that's the leak. Also check which TTL your harness uses, since a 1-hour cache changes the math.
Ran it, and the TTL mattered more than the interval. The transcripts of the exact orchestrator session that used sleep 595 aren't on disk, so this is the nine Claude Code sessions since 10 October that drove the same dispatcher: 3,360 assistant turns, almost all Opus.
Every cache write in them is on the 1-hour TTL, none on the 5-minute one. Bucketed by the gap since the previous turn:
So a ten-minute wake-up stayed warm here: only 1 of the 146 turns after a 5-60 minute gap rewrote more than 50K tokens. The big rewrites are the turns after an hour or more (77 of the 79), and those go cold whatever the polling interval is. Your 4.5-minute cap is the right fix on a 5-minute TTL. On this setup it would add wake-ups without saving a cold write.
Caveats: gaps are measured between consecutive assistant timestamps, so they run a little short of the real idle time. And I haven't confirmed which TTL the orchestrator used while the article's polling ran, so I wouldn't generalize past these nine sessions.