How to Be a Smarter Token Manager: Model Routing, Explained

Abstract visualization of AI model routing across layered network tiers

Two weeks of writing about AI token economics kept leading to the same corner: you cannot control what the vendors charge, only how wisely you spend it. That is the entire case for model routing, and this week it got a perfect teaching example.

On Tuesday, Anthropic launched Claude Sonnet 5, and the whole pitch fit in one sentence: near-Opus performance, at a fraction of the price. Sit with that for a second, because that sentence is the entire case for routing, stated by a frontier lab about its own model lineup.

How the pricing actually works

You pay per token, split into input (what you send) and output (what the model writes back), and output is the expensive side, usually about five times the input rate. Here is the current Claude ladder, per million tokens.

ModelInputOutputNotes
Haiku 4.5$1$5Fastest, cheapest current tier
Sonnet 5 (intro)$2$10Through Aug 31, 2026
Sonnet 5 (standard)$3$15After Aug 31
Opus 4.8$5$25Premium, the common default
Fable 5$10$50Top tier, twice Opus

Two more levers sit on top of that ladder: batch processing takes 50% off, and prompt caching takes up to 90% off the input you reuse. Keep both in your back pocket.

Now, Sonnet 5 specifically. Anthropic’s own benchmark numbers put it close to Opus 4.8, roughly 63 versus 69 on agentic coding and basically tied on knowledge work, at about 40% of the price. That is the headline, and it is real. Here are the two things worth checking before anyone lets a vendor’s pricing banner do the talking. Sonnet 5’s new tokenizer turns the same input into up to 35% more tokens, so a slice of that discount comes right back. And the two-dollar rate is an introductory price that reverts to three and fifteen at the end of August. Real savings are real, you just calculate them on tokens, at the price you will actually pay in September, not the launch banner.

The move: match the model to the task

Here is the whole idea, and it is almost embarrassingly simple. Most AI calls never needed the top model in the first place. Across the deployments we see at Olakai, somewhere between 60 and 80% of the work, the summarizing, the extracting, the routine code, gets handled just as well by a model that costs five or ten times less. This is not a hunch. Researchers at UC Berkeley, Anyscale, and Canva published peer-reviewed routing work (RouteLLM, presented at ICLR 2025) showing roughly 85% cost savings while holding 95% of frontier-model quality, and in practice a well-chosen model pair lands around half the cost at about 98% of the quality. The reason it works is simple: most teams were overpaying on the easy stuff the whole time.

Being a smarter token manager is just this: send each task to the cheapest model that can actually do it, and save the expensive model for the work that truly needs it.

How it plays out with AI coding agents

Coding is where the token bill actually lives for most engineering orgs, so it is worth making this concrete with three scenarios that show up constantly in AI coding tool deployments.

The planner and the executors. A coding agent is not one thing. It is a planner that decides the approach, and a swarm of executors that do the grunt work: writing boilerplate, generating tests, fixing lint, editing files. The judgment lives in the planner, so give it the best model available. The executors are mostly routine, and they run over and over across a long session, which is exactly where tokens pile up. Point the executors at Haiku or Sonnet 5 instead of Opus, and the build gets dramatically cheaper with no drop in the quality that matters. One measured example: a 14-million-token build came in 57% cheaper with the executor on Haiku 4.5 instead of Opus 4.8, and the planner never changed.

Route by difficulty. Not every ticket is hard. Renaming variables, scaffolding a test, a simple endpoint, a formatting pass, that is easy work, and it should go to Haiku. A feature or a mid-size refactor is Sonnet 5 territory. The gnarly stuff, tricky architecture, a subtle concurrency bug, security-sensitive code, is where it makes sense to spend on Opus. On most engineering teams the easy and medium buckets make up the vast majority of tickets, which means most traffic should never touch the frontier model at all.

Watch the loops. Agentic coding burns tokens in a way chat never did, because agents retry, re-prompt, and loop, and every wasted token in turn one gets paid for again on every turn after it. A single long, unoptimized Opus session can run twenty dollars or more; the same session, routed and cleaned up, can be two or three. Multiply that across a twenty-developer team running dozens of sessions a day, and the difference is a five-figure monthly bill that is mostly avoidable. Route the routine sub-steps down, and cap the loops so one stuck agent cannot run up the tab.

The same logic holds outside of code. Summarizing a long document costs about eleven cents on Haiku, fifty-five cents on Opus, and a dollar-ten on Fable, for the same summary. Run a million of those a month and that is a hundred and ten thousand dollars against well over a million. Burning the most capable model on a routine document summary is paying ten times over for an answer nobody can tell apart from the cheaper one.

The catch, and it is the important one

Routing is not free money, and it is not fire-and-forget. The classic way it bites: a team builds a router, cuts the bill 40%, finance is thrilled. Then the provider quietly tweaks the cheap model, a quality check starts failing, and the router silently sends everything back to the most expensive model. The next bill triples. Nothing errored. Nothing alerted. Savings only ever count net of quality, and a weaker answer that triggers retries and manual cleanup can quietly eat the very savings it created.

Routing without measurement saves money right up until it costs more than it saved. Doing it properly takes three things running underneath the router: cost per outcome for each model, not just the total bill, so a route can be proven to actually pay off; a live watch for silent escalation and quality drift; and enforceable limits around the whole system, so a misrouted or runaway job cannot eat the quarter’s budget before anyone notices. This is precisely the layer we built Agent IQ to sit on top of, and it is why cost-per-outcome tracking, not just total spend, is the metric that matters. Visibility tells a team it happened. A limit stops it before it does.

What this means for the CFO conversation

For a finance leader watching AI coding spend climb, routing is the single highest-leverage lever available before the next budget review, but only if someone can show the receipt. “We switched to a cheaper model” is not a number. “We cut cost per accepted line by 40% while holding acceptance rate flat” is. That distinction is the difference between a CFO who trusts the next AI budget request and one who starts asking for a moratorium, a pattern we have written about in why acceptance rate is the wrong metric on its own for judging coding-tool ROI.

The playbook

This is what leading an AI transformation actually looks like in 2026. Not chasing the biggest model. Matching the model to the task, measuring that the swap held quality, and proving the savings with a number a CFO can defend in a board meeting. That is the vendor-neutral measurement layer Olakai exists to provide: one place to see cost per outcome across every model and every vendor, not a router’s word for it. That is how a team ships more, spends like it is its own money, and walks into the next budget review with the receipt instead of an excuse.

One question worth taking into the next architecture review: what share of your AI calls hit your most expensive model by default, and do you actually know whether they needed to? If the honest answer is “we’re not sure,” that is the gap talking to an Olakai expert is built to close.

Talk to an Expert →