# The cheapest model on my plan loses every benchmark. It still beats models charging 14x more. > Source: > Published: 2026-08-21 20:38:31+00:00 The cheapest model I can run on my plan costs **$0.14** per million tokens. The one I actually reach for costs **$0.44**. I put them side by side expecting the cheap one to be *close*. It lost all four benchmarks. Coding, reasoning, math, real-world bug-fixing — four for four. I'm still recommending it. Not because it competes with the good models. Because of what it does to the models in the middle. | MiMo-V2.5 | Deepseek v4 flash | | |---|---|---| | Input / 1M | $0.14 | $0.44 | | Output / 1M | $0.28 | $1.32 | | Requests per 5h window | 30,100 | 7,600 | | Coding | 56.8 | 69.1 | | Reasoning | 38.0 | 51.8 | | Math | 85.0 | 86.0 | | Bug-fixing (SWE-Bench) | 43.1 | 49.9 | Two numbers matter more than the rest. MiMo gives you roughly **four times as many requests** before your window empties, at **a third of the input price**. And it gives up **twelve points of coding ability** to do it. That's the whole decision. Not "which model is better" — which resource you're actually short on. I went in believing the cheap models had quietly caught up. The number I expected to find was a two- or three-point gap. Math cooperated: 85.0 against 86.0. One point. That's noise, and it's a real result — for arithmetic-heavy work the cheap model is simply fine. Reasoning did not cooperate. 38.0 against 51.8 is a **27% drop**, the widest gap of the four. On paper that reads like a rounding difference. In practice it's the difference between a model that follows a four-step refactor and one that loses the thread at step two and confidently ships step three. So "close enough" was wrong, and it was wrong in the direction that costs you the most: the reasoning gap is exactly the gap you feel when you hand a model something ambiguous. The interesting fight was never cheap-versus-best. Look at what sits *between* them. | Model | Coding | Input / 1M | Requests / 5h | |---|---|---|---| | MiMo-V2.5 | 56.8 | $0.14 | 30,100 | | Qwen3.7-Plus | 55.9 | $1.20 | 4,300 | | GLM-5.1 | 55.8 | $1.40 | 880 | | Qwen3.6 Plus | 54.5 | $2.00 | 3,300 | The $0.14 model beats all three. Qwen3.6 Plus charges **fourteen times more per input token** and codes a point and a half worse. GLM-5.1 charges ten times more, scores a point lower, and burns your quota **thirty-four times faster** — 880 requests against 30,100. That's the finding. The floor didn't rise to meet the ceiling. It rose to swallow the middle. Every model priced between one and two dollars is now paying a premium for benchmark scores it doesn't actually have, and the only reason that isn't obvious is that nobody puts price, benchmark, and quota burn in the same row. Which is the entire reason I built the thing. MiMo-V2.5 isn't literally the cheapest model on my plan. There's one below it: **Muse spark 1.2 contributor**, at $0.10/$0.20, with 45,300 requests per window and a coding score of 72.2 — better than DeepSeek, at a quarter of the price. That combination doesn't happen by accident. The word *contributor* is sitting right there in the model name. I don't have documentation explaining the arrangement, so I'm not going to assert one. I'll say this instead: when one model is cheaper, faster-burning, *and* better than everything around it, the price is buying something other than compute. Treat it as an outlier until you know what. Set it aside and MiMo-V2.5 is the floor. Hy3 ties it on input price at $0.14 and actually out-codes it slightly at 58.8 — but charges twice as much on output and gives you 4,300 requests instead of 30,100. The first version of my burn scoring inferred quota cost from price. Cheaper token, slower burn. It seemed obviously true. It was wrong, and it was wrong in an embarrassing direction: it ranked expensive models as quota-hungry even when the provider gave them generous request allowances, and it flattered cheap models that burn through a window fast. I was measuring the thing I could see instead of the thing I cared about. The fix was to stop inferring and start reading — the published request counts per window, straight from the docs. That's when the table started disagreeing with my intuitions, which is when it started being useful. The MiMo-versus-middle finding above only exists because burn stopped being a function of price. There's still a bug I haven't fixed: at the low end, a couple of models render a burn band that disagrees with their own request count. It's on my list. I'd rather say that here than have you find it. Benchmarks are a proxy and a coarse one. A twelve-point coding gap is real, but I can't tell you it maps cleanly onto your codebase, your language, or your prompting habits. Some of these scores come from different evaluation suites and get normalized to sit in the same column — that normalization is a judgment call, and it's mine. Nothing here is hand-curated. Scores, tags, and burn bands are all computed from three upstream sources, so when they update, my conclusions change without my permission. That's the design. It also means I'm occasionally wrong in public. And I have no historical data. I can tell you what the board looks like right now. I can't tell you what moved. I think most people pick a model once, by reputation, and never revisit it — and then spend the rest of the month rationing requests they didn't need to ration. The table is free, needs no account, and links every number back to its source: ** zp.svelte-apps.me** · code at So: **when you're choosing a model, are you short on capability or short on requests?** I've been answering that question wrong for months — optimizing for the smartest model I could afford, then quietly avoiding using it. Curious whether anyone else has caught themselves doing the same thing.