Migrating: Opus 4.6 to Opus 5

The widest single-generation gap in the current lineup

This migration spans more actual behavioural change than a typical adjacent-generation move, because it crosses the same boundary where the older sampling controls and thinking-budget mechanism were dropped entirely — code untouched since it was written against this generation will fail immediately on the newer one, not degrade gracefully.

What to check before moving real traffic

Beyond the hard-breaking fields, thinking flips from opt-in to on-by-default, and cannot be disabled at all above the mid-to-high effort range — a real behavioural shift for any workload using higher effort settings. The cache minimum also moves substantially in your favour here, which is worth verifying directly rather than assuming: prompts too short to cache on the older generation may cache cleanly on the newer one with no code change.

Don't migrate this one without a test pass

Because three independent changes land at once — hard-breaking fields, a flipped thinking default, and a new effort tier — this is not a migration to cut over on a Friday afternoon with no verification plan. Budget real testing time against your actual hardest tasks, not just a smoke-test against typical traffic, before moving production volume across this specific boundary. Treat the fields that error outright as the easy part of the work — they fail loudly in testing and get fixed quickly. The thinking-default and cache-minimum changes are the ones that need deliberate verification, since neither produces an error on its own.

Related

See what actually changed from Opus 4.6 to Opus 5 for the narrative version of this migration, and budget_tokens is not supported on Opus 4.7 and later for the error this migration most commonly triggers first.