Most people who work with AI coding tools pick one model and run everything through it. Usually it's the most capable model they have access to, on the theory that the best model gives the best results everywhere. That's a reasonable default and an expensive habit. The work an AI does on a task isn't one uniform activity - it's several distinct phases, and they don't all need the same horsepower.
I run a fleet of autonomous agents in production and ship ten live products, and the single change that moved my AI spend the most was not a cheaper model across the board. It was matching each phase of the work to the model that phase actually needs.
The work has phases, and they're not equal
Take a normal coding task: add a feature, refactor a module, wire up a new integration. If you watch what the AI is actually doing, it splits into three kinds of work.
Planning and architecture. Deciding how to structure the change, which files to touch, what the interfaces look like, what could break. This is where reasoning quality matters most. A bad decision here costs you the whole task - you'll implement the wrong thing correctly. The token volume is low. A good plan is a few hundred words.
Generation. Writing the actual code once the plan exists. This is high-volume work - the bulk of the tokens in any task are here - but it's comparatively low-leverage per token. When the plan is clear and the task is well-scoped, generation is more transcription than invention. Speed and cost dominate.
Review. Reading the output back, checking it against the plan, catching the subtle bugs. This swings back to high-leverage, low-volume. You're not producing much text; you're making a judgment that determines whether the work ships.
Planning and review are low-volume and high-leverage. Generation is high-volume and lower-leverage-per-token. Once you see the work that way, running all three on the same model looks like a category error. You're either overpaying for generation or underpowering your planning, depending on which model you picked.
Match the model to the phase
The current Claude lineup gives you a clean spread to map onto those phases. Opus 4.8 (or Fable, when I want the strongest reasoning available) for the high-leverage work. Sonnet for the bulk generation. Haiku for mechanical transforms.
Plan on the strong model. Give Opus 4.8 the task, the relevant context, and ask it to produce a plan before it writes anything: the files it will change, the approach, the edge cases, the interfaces. This is the phase where a more capable model earns its cost, and the cost is small because the output is small. You're spending your most expensive tokens exactly where reasoning quality changes the outcome and the token count is lowest.
Build on the fast model. Hand the approved plan to Sonnet and have it implement. This is where the volume lives, and Sonnet is fast and roughly an order of magnitude cheaper than the top tier for the same tokens. When the plan is good, the strong model's judgment is already baked into the instructions Sonnet is following. You're not asking Sonnet to make the hard calls; you're asking it to execute calls that were already made well.
Review on the strong model again. Bring Opus 4.8 back to read the generated code against the original plan. Did it implement what was decided? Are there subtle bugs, off-by-one errors, missed edge cases, silent behavior changes? This is a small amount of output for a high-value judgment, so again you're paying top-tier rates on a low token count.
Reserve the cheapest model for mechanical work. Renaming across files, reformatting, converting data between shapes, boilerplate that follows an obvious pattern - Haiku handles these fine and costs the least. If a junior developer could do it without thinking hard, it doesn't need your best model.
The workflow is: plan on the strong model, hand the approved plan to the fast model to build, review on the strong model. Two thin slices of expensive reasoning wrapped around a thick middle of cheap generation. The expensive model touches the tokens where its judgment matters; the cheap model touches the tokens where volume matters.
When not to downgrade
This is a heuristic, not a law, and the failure mode is treating it as one. Some work is hard reasoning all the way through, and forcing it onto a fast model to save money is a false economy that costs you more in rework than you saved in tokens.
Keep the strong model on the whole task when:
- The problem is genuinely hard to reason about - concurrency, subtle state management, an algorithm where the correct approach isn't obvious. If generation itself requires judgment, generation needs the strong model.
- You're hunting a subtle bug. Debugging is reasoning-dense; the whole point is that the answer isn't apparent. A fast model that misses the bug hasn't saved you anything.
- The plan can't be made precise enough to hand off. If you can't write instructions a fast model can follow without inventing the hard parts, the plan isn't done, and handing it off just moves the hard thinking to the wrong model.
The tell is the plan. If you can produce a plan specific enough that implementing it's mostly mechanical, the handoff works. If every step still contains an open judgment call, you're not ready to downgrade - finish the thinking first. This is the same discipline I wrote about in planning first and coding second: a plan solid enough to hand to a cheaper model is the same plan solid enough to trust at all.
How prompt caching compounds the savings
There's a second-order effect that makes the split pay off more than the raw per-token math suggests. When you plan, build, and review across a single task, the three phases share most of their context - the same files, the same requirements, the same reference material sitting in the prompt.
Prompt caching lets you pay full price for that shared context once and a small fraction of the price on every subsequent call that reuses it. The cache has a short time-to-live, on the order of a few minutes, which is exactly the window in which the phases of one task actually run. Plan, generate, review - all within the cache window, all reusing the same cached prefix.
The interaction with model selection is where it gets good. Caches are per-model, so the phases you keep on one model share a cache; the switch to the fast model for generation starts its own. That argues for keeping each model's phases contiguous rather than ping-ponging between models on every call, so each model's cached context stays warm. Structure the work so the strong model does its planning in one sustained pass, the fast model does its generation in another, and you get both the cheaper generation tokens and the caching discount within each phase. The savings stack.
If you're going to run a mixed-model workflow, the thing that lets you tell whether it's actually saving money is visibility into where the tokens go. It's easy to assume the split is helping when a caching mistake or an accidental model choice is quietly eating the gains. I keep token spend visible precisely so I can see, per phase, whether the expensive model is only touching the high-leverage tokens or has crept into the bulk work.
The mental model
Stop thinking of "which model should I use" as one decision. It's a decision you make per phase, and the phases have different economics. Spend your best reasoning where a wrong call is expensive and the token count is low. Spend your cheapest tokens where the volume is high and the judgment is already made. The strong model plans and checks; the fast model does the work in between; the cheapest model handles what barely needs thinking at all.
The same review discipline applies whether one model or three did the work - if you're going to trust generated code, something capable has to read it back, which is its own habit worth building into a verification loop. Match the model to the task and the bill goes down while the output gets better, because each phase is finally running on the model it needed all along.