Every guide to reducing LLM costs carries the same recommendation: use a cheaper model for the easy work. Cascade systems, model routers, "use Haiku for classification." The advice is everywhere, and reported savings run from 30% to 87%.
It ran for 34 days and the result was measured. It saved 0.89%.
What it actually cost
| Model | Calls | Cost | Share of spend |
|---|---|---|---|
| Haiku 4.5 | 405 | $4.63 | 0.07% |
| Sonnet 5 | 631 | $30.10 | 0.47% |
| Sonnet 4.6 | 558 | $23.11 | 0.36% |
| Cheap tier combined | 1,594 | $57.84 | 0.89% |
Opus-tier models took the other 21,563 calls and $6,407.28, or 99.1% of spend.
Look at the shape. 6.9% of calls, 1.68% of tokens, 0.89% of cost. Each step down is smaller than the last, and that progression is the whole finding.
Why routing fails on agentic work
The advice holds up fine. It just answers a different question than the one an agentic workload asks.
Cost on this kind of workload is dominated by context volume rather than per-token price. The calls that cost money are the ones dragging a large working context: a codebase, a document set, a long tool-call chain. Those are precisely the calls you can't demote, because they're the ones that need the capable model.
You route the small jobs to the cheap model because they're small. Then you're surprised that moving small jobs saved a small amount.
It's close to circular once you see it. Routing selects for low-context tasks, low-context tasks were never expensive, so the saving is bounded by how little they cost to begin with. Haiku handled 405 calls for $4.63, under a cent and a half each. There was no meaningful money there to save.
What the 30–87% figures are measuring
Those numbers are real, but they come from a different workload shape: high-volume, low-context, repetitive calls like classification, extraction and moderation. Millions of short prompts where per-token price genuinely is the dominant term and context barely matters.
If that's your workload, route aggressively and the reported savings will hold. If your workload is agentic, the same technique addresses under 1% of your bill while adding a router, a fallback path, and a quality risk on every misrouted call.
Check before you build a router
- Total your spend by model for a week. What share is already on cheap models?
- Look at cost per call by tier. If your cheap tier is under a cent or two, there's nothing to recover.
- Compare token share to call share. If 7% of calls are 1.7% of tokens, routing is selecting for the wrong thing.
- Attack context size instead. On a cached workload that's where the money is.
- None of this applies to high-volume, low-context work like classification or extraction. There, routing genuinely does deliver the headline numbers.
The routing stays. It costs nothing to leave in and the quality is fine for what it handles. But it was assumed to be doing real work, and it wasn't. Better to publish that than quietly keep the assumption.
Method & disclosure
From the same dataset as the 34-day cost study — 381 session transcripts, 23,157 billable calls, 18 June to 3 August 2026, de-duplicated by message ID. Per-model call counts and token counts are actual.
Costs are calculated: published per-model list rates applied to measured tokens, cache reads at 0.1× input and writes at 1.25× on the five-minute TTL. Sonnet 5 is costed at its introductory rate, which covers this window.
One limitation. Routing here was manual and conservative, rather than an automated cascade with a confidence threshold. A more aggressive router would move more calls, but it would still be selecting low-context work, which is the actual constraint.
No commercial relationship with any vendor named. No affiliate arrangement on anything in this piece.