Cost optimization usually means routing down to a cheaper model. But the cheapest sticker price is not always the cheapest outcome. On some tasks the bigger model is the frugal choice once you count the retries, escalations, and review time the cheap model creates.
The standard advice on Claude cost is to route work down to the cheapest capable model, and most of the time that advice is right. But taken as a reflex rather than a calculation, it leads teams into a trap, which is assuming that the model with the lowest per token price is always the cheapest model to run. That assumption holds only when the cheap model gets the answer right. When it does not, the true cost of using it includes everything that happens because it was wrong: the retries, the escalations to a stronger model, the validation overhead, the human review, and sometimes the much larger cost of a bad answer reaching a customer or a decision. On certain tasks those downstream costs are large enough that the bigger model, despite its higher sticker price, is the genuinely frugal choice. Knowing how to spot those tasks is as much a part of good optimization as knowing when to route down.
The error at the root of over routing down is treating the per token price as the cost of the request. It is only the cost of one successful attempt. The cost of getting a correct, usable result is the price of however many attempts and corrections it takes to get there. If a cheaper model needs to be retried, or its output has to be checked and fixed, or a fraction of its requests fail and escalate to a more expensive model anyway, then the effective cost per correct result is much higher than the sticker price suggests. On a task where the cheap model is reliable, those corrections are rare and the sticker price is close to the truth. On a task where the cheap model struggles, the corrections dominate, and the sticker price is a fiction. The discipline is to price the correct result, not the attempt.
Consider the common fallback pattern, where a request starts on a cheap model and escalates to a stronger one when the cheap model signals it cannot handle the task. This pattern is excellent when the cheap model succeeds most of the time, because you pay the cheap rate on the majority and the expensive rate only on the difficult minority. But its economics invert as the escalation rate climbs. If half the requests escalate, you are paying for two model calls on half your traffic, the cheap attempt plus the expensive retry, which can cost more than simply sending everything to the stronger model once. There is a crossover point, and past it the fallback pattern is more expensive than going straight to the bigger model. Teams that set up fallback and never measure the escalation rate often sit past that crossover without realizing they are paying the escalation tax on top of the bigger model cost they were trying to avoid.
There is a second, subtler way the bigger model can be cheaper, which is that it sometimes does the job in fewer tokens. A more capable model can often reach a correct, complete answer more directly, with less rambling, fewer clarifying detours, and less redundant reasoning, while a weaker model may need a longer output or several turns to arrive at the same place, if it gets there at all. Because output tokens are the expensive side of the bill, a model that produces a tight correct answer in one pass can cost less per result than a cheaper model that produces a sprawling answer or needs multiple turns. The per token rate is higher but the token count is lower, and the product, which is what you actually pay, can favor the bigger model. This is most pronounced on complex tasks where the weaker model's path to the answer is long and uncertain.
Some task profiles reliably favor the more capable model on total cost, and they are worth recognizing so you do not route them down by reflex:
In all of these, the cheap model's apparent saving is borrowed against a downstream cost that is larger than the saving, and the bigger model is the honestly cheaper option.
The reason this is a middle of funnel decision rather than a rule of thumb is that the crossover depends on numbers specific to your task, and you have to measure them. You need the cheap model's accuracy on a representative test set, the cost of each correction path, retry, escalation, review, and rework, and the rate at which those paths fire. With those, you can compute the effective cost per correct result for the cheap model and compare it to the bigger model's cost per correct result. Sometimes the cheap model still wins comfortably and you route down with confidence. Sometimes the comparison reveals that the cheap model only looked cheap and the bigger model is the better buy. Either way the decision rests on measured numbers, not on the instinct that cheaper is always cheaper. This is the same accuracy per dollar discipline applied with the full downstream cost included.
This matters beyond the engineering bill, because it shapes what you should commit to and how you should talk about your spend. A team that has measured where the bigger model is genuinely cheaper can defend its model mix to finance with evidence, rather than being pushed to route everything down to hit a crude cost target that would actually raise total cost through rework. It also means your committed spend reflects the real optimal architecture, not a falsely deflated number that you will blow through the moment the rework costs show up. Good optimization is not minimizing the sticker price line, it is minimizing the total cost of correct results, and sometimes that means deliberately spending more per token to spend less overall.
Knowing when a bigger model saves money is the mature half of model selection, the counterweight to routing down, and it keeps optimization honest about total cost rather than sticker price. It works hand in hand with accuracy per dollar measurement, fallback design, and output control. For the full method, including how to find your crossover point and price your correction paths, read the pillar guide, the token optimization playbook. If you want this measured against your real workload, book a strategy call and we will find where your model mix is leaving money on the table in either direction.
Bring us your workload and we will measure the crossover, price your correction paths, and tell you exactly where the bigger model is the frugal choice.
Book a Strategy CallWeekly intelligence on Anthropic pricing moves and the buyer side counters that work.