I routed two weeks of coding to a model 25x cheaper than Opus. The model wasn't the slow part.

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).

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.

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:

I read the review feedback that sent orders back. Nearly all of it falls into five groups:

1. Failing silently: a missing column, a join that matched zero rows or a button that wasn't found, all treated as success.
2. Data edge cases: duplicate rows, a date that's object on one side and str on the other, and tickers like NA and NULL that pandas quietly reads as NaN.
3. 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.
4. New behaviour with no test, or a runbook left describing the old behaviour.
5. Matching too loosely: a substring check for selected that also hits unselected, 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:

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 wait command 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 replaces sleep 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 ([email protected]). If you've measured your own split, I'd like to compare numbers.