prompt caching · 9 min read · 2026-07-10

Why switching models mid-session breaks your prompt cache

You're 40 turns deep in Claude Code, you type /model haiku to ask a cheap question, and your next turn is slow and, if you're on the API, surprisingly expensive. Nothing crashed. You just invalidated your prompt cache. Here's exactly why that happens, what it costs, and how to use multiple models without paying the penalty.

How prompt caching actually works

When you send a request to Claude, the API can cache the processed form of your prompt so the next request doesn't have to re-compute it. Per Anthropic's prompt caching docs, the economics are:

In an agentic coding session, almost everything is a re-read: the system prompt, the tool definitions, and every previous turn get re-sent on every request. That's why Anthropic's own engineering write-up, "Lessons from building Claude Code: prompt caching is everything", treats the cache as the load-bearing wall of the whole product. A long session with a warm cache runs at roughly a tenth of the input cost, and with dramatically lower time-to-first-token, since the model skips re-processing hundreds of thousands of tokens.

Two properties of the cache matter for this article:

1. It's a prefix match on exact bytes. The cache key is derived from the rendered prompt: tools, then system prompt, then messages. Any byte change at position N invalidates everything after N.
2. It's scoped to the model. The cached artifact is the model's internal state (the KV cache) computed from those bytes. Opus, Sonnet, and Haiku have different weights and different architectures; the numbers one model computes are meaningless to another. There is no cross-model cache, on any provider.

What actually happens when you switch models

Anthropic's docs include an invalidation hierarchy: some changes only invalidate part of the cache, but two changes nuke everything: editing the tool definitions, and switching the model:

So when you run /model mid-session in Claude Code, three things happen on your next turn:

• Full re-read at full price. The new model has no cache entry for your conversation, so your entire accumulated context (system prompt, tools, CLAUDE.md, every file read, every diff) is processed as fresh input, plus the 1.25× write premium to build the new model's cache.
• A visibly slow turn. Cached tokens skip prefill. Uncached, a 100K+ token context adds many seconds before the first token appears.
• The old cache dies quietly. The default TTL is 5 minutes, refreshed on use. Stay on the new model past that and switching back pays the full re-write again. A round trip costs you twice.

Note what didn't break: your conversation. The transcript carries over fine, which is exactly why this cost is invisible. The UX is seamless while the meter runs. Community write-ups have measured the same thing: each model keeps an isolated cache, so a switch recomputes the entire request even when the content is identical, and asking a "cheap" model one question mid-session can cost more than letting the expensive model answer.

The math: what one careless switch costs

Take a realistic Claude Code session that has grown to 150K tokens of context, running on an Opus-tier model at $5 per million input tokens:

Two ordinary cached Opus turns would have cost about $0.16. The round trip cost ~7× more, all to save money on one question. And this scales linearly with context: at 400K tokens of context on a 1M-context model, one switch back to Opus is ~$2.50 of pure cache rebuild. The cheap question was the most expensive thing you did all session.

Subscription users: you pay in rate limits, not dollars

On Claude Pro/Max plans there's no per-token bill, but usage limits are still accounted in tokens, and cache misses consume dramatically more of them. The same 150K-token rebuild that costs an API user ~$1 costs a subscription user a real chunk of their 5-hour window. If you've ever wondered why your limits evaporated on a day you kept flipping between models, this is why. (Rate limits also weigh cache reads far below uncached input, so a warm cache stretches your quota the same way it stretches API dollars.)

Cache-safe ways to use multiple models

None of this means "pick one model forever." It means the switch boundary should be the session, not the message. Three patterns, in increasing order of convenience:

1. Finish the thought, then switch

If you must switch inside one session, do it at a natural boundary: after finishing a task, before starting a fresh one, ideally after /clear or /compact when the context is small. Rebuilding a 5K-token cache is noise; rebuilding 300K is not.

2. Delegate to subagents

Anthropic's own guidance for agent builders is to keep the main loop on one model and spawn a subagent on the cheaper model for the sub-task. The subagent gets a fresh, small context (cheap to process), does its work, and returns a summary, while your main session's cache stays warm and untouched. In Claude Code, the Task/Agent tool with a model override does exactly this.

3. Run one live session per model

The heavyweight option: keep parallel sessions, one per model. Opus in one, Haiku in another, Codex in a third, and route work to whichever fits. Each session maintains its own prefix, its own history, and its own warm cache. Frequent turns keep each cache alive (every use refreshes the 5-minute TTL), so every model answers at ~0.1× read pricing with fast time-to-first-token. You never pay a rebuild because nothing ever switches.

This is exactly the workflow Model Shift automates: each model is mapped to a gear, and every gear runs in its own tmux-backed tab. Throwing the lever doesn't switch the model inside your session; it moves you to that model's own live session, cache warm, context intact. Multi-model workflow, zero cache rebuilds.

How to verify this yourself

On the API, the response usage block tells you exactly what happened:

"usage": {
  "input_tokens": 412,                  // full price
  "cache_creation_input_tokens": 148213, // 1.25x -- you just paid a rebuild
  "cache_read_input_tokens": 0           // 0.1x -- this should be the big number
}

On a healthy long session, cache_read_input_tokens dominates. Right after a model switch, it drops to zero and cache_creation_input_tokens spikes to your whole context size. In Claude Code, /cost (API users) reflects the same spike, and the Claude Code docs confirm caching is enabled by default precisely because these misses are so expensive.

FAQ

Does /model reset my conversation?

No. Context and history carry over. Only the cache is lost, which is why the cost is easy to miss.

Is this specific to Claude?

No. Prompt/prefix caches are model-scoped everywhere, OpenAI, Google, and Bedrock included, because the cached artifact is model-internal state. OpenAI's automatic caching has different pricing (free writes, ~50–75% read discounts) but the invalidation rule is the same: new model, cold cache.

Does switching thinking/effort settings also break the cache?

Toggling thinking invalidates the messages cache but keeps tools+system. Changing tool definitions or the model invalidates everything. Editing your system prompt (or hooks that inject timestamps into it) invalidates system+messages. The model switch is the most expensive single toggle in the product.

What about long gaps, like lunch breaks?

The default cache TTL is 5 minutes, refreshed on every use. Walk away for 20 minutes and your next turn pays a rebuild even with no model switch. API builders can opt into the 1-hour TTL at a 2× write price; in interactive tools, just know the first turn after a break is the slow one.

Further reading: Anthropic prompt caching, explained (TTLs, pricing, the prefix rule) · A cache-safe multi-model workflow for Claude Code & Codex