Anthropic shipped Claude Sonnet 5 on June 30 with near-Opus-4.8 agentic performance at one-fifth the price, and quietly rug-pulled every team still routing serious work to Opus. The tokenizer change is a 30% price hike nobody is talking about.

Claude Sonnet 5 Is the Only LLM That Mattered This Week. Anthropic Just Made Opus a Hard Sell.

Hey guys, Mr. Technology here. I am going to be direct: if you ship LLM-powered software and you did not read the Claude Sonnet 5 release notes on June 30, you are overpaying for an inferior model this week. Anthropic dropped a frontier-grade agentic model into the Sonnet tier, kept the list price identical to Sonnet 4.6, and watched the entire developer internet spend four days arguing about a pelican. I am going to talk about what actually changed.

The Headline: Sonnet 5 Closes the Gap to Opus 4.8

Anthropic's own positioning is unambiguous. From the launch post: "its performance is close to that of Opus 4.8, but at lower prices." Close is doing a lot of work in that sentence, so here are the numbers. On Anthropic's agentic search eval BrowseComp and the OSWorld computer-use eval, Sonnet 5 traces a Pareto curve that strictly dominates Sonnet 4.6 and overlaps with Opus 4.8 at higher effort settings. Independent reviewers at Vellum put Sonnet 5 within roughly 6 points of Opus 4.8 across coding, terminal, and reasoning suites — 63.2% vs 69.2% on their aggregate, versus Sonnet 4.6 at 58%.

That is not "Sonnet got better." That is "the Sonnet/Opus pricing tier just collapsed." Anthropic's own system card notes Sonnet 5 is significantly less capable at cyber tasks than Mythos 5, which is exactly why the launch cleared regulatory review — but the capability delta to Opus 4.8 is now narrower than the price delta. At list price, Opus 4.8 is $15/$75 per million input/output tokens. Sonnet 5 launches at $3/$15 (intro pricing $2/$10 through August 31). You are paying five times more per token for a model that is, on most workloads your team actually runs, between 5% and 10% better. That math does not work in Opus's favor anymore.

The Tokenizer Rug Pull Nobody Is Talking About

Here is the part that should be on the front page of every AI engineering newsletter and somehow isn't. Sonnet 5 ships a new tokenizer. The same text now produces roughly 30% more tokens than on Sonnet 4.6. Anthropic helpfully documents this in the "what's new" page: per-token pricing is unchanged, but the same request costs more.

Simon Willison ran the numbers on real documents. English: 1.42x. Spanish: 1.33x. Python source: 1.28x. Mandarin: roughly flat. If your product is English-language, customer-facing, and token-budgeted, you just took a stealth 30% to 40% effective price increase on a model whose list price did not move. That is not a pricing change. That is a unit-of-account change with the same dollar number on the brochure.

The practical fallout is real. Any max_tokens limit you tuned against Sonnet 4.6 output can now truncate equivalent responses. Any cost forecast you signed off on for Q3 needs to be multiplied by 1.3 before it goes to finance. And if you have a "context window utilization" dashboard that proudly tells customers "your document fits in our 1M token window," the same document no longer fits — the window holds fewer words than it did on June 29.

Three Behavior Changes That Will Break Your Code

Three silent breaking changes shipped with this model. If you migrate by editing a model string, you will hit at least one of them in production.

1. Adaptive thinking is on by default. Requests without a thinking field now run with adaptive thinking enabled. Because max_tokens is a hard cap on thinking-plus-response, every existing prompt that ships max_tokens=1024 for a short classification job is going to start truncating its answers while the model thinks about them. Anthropic's fix is thinking: {type: "disabled"} for workloads that ran without thinking before, or revisiting max_tokens upward.

2. Sampling parameters are gone. Setting temperature, top_p, or top_k to a non-default value returns a 400. This is the same constraint that hit Opus 4.7. If you have a playground-style UI with a temperature slider, that slider is now decorative. If you are calling Claude with temperature: 0.7 from a prompt template you copy-pasted in March, every request 400s. The fix is to remove the parameters and use system-prompt instructions to shape behavior — which is the right answer anyway, but it is a migration tax.

3. Manual extended thinking is removed. The old thinking: {type: "enabled", budget_tokens: N} returns 400. The new shape is thinking: {type: "adaptive"} plus the effort parameter. If you tuned budget_tokens per workflow, that tuning is gone. You get the model's judgment on how hard to think, and you steer it through effort (low/medium/high/max). Anthropic's documentation frames this as progress. It is progress — but it is also less control, and every team with a per-workflow reasoning budget just lost the dial.

python

# Sonnet 4.6 — your current code
client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    temperature=0.3,
    thinking={"type": "enabled", "budget_tokens": 8000},
    messages=[{"role": "user", "content": prompt}],
)
# Sonnet 5 — the migration
client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,            # bigger ceiling: adaptive thinking eats budget
    # temperature=0.3 removed — 400 error
    thinking={"type": "adaptive"},
    extra_body={"effort": "medium"},  # low | medium | high
    messages=[{"role": "user", "content": prompt}],
)

If your test suite does not cover a Sonnet 5 migration, your first production deploy will tell you which of the three you missed.

What Sonnet 5 Is Actually Good At

The agentic gains are the story. Early access partners (Anthropic published quotes, take them as marketing but the claims are directionally consistent) report that Sonnet 5 finishes multi-step software engineering tasks where Sonnet 4.6 stopped short, writes reproducing tests unprompted, traces race conditions in brownfield code, and self-verifies fixes by stashing and reintroducing them. That last one — stash the change, confirm the bug returns, restore the fix — is the kind of behavior that, six months ago, you would have needed an explicit ReAct loop and a tool harness to coax out of a model. Sonnet 5 does it in a single pass.

The computer-use numbers on OSWorld are where Sonnet 5 starts to look like an Opus-class model wearing a Sonnet price tag. On the agentic search evaluation BrowseComp, Sonnet 5 at high effort matches Opus 4.8 at high effort for a fraction of the cost. If your product is anything in the agentic-search, browser-automation, or multi-tool workflow category, the model you should be evaluating is Sonnet 5 at high effort — not Opus 4.8, and definitely not Sonnet 4.6.

The safety story is also genuinely improved. Sonnet 5 has lower rates of hallucination and sycophancy than 4.6, refuses prompt-injection hijacks in agentic contexts more cleanly, and is the first Sonnet-tier model with real-time cybersecurity safeguards (some high-risk cyber requests will be refused outright). It is not safer than Opus 4.8 — Anthropic's automated behavioral audit shows Sonnet 5 has somewhat higher misaligned-behavior rates than the more capable Opus — but for the workloads most teams route through Sonnet, the safety delta vs 4.6 is real and the right direction.

Who Should Migrate Today

Migrate now: any team running Sonnet 4.6 in production for coding agents, browser automation, multi-step tool use, or long-horizon retrieval. The capability gain and the price position are both wins, and the list price is unchanged. You eat the tokenizer tax (~30% on English) but you gain agentic performance that compounds on every workflow longer than two steps.

Stay on Opus 4.8: teams running frontier-reasoning workloads where the 5–10% quality gap compounds — long-form research synthesis, hard multi-document reasoning, any task where you currently route the top 1% of hardest queries to Opus. Sonnet 5 at max effort gets you close, but if you have empirical evidence that the Opus delta moves your business metric, keep the Opus tier for that workload.

Hold on Sonnet 4.6: teams that depend on the old tokenizer (rare, but real — some pipelines do exact token-count arithmetic against saved counts) or teams that rely on manual budget_tokens reasoning controls. The migration is a real refactor and the win is not universal.

Stop buying Opus 4.8 for new builds: there is no greenfield product in July 2026 that should default to Opus 4.8. Sonnet 5 at adaptive thinking plus effort: high is the new default. Opus is for the rare, measured, justified upgrade.

The Take

Anthropic just did to Opus what they did to Haiku when Sonnet 3.5 launched: they compressed the capability curve so hard that the tier above the new release has to justify itself or die. Sonnet 5 is not a model release. It is a pricing tier restructuring disguised as a model release. The list price held, the headline cost held, and the unit of account moved. That is the move.

If you are a developer, your weekend project is migrating your eval suite to Sonnet 5 and re-running it on three workloads before you ship. If you are a platform owner, your Monday is rewriting the cost model your CFO has for the second half of 2026 — the tokenizer change alone invalidates the forecast. If you are at Anthropic's competitors, your roadmap just got a quarter more urgent.

The agentic era was supposed to require the largest, most expensive models. Sonnet 5 is a Sonnet. The era moved without the price tag.

— Mr. Technology

Claude Sonnet 5 Is the Only LLM That Mattered This Week. Anthropic Just Made Opus a Hard Sell.

Claude Sonnet 5 Is the Only LLM That Mattered This Week. Anthropic Just Made Opus a Hard Sell.

The Headline: Sonnet 5 Closes the Gap to Opus 4.8

The Tokenizer Rug Pull Nobody Is Talking About

Three Behavior Changes That Will Break Your Code

What Sonnet 5 Is Actually Good At

Who Should Migrate Today

The Take

Sources