What actually changed from Opus 4.6 to Opus 5

Three generations of accumulated change, not one

Opus 4.6 to Opus 5 spans more ground than a typical single-generation move, because Opus 4.7 sits between them and introduced changes of its own that Opus 5 inherits — so this migration carries both what changed at 4.7 and what changed again at 5, compounded rather than sequential independent choices you could evaluate one at a time.

The sampling and thinking-budget fields are gone

Opus 4.6 still accepts the older sampling controls and the older thinking-budget mechanism. Opus 5 rejects all of them outright — not degraded gracefully, rejected. Any request-building code that hasn't touched its thinking or sampling configuration since it was written against an older Opus generation will fail immediately on this move, not fail subtly. That's the first thing to check, and it's a hard stop rather than a silent behaviour change, which at least makes it impossible to miss during testing.

Thinking flips from opt-in to on-by-default

Opus 4.6 thinks only when you ask it to. Opus 5 thinks by default and, at higher effort levels, cannot have thinking turned off at all — a request combining a high effort setting with thinking explicitly disabled is rejected. This is the same shift Sonnet went through at its own 5 generation, but it matters more here because Opus is disproportionately used for exactly the harder, more open-ended tasks where higher effort levels are common, which means more of a typical Opus workload runs into the "can't disable thinking here" boundary than would be true for a typical Sonnet workload.

The cache minimum moves favourably, which is easy to miss as a win

Opus 4.6 has one of the highest minimum cacheable prefix lengths of any model in the current lineup. Opus 5's minimum is substantially lower. That's a genuine improvement worth noticing deliberately: prompts that were previously too short to cache at all on 4.6 may cache cleanly on Opus 5 with no code change required — an upside of this migration that doesn't show up unless you specifically go check, since nothing prompts you to notice a cache that started working that wasn't working before.

New effort capability, and a genuinely new fast-mode tier

Opus 5 carries the same top-of-range effort level introduced at 4.7, plus its own fast-mode option at a separate premium rate — neither of which Opus 4.6 offered. Both are worth testing deliberately against real workloads rather than adopted by default, for the same reason any new capability is worth evaluating on its own merits rather than assumed to be a strict improvement for every use case.

Why testing against your hardest tasks matters more here than usual

Opus is disproportionately chosen specifically for tasks near the edge of what a model can reliably handle, which means the margin for a subtle regression to matter is thinner here than for a tier where tasks are typically well within a model's comfortable range. Re-test this migration against your genuinely hardest real tasks, not just a representative average sample — a change that looks like a non-issue on typical tasks can behave differently on the specific edge cases that were the whole reason Opus was chosen for that workload in the first place.

Don't migrate on a Friday

None of the individual changes here are hard to fix once identified, but discovering three of them simultaneously in production, after a change that looked like it should have been safe, is a worse experience than catching them in staging with time to actually investigate each one. Budget real verification time for this migration rather than treating a same-tier model swap as routine — it carries more genuine behavioural change than the tier positioning would suggest at a glance.

See migrating: Opus 4.6 to Opus 5 for the field-by-field diff, and budget_tokens is not supported on Opus 4.7 and later for the specific error this migration most commonly triggers on the first attempt.