Why Switching Claude Models Mid-Session Quietly Costs You More Tokens
Switching between Claude models mid-session breaks caching and reloads your whole conversation at full price. Here's why, and what to do instead.
What happens when you switch Claude models mid-conversation?
Switching models mid-session, say from Opus to Haiku to save money on an easy question, forces Claude to reload your entire conversation history from scratch on the new model. Each model keeps its own separate cache of the conversation. The moment you switch, that cache is void, and the full context gets read back in at full, uncached price. Switch back to the original model later, and the same thing happens again. What looked like a cost-saving move can end up burning more tokens than just staying put.
TL;DR
- Per-model caching means each Claude model maintains its own cache of a conversation, so switching models mid-session forces a full, uncached reload of everything said so far.
- Cheaper models aren’t always cheaper jobs, because a smaller model like Haiku can need more attempts and edits to reach the same result, erasing any per-token savings.
- Anthropic’s own guidance recommends starting most work on Opus and adjusting effort level rather than swapping models partway through a session.
- The advisor feature lets a cheaper model handle the bulk of the work while calling in a stronger model only for hard decisions, without breaking the cache the way manual switching does.
- Effort level is the better lever: dropping effort or asking for a “quick answer” avoids the cache penalty entirely while still cutting cost on simple questions.
- Skills have changed too: Claude now handles a lot of what detailed skill packs used to spell out, so a skill should be a short list of corrections, not a full procedure.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
Why does caching make model switching expensive?
Claude’s caching system is designed to avoid re-processing the same conversation history over and over. When you’re deep into a session, the model has already “read” everything that came before, and that gets stored so follow-up turns don’t cost full price to reprocess. This is what makes long sessions on a single model manageable from a cost standpoint.
The catch is that this cache is tied to the specific model you’re using. Opus has its own cache. Haiku has its own. Sonnet has its own. They don’t share. So the instant you switch from one to another mid-conversation, the new model has no cached version of what’s been said. It has to ingest the entire conversation history again, and that ingestion happens at the full, uncached token rate.
If you then switch back to the original model for a harder task, the same thing happens in reverse. The original model’s cache is also gone by that point, so it reloads everything again at full price too. Bouncing between models a few times in a session can rack up what amounts to an order of magnitude more in token costs than just staying on one model the whole way through, according to Anthropic’s own framing of the issue.
Is picking a cheaper model actually cheaper?
Not necessarily, and not just because of caching. There’s a second cost that’s easy to miss: smaller models often need more attempts to land the same result. A model like Haiku might be far cheaper per token than Opus, but if it takes two or three extra rounds of edits and retries to get a task right, every one of those retries adds tokens and adds time.
One test referenced this year found that Haiku 5.5 needed more requests than larger models to reach comparable quality, and took almost twice as long as Sonnet on longer sessions. That’s the trap: a model can look cheaper on a per-token basis while costing more per completed job once you account for the extra back-and-forth.
This is why Anthropic’s own guidance suggests starting most work on Opus 5.5 and treating effort level, not model choice, as the main lever for controlling cost. Turning effort down for a simple question, or just telling Claude to give a quick answer without deep reasoning, avoids both the caching penalty and the retry penalty.
What is the advisor feature and how does it help?
The advisor is a setting that lets you run a cheaper model for the bulk of a session while giving it permission to consult a stronger model when it hits something genuinely difficult. Instead of you manually switching models and paying the reload cost, Claude decides when to bring in the stronger model.
This typically happens in three situations: before committing to an approach on a hard problem, when the same error keeps recurring and a fresh perspective might help, and before declaring a task finished, as a kind of self-check from a different model. The key difference from manual switching is that turning on the advisor mid-session doesn’t break or clear the cache the way switching models outright does.
In practice, you turn this on inside a session, for instance by invoking the advisor on a Sonnet session and pointing it at Opus. Anthropic has said this approach usually costs less than running the stronger model for the entire session, while still getting its input on the hard parts. It’s worth noting this feature is still marked experimental, so behavior and availability may change. For straightforward work, especially on a subscription plan rather than pay-as-you-go API credits, sticking to a single model for the whole job remains the simpler and often more predictable choice.
How should you actually choose and stick with a model?
The practical takeaway is to pick a model at the start of a job based on its difficulty, not switch opportunistically as the conversation evolves. If the job is complex, start on a stronger model like Opus. If it’s simple throughout, a lighter model may be fine from the start. What you want to avoid is starting strong and then downgrading partway through to “save money” on an easy question, because that’s exactly the scenario that triggers a full cache reload.
If a question partway through a session is genuinely easy, the better move is to lower the effort level or explicitly ask for a fast, non-reasoning answer rather than changing models. This keeps the existing cache intact and still reduces the computational load for that specific turn.
For situations where you genuinely need a second opinion from a stronger model without committing to running it the whole way through, the advisor feature is the more cost-aware option, provided you’re in an environment that supports it and you’re comfortable with an experimental feature.
Frequently Asked Questions
Does switching from Opus to Haiku always cost more?
Not always, but it frequently does once you factor in the cache reload. If the conversation history is short, the reload cost is small. In a long session, reloading the full context at full price can outweigh whatever you saved by using a cheaper model for one question.
What’s the difference between the advisor feature and manually switching models?
Manually switching models breaks the per-model cache and forces a full reload of the conversation at full token price. The advisor feature lets the primary model consult a stronger model for specific hard moments without clearing that cache, which Anthropic says typically costs less overall.
Is lowering effort level better than switching models?
For simple questions within an otherwise complex session, yes. Dropping the effort level or asking for a quick, non-reasoning answer avoids the cache penalty entirely, since you’re still on the same model, just asking it to do less work on that particular turn.
Why did a cheaper model end up costing more time in testing?
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
In testing referenced this year, Haiku 5.5 needed more requests to reach the same quality as larger models and took nearly twice as long as Sonnet on long sessions. More retries and edits mean more total tokens spent, even though each individual token costs less.
Should I still use skills now that Claude handles more by default?
Many existing skill packs are now redundant because current models already follow the basic rules those skills used to spell out. The more effective approach is to let Claude attempt a task unaided first, then write a skill containing only the corrections or niche knowledge it actually got wrong.