Migrating Cached Prompts Across a Model Change

A cache is scoped to the model that wrote it — there's no mechanism for a prefix cached under one model to carry over as a warm cache under a different one, which means every model migration is, among everything else, a caching reset that's worth planning for explicitly rather than discovering as an unexplained cost or performance dip after the fact.

Why caches can't carry over between models, mechanically

Caching works by matching an incoming request's prefix against previously-seen prefixes for that specific model — the underlying mechanism is inherently model-scoped, since a cache is fundamentally tied to how that specific model processes the prefix. There's no cross-model cache-sharing mechanism to rely on; treating a migration as anything other than a full caching reset is planning against a carryover that doesn't exist.

The immediate cost impact of a caching reset

For any workload that had built up meaningful cache warmth under the old model, the period immediately after a migration will show higher effective costs than the old model's steady state, purely because every prefix needs to be freshly written and re-warmed under the new model before the caching discount starts accruing again. This is a temporary, expected effect, not a sign the migration itself was a mistake — but it's worth anticipating in any pre-migration cost estimate rather than comparing the old model's fully-warmed cost against the new model's cold-start cost and drawing a misleading conclusion from that mismatch.

Building a fair cost comparison despite this

When estimating migration costs ahead of time, it's worth explicitly modeling both a cold-start period and a steady-state period separately, rather than a single blended estimate — the true cost of a migration includes a real, temporary re-warming cost on top of whatever the new model's steady-state economics turn out to be, and a comparison that only looks at eventual steady state will understate the actual near-term cost of making the switch.

The write-charge wrinkle if migrating onto GPT-5.6 or later

If the migration target is a GPT-5.6-family model, the re-warming period is more expensive than it would have been on an older model, because every fresh write during that re-warming period now carries the newer generation's cache-write charge — a cost that simply didn't exist during the equivalent re-warming period on an older-generation model. This compounds the temporary cost bump described above and is worth factoring in explicitly for exactly this migration direction.

Restructuring prompts as part of the migration, not after

If a migration is happening anyway, it's a natural moment to also revisit whether your prompts are structured optimally for caching under the new model — moving request-specific content toward the end of a prompt, consolidating what used to be several smaller cacheable sections into a more efficient structure. Bundling this optimization into the migration itself, rather than treating it as a separate future task, means the new model gets set up correctly from the start rather than inheriting a caching structure that was really tuned for the old model's specific quirks.

Monitoring cache-hit rate specifically during the transition

Watching cached_tokens in the usage object closely during the weeks immediately following a migration — more closely than you might under normal steady-state operation — helps confirm the cache is actually re-warming as expected, rather than staying colder than anticipated because of some structural issue with the new model's matching behavior or an overlooked prompt change that broke prefix stability during the migration itself.

Setting realistic expectations for how long re-warming takes

How quickly a cache re-warms after a migration depends entirely on how often your workload's traffic pattern naturally reuses its cacheable prefixes — a high-frequency workload re-warms within hours; a low-frequency one might take days or weeks to reach the same steady-state hit rate the old model had built up over a much longer period. Setting expectations accordingly, rather than assuming re-warming happens overnight, avoids a false alarm about the new model's caching "not working" when it's actually just early in a normal, expected warming curve.

Communicating the temporary cost bump to whoever watches the budget

Whoever's responsible for monitoring spend needs to understand, ahead of time, that a migration will produce a temporary cost bump during the re-warming period that isn't itself a sign of a problem — without that context, a soft budget alert firing during a planned migration's re-warming period can look like an alarming regression rather than the expected, temporary consequence of a deliberate, already-approved decision.

Planning the migration timing around your workload's natural rhythm

If your workload has predictable slower periods — a quieter time of week, a natural lull between major releases — timing a migration to land during one of those windows means the temporary re-warming cost lands when overall volume is already lower, reducing its absolute dollar impact even though the proportional effect on caching efficiency stays the same. This is a small, situational optimization, but it's a free one for any workload that genuinely has a predictable quiet period to take advantage of.

Why this is worth its own dedicated page rather than a footnote elsewhere

Caching economics are already one of the more computation-heavy parts of planning around this ecosystem, and the specific interaction between "caches reset on migration" and "GPT-5.6 introduced a write charge that didn't exist before" is exactly the kind of compounding detail easy to miss if it's buried as an aside inside a more general migration guide. Giving it a dedicated page makes sure anyone planning a migration onto the newest model generation actually encounters this specific interaction clearly, before committing to a migration date, rather than discovering it only after the migration is already underway and the temporary cost bump has already started showing up.