Prompt caching is one of the biggest cost levers on Claude: a cache read is billed at 0.1x the base input price, so a system that keeps a large shared prefix (system prompt, tool definitions, reference documents) cached can process the same tokens for a tenth of the price. But the cache is keyed to the model. Changing the model string — say, from claude-opus-4-7 to claude-opus-4-8 — invalidates the existing cache regardless of whether the prompt content is byte-identical. The first request on the new model writes the cache fresh, at cache-write rates. Your cache_control markers themselves keep working across the migration; it's the cached entries that don't carry over.
What the cold-cache spike actually costs
Cache writes are priced above normal input: a 5-minute cache write costs 1.25x the base input price, and a 1-hour cache write costs 2x. Cache reads cost 0.1x. So the day you cut over, requests that used to bill a large prefix at 0.1x briefly bill it at 1.25x–2x instead — up to a 20x swing on the cached portion until entries are re-established. For a low-volume app this is noise. For a high-throughput system with a six-figure-token shared prefix, an abrupt 100% cutover can produce a visible one-day cost bump and, worse, a latency bump, because cache writes do full prompt processing.
One more wrinkle: on some model upgrades the token counts themselves change. Claude Opus 4.7 and later Opus models, Sonnet 5, and Fable 5 use a newer tokenizer that produces roughly 30% more tokens for the same text than Opus 4.6 and earlier. If you're crossing that boundary, the prefix you re-cache is also bigger than the one you're leaving behind — budget for both effects.
Pre-warming during a gradual rollout
The fix is to make cache writes happen on your schedule, not your users'. A standard rollout looks like this:
1. Shadow-write before cutover. Before shifting any traffic, send a small number of real-shaped requests to the new model — same system prompt, same tool definitions, same document prefix, with a minimal max_tokens. Those first requests pay the cache-write premium once and establish the entries. (Note that Anthropic's batch documentation explicitly disallows max_tokens: 0 cache pre-warming inside a Message Batch — pre-warm traffic belongs on the synchronous Messages API.)
2. Match the cache duration to your traffic gap. The 5-minute cache only helps if follow-up traffic arrives within five minutes of the write; each read refreshes the window. If your rollout ramps slowly, or your pre-warm job runs ahead of a traffic shift, use the 1-hour duration on the breakpoints you pre-warm. The break-even math from Anthropic's pricing page: the 5-minute write (1.25x) pays for itself after one cache read; the 1-hour write (2x) pays for itself after two.
3. Ramp a percentage, keep both caches warm. During a 5% → 25% → 100% ramp, both models serve traffic, so both caches stay warm from live requests — the old model's cache is maintained by the 95%, the new model's by the 5%. The cost spike disperses into the ramp instead of landing on cutover day. This is also the window to re-baseline token overhead and validate output quality.
Platform wrinkles to check
The invalidation-on-model-change behavior is the same on every platform, but two details differ. First, cache minimums: Claude Fable 5 has a lower prompt-cache minimum of 512 tokens on the Claude API (versus 1,024 on Opus 4.8) — but on Amazon Bedrock the Fable 5 minimum is still 1,024, so a prefix that caches on the first-party API may be below the caching threshold on Bedrock. Second, if you run the same workload on two platforms (see dual-platform rate-limit isolation), remember each platform maintains its own cache — pre-warm each surface you serve from, using the right model-ID form for each (claude-opus-4-8 on most platforms, anthropic.claude-opus-4-8 on Bedrock).
Where to go next
For the mechanics of writes, reads, and breakpoints, see prompt cache mechanics and cache write vs. read pricing. If your upgrade crosses the tokenizer boundary, read the tokenizer break on upgrade before you re-budget.