What actually changed from Sonnet 4.6 to Sonnet 5

Why "just swap the model id" undersells this move

Sonnet 5 and Sonnet 4.6 sit at the same point in the lineup and, on paper, look like a straightforward drop-in upgrade — same tier, broadly similar positioning. In practice, three things move at once between them, and each one individually is enough to change either your bill or your prompt's behaviour if it goes unchecked: the tokenizer, the thinking default, and the effort level ceiling.

The tokenizer difference is the one that surprises people first

Sonnet 5 counts tokens differently from Sonnet 4.6 for identical text — noticeably more tokens for the same input, at an unchanged per-token sticker price. That means a workload that costs roughly the same per token on both models can still bill meaningfully more on the newer one, purely because the same text turns into more billable tokens. Anyone budgeting this migration off the sticker price alone, without re-counting real prompts against the new model specifically, is working from a number that understates the actual cost.

Thinking runs by default now

Sonnet 4.6 only thinks when you explicitly ask it to; Sonnet 5 has thinking on by default. That changes two things at once: max_tokens now has to account for thinking as well as the visible answer, since both draw from the same budget, and requests that previously ran without any thinking overhead at all now carry some by default unless you actively configure it off. A prompt tuned against 4.6's opt-in thinking behaviour, moved unchanged to Sonnet 5, is silently running under different assumptions than it was written against.

A new effort level is available, and worth testing deliberately

Sonnet 5 is the first Sonnet generation with the highest effort tier available in the current lineup, which didn't exist as an option on Sonnet 4.6 at all. That's genuine new capability for the hardest tasks this tier handles, not something to reach for by default — test it specifically against tasks that were previously the ceiling of what Sonnet could handle well, rather than raising every request to the new top tier reflexively.

The practical migration checklist

Re-count your actual prompts against Sonnet 5 rather than assuming the old counts hold, re-check max_tokens against thinking now running by default, and treat the new top effort level as something to test deliberately rather than adopt uniformly. None of these three individually is hard to fix; the risk is moving without checking any of them and discovering all three at once, weeks later, as an unexplained bill and a handful of truncated responses.

Quality behaviour worth re-testing, not just assuming carries over

Beyond the mechanical changes, it's worth treating Sonnet 5's actual output quality on your specific tasks as something to re-verify rather than assume improved uniformly just because it's the newer generation. A newer model is not guaranteed to be strictly better on every task type a predecessor handled — it's typically better on balance, with a different profile of strengths, and a narrow task that happened to suit 4.6's particular behaviour well is worth spot-checking rather than assuming the upgrade is a pure win across the board without looking.

A migration plan that catches all three changes at once

Run your actual production prompts against Sonnet 5 in a staging environment before cutting over traffic, checking token counts, max_tokens sufficiency under default thinking, and output quality together rather than as three separate exercises — a fix for one of these in isolation can mask a problem in another if you're only checking pass/fail on the final output rather than the intermediate numbers. Treat this as one migration with three moving parts, not three unrelated migrations that happen to share a model swap.

See migrating: Sonnet 4.6 to Sonnet 5 for the field-by-field pricing and limits diff, and why your token-count estimate was wrong for the tokenizer issue in more general terms beyond this one migration.