What Doesn't Transfer When You Change Models

Most guidance about switching models focuses on what changes — price, context window, recency. Just as important, and far more often overlooked, is what silently doesn't transfer at all: state, tuning, and assumptions built around the old model that simply don't exist for the new one until you deliberately rebuild them.

Cached prefixes don't survive a model switch

Caches are scoped to the specific model that wrote them — switching models mid-workflow means every cache built up under the old model starts cold under the new one, with no carryover of accumulated cache warmth at all. A workload that had been running efficiently thanks to a well-warmed cache under the old model needs to rebuild that warmth from scratch under the new one, and the caching economics themselves may differ meaningfully between the two models regardless.

Reasoning-effort tuning is model-specific, not a general setting

If you'd tuned reasoning-effort levels carefully for a workload under a model that publishes that control, that tuning has no meaning at all for a model that doesn't publish the same control — currently, that's every model on this site's roster except one. Switching away from the model with published effort levels means losing that specific lever entirely, not just needing to re-tune it; switching toward it means gaining a lever that simply didn't exist under whatever model you were using before.

Rate-limit headroom doesn't transfer between limit groups

An account's usage tier is genuine and does transfer across models — but a specific model's rate-limit table is model-group-specific, and a workload that fit comfortably under one model's published ceiling isn't guaranteed to fit as comfortably under a different model's table, even at the identical account tier, since this site's own research has documented real, substantial differences between limit groups that don't track price or capability in any simple way.

Your own accumulated intuition about a model's behavior doesn't transfer either

Beyond anything technical, a team that's worked with one model for a while develops real, informal calibration — a sense of how it typically responds to certain kinds of instructions, where it tends to need more explicit guidance, what its common failure modes look like. None of that intuition automatically applies to a different model, even a closely related sibling, and treating early sessions with a new model as an opportunity to rebuild that calibration, rather than assuming your old instincts still apply directly, avoids a subtle source of friction in the early period after a switch.

AGENTS.md content written with one model's quirks in mind

If your project context file includes guidance specifically tuned around a particular model's known tendencies — workarounds for a specific weakness, instructions calibrated to how that model tends to interpret certain phrasing — that guidance may not apply, or may even actively mislead, a different model with different tendencies. Reviewing project context for model-specific assumptions after any model switch, not just general project conventions, is worth doing as part of the switch itself rather than treated as a separate task nobody gets around to.

Cost baselines and budget expectations reset, not adjust proportionally

It's tempting to assume a cost baseline built under one model simply scales by the price ratio between old and new models — but token consumption patterns, not just price, can differ between models for the identical task, which means a proportional cost adjustment based purely on published per-token price differences can be meaningfully wrong. Building a fresh baseline from real usage under the new model, rather than mathematically adjusting the old one, produces a more trustworthy budget going forward.

Building a checklist for what to explicitly re-establish

Given how much silently doesn't carry over, it's worth a short, explicit checklist for any model switch: rebuild cache warmth expectations, re-tune or remove reasoning-effort settings as applicable, re-check rate-limit headroom against the new model's specific table, review AGENTS.md for model-specific assumptions, and build a fresh cost baseline from real post-switch usage. None of these individually takes long, and together they cover the large majority of what actually breaks quietly during a model switch that a spec-sheet comparison alone won't reveal.

Why none of this shows up in a typical pre-migration comparison

A spec-sheet comparison between two models naturally focuses on what's explicitly published and directly comparable — price, window, cutoff — because those are the things both models' own pages state plainly. Everything on this page is different: it's not a property of either model individually, it's a property of the relationship between your specific existing setup and whichever model you're switching away from, which is exactly why no generic comparison table, including the ones this site publishes, can surface it automatically. It has to be checked deliberately, workload by workload.

Why teams that skip this checklist tend to blame the wrong thing

When one of these silent gaps causes a real problem after a migration — a cost spike from cold caches, a confusing behavior change from lost project context, a throttling incident from an unchecked rate-limit table — the natural instinct is often to blame the new model itself as somehow worse or less reliable than the old one. In most cases the new model isn't actually the problem; the gap is in what didn't get deliberately re-established during the switch, and recognizing that distinction is what prevents an unfair, inaccurate verdict against a model that might otherwise have been a perfectly good choice.

Treating this list as a living one, not a fixed inventory

This isn't necessarily an exhaustive list of everything that fails to transfer across a switch — as this ecosystem's own mechanics evolve, new model-specific features may emerge that create new categories of things worth re-establishing after a future migration. Treating this page's checklist as a solid, well-tested starting point rather than a permanently complete and final one is the more accurate, more durable way to actually use it going forward.