
Claude Sonnet 5 shipped on June 30. Anthropic's framing was "a cheaper way to run agents," which is technically accurate but undersells what's actually interesting here. The benchmark I keep coming back to is Terminal-Bench 2.1: Sonnet 5 scores 80.4%, while Opus 4.8 scores 74.6%. The mid-tier model now beats the top tier on agentic terminal tasks. On GDPval-AA v2, a knowledge work eval, Sonnet 5 scores 1,618 Elo versus Opus 4.8's 1,615, basically a dead heat.
Opus 4.8 still leads on SWE-bench Pro (69.2% vs Sonnet 5's 63.2%) and OSWorld-Verified (83.4% vs 81.2%). For hard multi-step coding and complex computer-use flows, Opus is still the call. But for most of what shows up in an agent loop, Sonnet 5 at $2 per million input tokens and $10 per million output tokens (introductory pricing, through August 31) is a genuinely different calculus than Sonnet 4.6 was.
That said, migrating isn't a find-replace on the model ID. Three changes in Sonnet 5 will break code that worked fine on Sonnet 4.6.
Adaptive Thinking Is On by Default Now
On Sonnet 4.6, if you didn't pass a thinking field, the model ran without thinking. On Sonnet 5, that same request runs with adaptive thinking enabled. For latency-sensitive paths, this will surprise you. And if you've tuned max_tokens around expected response length without accounting for thinking tokens, you may start seeing truncation.
To disable it explicitly:
thinking = {"type": "disabled"}
Manual extended thinking with budget_tokens now returns a 400 error on Sonnet 5, the same as on Opus 4.8. If you were using extended thinking on Sonnet 4.6, you need to migrate to the new effort parameter (low, medium, high, max, x-high) before you update the model ID. The old budget_tokens approach is gone.
The New Tokenizer Changes Your Cost Model
Same text, approximately 30% more tokens than on Sonnet 4.6. This is the one that catches you off guard, because everything else in the API looks identical. Same request shape, same response format, same streaming events. The usage field just comes back with higher counts for inputs and outputs that haven't changed.
What that means practically:
- Re-run your cost estimates. The per-token price is unchanged ($2/$10 intro, $3/$15 standard from September 1), but 30% more tokens means 30% higher cost for the same text. Model your costs against
claude-sonnet-5, not your Sonnet 4.6 numbers. - Your effective context capacity shrinks. 1M token context window still, but each token covers less text now. A prompt that fit cleanly before may run tight.
max_tokenslimits may truncate. If you sizedmax_tokensclose to your expected output length on Sonnet 4.6, revisit those limits before migrating.
I haven't run this across a large production pipeline yet, so I don't have an empirical multiplier for code-heavy versus text-heavy workloads. Budget conservatively until you do.
Temperature and Top-P Now Return 400
If your code passes temperature, top_p, or top_k to Sonnet 4.6, those same calls fail on Sonnet 5 with a 400 error. This constraint already existed on Opus 4.7 and 4.8. Anthropic has now extended it to Sonnet-class models.
The fix is the same one that works on Opus: use system prompt instructions to guide tone and behavior instead of sampling parameters. If you have a shared wrapper or middleware that injects sampling params for all Claude calls, that wrapper needs updating before you flip model IDs anywhere.
When to Still Use Opus 4.8
Sonnet 5 doesn't retire Opus 4.8. The SWE-bench Pro gap (63.2% vs 69.2%) matters for hard coding tasks where correctness is load-bearing. If your agent is doing complex multi-file refactors or algorithmic problem-solving where a mistake downstream compounds, Opus is still the more reliable choice.
My current routing after this launch: Sonnet 5 as the default for agentic loops, tool use, search, computer use, and anything where throughput matters. Opus 4.8 reserved for final synthesis steps in a pipeline, or tasks where the cost of a coding error is genuinely high.
Two things to check before switching: Sonnet 5 isn't available on the Priority Tier service tier, and it's not supported on the legacy InvokeModel or Converse APIs on Amazon Bedrock (only the newer Bedrock API). If you're on either path, confirm compatibility before updating configs.
The Pricing Window
The $2/$10 intro pricing holds through August 31, then moves to $3/$15. That's about two months to measure actual costs under the new tokenizer and decide whether the performance-to-cost ratio holds up for your specific workloads before the full rate kicks in.
The official migration guide covers all the API changes in detail. Read it before you touch the model ID string.