Every guide to reducing LLM costs contains 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%.
I ran it for 34 days and measured the result. It saved 0.89%.
The numbers
| 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 — 99.1% of spend.
Note the shape: 6.9% of calls, but only 1.68% of tokens, and 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 is not wrong, exactly. It is answering a different question than the one an agentic workload asks.
Cost on this kind of workload is dominated by context volume, not by 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 — and those are precisely the calls you cannot demote, because they are the ones needing the capable model.
You route the small jobs to the cheap model because they are small. Then you are surprised that moving small jobs saved a small amount.
It is 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 in the first place. 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. Classification. Extraction. Moderation. Millions of short prompts where per-token price genuinely is the dominant term and context is negligible.
If that is your workload, route aggressively — 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 is 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 is where the money is
- Not: high-volume low-context work like classification or extraction. There, routing genuinely does deliver the headline numbers.
I am not removing the routing. It costs nothing to leave in and the quality is fine for what it handles. But I had assumed it was doing real work, and it was not — and I would rather 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 worth stating: routing here was manual and conservative, not 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.