Migrating: Opus 4.8 to Opus 5

Same price, one real behavioural difference

These two models share their sticker price and request surface, which makes this one of the simplest-looking migrations in the lineup on paper — and it mostly is, with one specific exception worth checking deliberately: thinking's default flips. The source generation runs with thinking off unless explicitly requested; the destination runs with it on by default and can't be disabled at all above the mid-to-high effort range.

Why this matters more than it looks like it should

Because so much else stays identical between these two, it's tempting to treat this as a same-day, no-testing cutover — exactly the assumption that lets the thinking-default change slip through unnoticed until a max_tokens ceiling that worked fine on the source model starts truncating responses on the destination one. Check max_tokens sufficiency specifically as part of this migration, even though almost nothing else about the request needs to change.

A good candidate for a fast, low-risk migration once tested

Because so little else changes between these two, this is one of the faster migrations in the lineup to actually execute once the thinking-default check is done — there's no tokenizer shift, no removed fields, and no cache-minimum surprise to account for on top of it, which isn't true of most of the other migrations covered on this site. Confirm max_tokens sufficiency at whatever effort level your workload actually uses, ship the change, and move on — this is not a migration that needs an extended staged rollout the way a multi-change move does.

Related

See thinking disabled above high effort on Opus 5 for exactly how the destination model's thinking default interacts with higher effort settings.