Claude Sonnet 5: Anthropic Turns Model Choice Into a Dial

Sonnet just stopped losing to Opus

For two years, picking a Claude model meant picking a tier: Sonnet for volume and cost, Opus for the tasks where you couldn't afford to be wrong. Claude Sonnet 5, which Anthropic shipped on June 30, doesn't just narrow that gap — it makes the tier question itself less useful to ask.

Anthropic's own framing is unusually blunt about where the gains have concentrated recently: "the clearest gains in agentic capabilities have been in our Opus-class models." That's a notable admission from the company that built its reputation on Sonnet-class models in the first place — Claude Sonnet 3.5, 3.6, and 3.7 were the models that made agentic coding and tool use look production-ready, well before Opus caught up. Sonnet 5 is the correction. It's a substantial improvement over Sonnet 4.6 on reasoning, tool use, coding, and knowledge work, and on several evaluations it lands close enough to Opus 4.8 that the decision stops being about raw capability and starts being about cost.

From today, Sonnet 5 is the default model for Free and Pro plans, available to Max, Team, and Enterprise users, and live in both Claude Code and the Claude Platform under the API string claude-sonnet-5. If you haven't touched your default model setting, you're already on it.

The dial replaces the tier

Here's the part that actually changes how you build: Sonnet 5 ships alongside an effort parameter — a request-level dial, up to xhigh (extra-high effort), that trades latency and token spend for reasoning depth inside a single model. Anthropic's own cost-performance charts show Sonnet 5 at medium effort beating Sonnet 4.6 outright on cost efficiency, and at high effort closing in on Opus 4.8's ceiling on some tasks.

That reframes model routing. If you've built if (hard_task) callOpus() else callSonnet() logic — a static tier switch keyed on a task-difficulty heuristic — you now have a cheaper alternative: keep everything on Sonnet 5 and vary the effort level per call instead. Pricing makes the case concrete: Sonnet 5 launches at $2 per million input tokens and $10 per million output tokens through August 31, 2026, reverting to $3/$15 afterward. Opus 4.8 stays at $5/$25. Even at xhigh, you're paying Sonnet rates for work that used to require an Opus call.

This doesn't kill the Opus tier. It changes what the tier switch is for — not "is this task hard," but "does this task need capability that no amount of Sonnet effort will reach." That's a narrower set of calls than most routing logic currently assumes.

Where the gap doesn't close

Two details in the launch material matter more than the headline. First, safety: Sonnet 5 shows an overall lower rate of undesirable behaviors than Sonnet 4.6 and is generally safer to use in agentic contexts — a real improvement if you're running it with tool access and limited supervision. Second, and more relevant if you're weighing it against Opus for sensitive workloads: Sonnet 5 has a much lower ability to perform cybersecurity tasks than Anthropic's current Opus models. It does join the Cyber Verification Program at launch — live on the native Claude Platform, the Claude Platform on AWS, and Claude in Microsoft Foundry, with Google Vertex coming soon, and organizations already enrolled get the same access on Sonnet 5 without reapplying — but Anthropic's own recommendation for cybersecurity work that requires reduced guardrails remains Opus 4.8.

Read plainly: the gap narrows on reasoning, tool use, coding, and general knowledge work. It does not narrow on cyber-specific capability, and Anthropic isn't framing it as if it does. If your workload touches offensive or defensive security tooling, the tier switch we just said was less useful is still the right call there.

Anthropic corrected its own launch chart — same day

One detail we'd flag to anyone building eval pipelines on top of these releases: hours after publishing, Anthropic edited the post's own BrowseComp cost-performance chart. The original version used what the company now describes as a simpler methodology that underestimated Sonnet 5's score on that benchmark; the corrected chart matches the methodology documented in the Sonnet 5 system card — a 10M-token budget with compaction and programmatic tool calling, not the lighter setup originally graphed.

Two takeaways. First, the correction moved in Sonnet 5's favor, which at least reads as a company willing to publish an update that makes its own launch post look understated, rather than quietly leaving an inflated number up. Second, and more actionable: if you're citing Sonnet 5's BrowseComp numbers anywhere — a comparison deck, an internal eval writeup — re-check them against the system card, not the blog post you may have screenshotted on launch day. The launch-day chart and the current chart aren't the same chart.

What changes in your routing logic this week

If Sonnet 4.6 was your default and Opus was your escape hatch, the migration is mechanical: swap the model string to claude-sonnet-5, and before you touch your routing conditionals, try raising the effort parameter on the calls that used to trigger the Opus fallback. For a meaningful share of "hard" tasks — the ones that were hard because they needed more reasoning steps or tool calls, not because they needed capability Sonnet fundamentally lacked — that's a cheaper fix than a tier switch, and it's the one Anthropic is explicitly pointing you toward first.

What we're betting on next week

We're rerunning our own agentic-coding eval suite against claude-sonnet-5 at medium and high effort, side by side with our existing Opus 4.8 baseline, to see how much routing logic we can actually retire. We're also watching whether the effort parameter becomes a first-class option in claude-agent-sdk (currently at 0.3.201) rather than something you only set at the API layer.

→ Get in touch — we'll audit your model-routing logic and show where an effort dial replaces a static Opus fallback.