If you do one thing to your Claude bill this quarter, make it routing. Of every optimization lever available, sending each request to the right model instead of running everything on the most capable one is the change that moves the invoice most. The number is not marketing. Across a realistic enterprise workload, disciplined routing across Opus, Sonnet, and Haiku typically cuts aggregate spend by forty to seventy percent compared with uniform use of Opus. This is a buyer side guide to why that range is real and how to capture it.
We negotiate with Anthropic and optimize the spend beneath the contract, so this is written from what actually lands on invoices. The audience is both the engineering leader who will build the routing and the procurement leader who needs to understand why the savings are this large before committing to a spend tier.
The default in most organizations is to send every request to the strongest model. It is the path of least resistance, nobody gets blamed for using the best model, and early in a project the cost is invisible. But the strongest model is also the most expensive per token, often by a wide margin, and most real traffic does not need it. When a workload runs everything on Opus, it pays the top rate for a large volume of work that a cheaper model would have handled at the same quality.
That gap between what the work needs and what it is being charged is the entire saving. The forty to seventy percent range is simply the cost of the requests that were overpaying, returned to you once each one is matched to the model that fits it. The wider end of the range belongs to workloads with a lot of simple, high volume traffic. The narrower end belongs to workloads that genuinely lean on the model's hardest reasoning.
Routing well starts with knowing what each tier is actually good at, so you can match work to model deliberately rather than defaulting upward.
The mistake is treating these as a quality ladder where higher is always safer. They are a fit problem, not a ranking. The cheapest model that clears the quality bar for a given task is the correct model for that task, and for most tasks that is not Opus.
Routing does not require anything exotic. The practical approach is to classify requests by the kind of work they represent and assign each class to a model. Some classes are obvious from the endpoint or the feature they belong to. Others can be decided by a lightweight check on the input before the main call. The point is that the routing decision is cheap and the saving it unlocks is large, so even a simple rule set captures most of the benefit.
A common and effective pattern is to default the bulk of traffic to Sonnet, push the high volume simple work down to Haiku, and reserve Opus for the specific request types that demonstrably need it. Start there, measure quality on each class, and only move work up a tier where the data shows the cheaper model is genuinely falling short. The instinct to route everything to the top model out of caution is exactly the instinct that produced the bill you are trying to cut.
The objection to routing is always quality, and it deserves a real answer rather than a reassurance. The answer is measurement. Before you move a class of work to a cheaper model, define what good looks like for that class and test the cheaper model against it. For most classes the cheaper model passes easily, because the work was never hard enough to justify the top tier. For the few classes where it does not, you keep them on the stronger model. Routing decisions made on measured quality, not on nerves, capture the saving without the regression everyone fears.
This is also where the engineering and procurement views meet. The engineering leader owns the quality bar and the tests. The procurement leader owns the spend that the routing returns. When both can see that quality held while cost fell, the routing stops being a risk and becomes simply the correct way to run the workload.
Routing is the largest lever, but it does not work alone. Once a request is on the right model, caching its repeated context drops the input cost again, at up to ninety percent off the cached portion. Sending the latency tolerant share through batch halves it once more. The savings multiply, so a request that is routed to Sonnet, cached, and batched costs a small fraction of the same request run naively on Opus in real time. Routing is where you start because it has the biggest single effect and shapes everything downstream, but the full forty to seventy percent is routing working together with the rest.
There is a commercial reason to route before you negotiate a spend commitment, not after. A buyer who commits to a tier based on unoptimized, uniform Opus usage locks in a number that routing will then shrink, leaving them committed to spend they no longer have. Routing first means you forecast and commit against the optimized figure, which is often a tier lower and far safer. The lever that cuts your bill also protects your commitment, which is why it belongs at the front of any cost program.
Two objections stall most routing programs, and both deserve a direct answer. The first is that maintaining routing logic is a burden. In practice the logic is light, a classification of request types and a mapping to models, and it changes rarely. Set against a forty to seventy percent saving on a major line of spend, the maintenance cost is trivial, and the routing rules tend to stabilize quickly once the quality tests are in place.
The second objection is that a user might occasionally get a slightly weaker answer on a cheaper model. This is where measurement replaces fear. For the request classes you route down, you have already tested that the cheaper model meets the quality bar, so the risk is bounded by your own thresholds rather than left to chance. And for the small set of classes where quality genuinely matters more than cost, you keep them on the stronger model. Routing is not a blanket downgrade, it is a deliberate match of each task to the cheapest model that clears its bar, with the hardest work still going to the top tier.
Routing is not a one time project, it is a system that pays dividends as the model lineup evolves. When a new model arrives, or an existing one is repriced, the routing layer is the single place you adjust to capture the change, and every workload behind it benefits at once. A team without routing has to revisit each workload individually whenever the economics shift. A team with routing changes one mapping and the whole estate follows.
This is why routing belongs at the center of a cost program rather than at the edge. It is the control surface for your entire Claude spend, the place where a single decision, which model handles which work, propagates across everything. Build it once, measure the quality on each class, and you have not only captured today's forty to seventy percent saving but also given yourself the lever to capture tomorrow's, automatically, as the market keeps moving in the buyer's favor.
Model routing is the single most powerful way to cut a Claude bill, returning forty to seventy percent of aggregate spend by matching each request to the cheapest model that meets its quality bar. Build it on measured quality rather than fear, default most traffic to Sonnet with Haiku underneath and Opus reserved for the hard work, and layer caching and batch on top so the savings compound. Do it before you commit to a spend tier, and the same lever that lowers your invoice also right sizes your commitment.
Get a quote for a bounded engagement. Fixed fee or gainshare, no risk to you.
Get a QuoteWeekly intelligence on Anthropic pricing moves and the buyer side counters that work.