Most developers point every request at the most expensive model they have, then wonder why the bill is brutal. Model routing fixes that. Plan with a frontier model, execute with a cheaper one, and reserve top-tier tokens for the work that actually needs them. Done well it cuts an AI coding bill by 40 to 85 percent. Here is the real math, every practical way to do it, and how to see whether it is actually working.
Quick answer
Model routing means sending each task to the cheapest model that can handle it, instead of paying frontier prices for everything. The highest-leverage split is planning versus execution: use a top model like Opus 4.8 or GPT-5.5 to plan and write the spec, then hand that spec to a cheaper model like Sonnet, Haiku, or Cursor's Composer to write the code. Realistic savings are 40 to 70 percent from routing alone, and up to about 85 percent when you also stack prompt caching and lower reasoning effort. The peer-reviewed RouteLLM work reached 85 percent savings at roughly 95 percent of frontier quality. Tokens 4 Breakfast shows your spend per model so you know what to route and can prove the savings are real.
Each step stands on its own — skip to the one that matches where you are.
Model routing means matching each task to the cheapest model that can do it well, instead of paying frontier prices for every request. The cost gap is enormous: Claude Opus 4.8 runs about $5 per million input tokens and $25 per million output, while Haiku 4.5 is roughly $1 and $5. Using a top model to rename a file or add a TODO comment is money set on fire. The default mistake is leaving every request pointed at the most capable model and never switching.
You do not need the same model quality for planning and for execution. Planning is where the real thinking happens: understanding the codebase, choosing an architecture, and writing a detailed spec. That deserves your best model. Execution, taking a good spec and writing the code from it, is work a much cheaper model does well. The workflow: plan and write the spec with a frontier model, hand the spec to a cheaper model to write the code, optionally have the frontier model review the pull request, then let the cheap model fix and ship. The expensive thinking happens once, up front.
Take a feature that spends 100k input and 20k output tokens on planning, then 150k input and 120k output on coding, since writing code produces far more output. All on Opus 4.8 that is about $4.75. Move only the coding to Haiku 4.5 and it drops to about $1.75, a 63 percent cut for the same plan. Route across a bigger price gap and you save more: Matthew Berman's worked example lands at 68 percent, and the peer-reviewed RouteLLM framework reached 85 percent while keeping about 95 percent of frontier quality. The 90 percent you see in headlines is real only at the edge, with execution-heavy work, a wide price gap, and prompt caching stacked on top. Routing alone is usually 40 to 70 percent.
A simple routing table covers most work. Planning, architecture, and hard debugging go to a frontier model such as Opus 4.8 or GPT-5.5. Implementation from a clear spec goes to a mid model such as Sonnet 4.6 or Cursor's Composer, which costs about $0.50 and $2.50 per million and beats far pricier models on agent benchmarks. File navigation, renames, simple edits, and subagents go to Haiku 4.5, the cheapest capable option and more than twice as fast. Keep a second frontier model in reserve for code review, where a fresh set of eyes catches what the author missed.
Model family is only half of it. Every current platform, Claude Code, Codex, Cursor, and ChatGPT, exposes a thinking or reasoning effort setting from low up to max, and those thinking tokens bill at output rates. Most tasks do not need max thinking, yet defaults have crept toward high. Drop simple work to low effort and reserve high or max for genuine multi-step reasoning. On Claude Code use /effort or cap the ceiling with MAX_THINKING_TOKENS; OpenAI models take a reasoning_effort from none to xhigh. Effort routing compounds with model routing rather than replacing it.
There are four ways, in rising order of automation. First, manual: plan and write the spec with your frontier model, then copy the spec into a cheaper model and tell it to build. Second, in-tool controls: Claude Code switches models with /model and dials effort; Cursor's Auto mode routes tasks to its cheap in-house Composer automatically. Third, cross-CLI delegation: Claude Code and Codex can call each other, so you can plan in one and delegate the code writing to the cheaper one with a small skill. Fourth, dedicated routers for API or team workloads: OpenRouter's Auto Router, powered by Not Diamond, plus Martian and the open-source RouteLLM, classify each prompt's difficulty and send it to the right tier automatically.
Routing is the biggest single lever, but it compounds with a few more. Prompt caching gives roughly a 90 percent discount on repeated input such as your system prompt and CLAUDE.md, and can cut 30 to 50 percent of a typical bill on its own. Start a fresh session when you switch tasks so a bloated context window does not bill on every turn. Keep output tight, since output tokens cost three to five times input. Use the Batch API for a flat 50 percent discount on non-urgent work. And keep subagents disciplined, around four for most exploration. Each lever is worth 30 to 50 percent, and because they hit different parts of the bill, they stack.
Routing without measurement is guessing. To route well you have to see which model is actually eating your budget, and to prove a change worked you have to watch the number move. That is the gap Tokens 4 Breakfast fills. It shows your real spend broken out by model and by project, live in the Mac menu bar, with a month-end forecast and a Plan Advisor that tells you whether your subscription is even worth it. Route your execution to a cheaper model, then watch the per-model spend drop over the next week. If it does not move, you routed the wrong thing, and now you can see it.
Pro tips
Short, direct answers to the things people ask most about this.
Model routing is the practice of sending each task to the cheapest AI model that can handle it, rather than paying frontier prices for every request. Easy work like edits, file navigation, and writing code from a clear spec goes to a cheap model; hard work like architecture and planning goes to a top model.
Realistically 40 to 70 percent from routing alone, and up to about 85 percent when you also stack prompt caching and lower reasoning effort. The peer-reviewed RouteLLM framework reached 85 percent savings at roughly 95 percent of frontier quality. The 90 percent figure in some headlines is a best case that needs execution-heavy work, a wide price gap, and caching on top.
Claude Haiku 4.5 is the cheapest capable coding model, at roughly $1 per million input tokens and $5 per million output, and it is more than twice as fast as larger models. It handles quick edits, file navigation, and subagent work well. For writing full features from a spec, Sonnet 4.6 or Cursor's Composer offer more capability at still-low cost.
Use your best model, such as Opus 4.8 or GPT-5.5, for planning: understanding the codebase, choosing an architecture, and writing a detailed spec. Then hand that spec to a cheaper model like Sonnet, Haiku, or Composer to write the code. The expensive reasoning happens once during planning, and execution runs cheap.
Not automatically. Claude Code lets you switch models manually with /model and control the thinking budget with /effort and MAX_THINKING_TOKENS, but it does not route between models on its own. Cursor's Auto mode does route automatically, often to its cheap in-house Composer model. For full automatic routing on the API, use OpenRouter's Auto Router, Martian, or RouteLLM.
Measure your spend per model before and after. Tokens 4 Breakfast shows your real cost broken out by model and project, live in the Mac menu bar, with a month-end forecast. Route your execution to a cheaper model, then confirm the per-model spend actually drops over the following week instead of assuming it did.
Privacy-first analytics
We use optional analytics to understand aggregate website usage and make the product easier to discover. Google Analytics only loads after you accept. No account data, app data, or personal AI usage is sent, and you can change your choice anytime.
Read the privacy policy