Claude Sonnet 5 Review (2026): What It Really Costs, Where It Beats Opus, and the Tokenizer Catch

The one-line verdict

Switch to Sonnet 5 for agents, coding, and tool-heavy automation, and price the tokenizer change before you assume it got cheaper.

Anthropic shipped Sonnet 5 on June 30, 2026 as the most agentic Sonnet model it has made: it plans multi-step work, drives tools like browsers and terminals, and finishes tasks that previous Sonnet models would stall on. It runs at effort=high by default on the API and in Claude Code, and at that setting it approaches Opus 4.8 on some tasks while listing at a fraction of the price. For most people already living in Claude Code or building agents, it is the right default now.

The reason to slow down is money, not capability. The launch pricing looks like a cut, but a new tokenizer counts the same text as roughly 30% more tokens, and there are three breaking API changes that will 400 your requests if you migrate without reading them. Both are below.

What actually changed since Sonnet 4.6

Sonnet 5 is a drop-in upgrade for Sonnet 4.6 that trades a bit of manual control for a lot more autonomy.

The headline gain is agentic follow-through. Anthropic's own framing is that the clearest recent capability jumps had been in the Opus-class models, and Sonnet 5 narrows that gap: its performance sits close to Opus 4.8 at lower prices, with a much wider range of cost-and-speed options than Sonnet 4.6 offered. It improves over 4.6 on reasoning, tool use, coding, and knowledge work, and early-access partners described it finishing multi-step software tasks and checking its own output without being asked. On the benchmarks Anthropic highlights, agentic search (BrowseComp) and computer use (OSWorld-Verified), it is a strict improvement over 4.6 and can match Opus 4.8 at higher effort on some tasks. It is also, per Anthropic's safety write-up, less prone to undesirable behaviors than 4.6 and notably weaker at cybersecurity tasks than the current Opus models, which for most business use is a feature, not a loss.

The single most useful behavior change: adaptive thinking is on by default. On Sonnet 4.6, a request with no thinking field ran without thinking. On Sonnet 5, that same request thinks adaptively. You get better answers out of the box, but because max_tokens caps thinking plus response text together, an output limit you tuned for 4.6 can now truncate the visible answer. Revisit max_tokens on any workload that used to run without thinking.

:::callout{variant="note" title="Plain-English: what "agentic" means here"}
An agentic model doesn't just answer, it acts: it breaks a goal into steps, calls tools (a browser, a terminal, an API), reads the results, and keeps going until the job is done. "More agentic" means it stalls less often halfway through a multi-step task. That is exactly the work that used to require a bigger, pricier model.
:::

The real price: the whole Claude 5 ladder

Sonnet 5 lists at $2 per million input tokens and $10 per million output tokens as introductory pricing through August 31, 2026, then $3 input and $15 output after that. Here is where that lands against the rest of the family, with today's numbers:

Read the ladder in ratios and the decision gets simple. At intro pricing Sonnet 5 costs 40% of Opus 4.8 per token; even at the post-August standard rate it is 60% of Opus. Going the other way, it is 3x the price of Haiku 4.5 at standard pricing, and Haiku tops out at a 200k context window versus Sonnet 5's full 1M. So Sonnet 5 is the middle seat by design: cheaper than Opus, materially more capable than Haiku, with the same 1M context and 128k output ceiling as the flagships.

One spec that quietly matters for long jobs: Sonnet 5 keeps the 1M-token context as both default and maximum (there is no smaller-context variant), and can push to 300k output tokens on the Batch API with the output-300k-2026-03-24 beta header. What it loses versus the Opus tier is Priority Tier access, which is not offered on Sonnet 5.

The tokenizer tax nobody prices in

The sticker price fell; the effective price per unit of work did not fall as far, because Sonnet 5 ships a new tokenizer that turns the same text into about 30% more tokens than Sonnet 4.6.

A tokenizer is the part of the model that chops your text into the billable units called tokens. Sonnet 5's is different from 4.6's, and Anthropic states plainly that the same input text produces roughly 30% more tokens (the exact figure depends on the content). The per-token price is unchanged. But you pay per token, so if a request that tokenized to 10,000 tokens on 4.6 now tokenizes to about 13,000, an equivalent job costs about 30% more before you account for the price change itself. It also means your 1M context window holds less actual text, and a max_tokens limit sized against 4.6 output can now cut a response off early.

The practical rule: stop reusing token counts measured against older models, and re-measure against Sonnet 5. If you built cost forecasts, per-request budgets, or context-packing logic on 4.6 numbers, they are now optimistic. This is the same pattern that hit the Opus line earlier, which I broke down in the Opus 4.7 tokenizer change; the fix is the same: recount, then decide.

None of this makes Sonnet 5 expensive. At intro pricing it is still far below Opus for comparable output. It means the honest comparison is "$2 sticker minus a real capability gain plus a ~30% token overhead," not "it got cheap." Do the arithmetic on your own workload before you assume savings.

Three breaking changes before you flip the switch

Migrating from 4.6 is mostly painless, but three requests that worked yesterday now return a 400 error. Handle these first or your agent loop dies on the first call.

# Fails on Sonnet 5 (returns 400)
resp = client.messages.create(
    model="claude-sonnet-5",
    temperature=0.7,
    thinking={"type": "enabled", "budget_tokens": 32000},
    max_tokens=4000,
    messages=[...],
)

# Works: no sampling params, adaptive thinking, roomier max_tokens
resp = client.messages.create(
    model="claude-sonnet-5",
    thinking={"type": "adaptive"},
    max_tokens=8000,
    messages=[...],
)

Sonnet 5 vs Opus 4.8: when the cheaper model is the right one

For agentic coding and tool-use automation, Sonnet 5 at effort=high is the default choice, and you step up to Opus 4.8 only when a task genuinely needs the ceiling.

The case for Sonnet 5 is the effort dial. It exposes the same medium/high/extra-high effort levels as the Opus tier, and Anthropic's own cost-performance curves show it covering a much wider range than 4.6: strong efficiency at medium effort, and at higher effort it reaches Opus 4.8's capability on some tasks. Since it costs 40% of Opus at intro pricing (60% after August), the math favors starting on Sonnet 5 and only escalating specific hard tasks to Opus, rather than paying the Opus rate on everything.

The case for staying on Opus 4.8 is narrow but real: work where the top of the capability curve pays for itself, the hardest agentic coding, long autonomous runs where a single failed step is expensive, or anything where "matches on some tasks" is not good enough because the tasks that matter are the ones it doesn't match. If you are delegating unattended production work at scale, the price gap can be cheaper than one bad Sonnet run.

The honest reception: why some people call it a downgrade

The community reaction has been split, and pretending otherwise would be dishonest. Alongside the "finishes tasks 4.6 couldn't" praise, public threads on r/ClaudeAI this month include ones titled bluntly "Sonnet 5 is a downgrade," plus a steady run of "is it actually worth using" and "what's the consensus" posts. That gap between Anthropic's "close to Opus 4.8" framing and some users' lived feel is worth naming.

Two things explain most of it. First, adaptive-thinking-by-default changes response shape and latency, so workflows tuned to 4.6's terser, no-thinking output can feel different even when quality is up. Second, the tokenizer change makes cost comparisons look worse until people re-measure, which reads as "more expensive" before it reads as "different tokenizer." Neither means the model is bad; it means a drop-in upgrade is never quite drop-in. Test it on your actual prompts before you trust anyone's verdict, mine included.

Who should switch and who should wait

Migrating a coding or agent setup and want the pieces that actually matter dialed in first? Grab the free Claude Code + Codex setup checklist, the configuration and cost-control steps worth running before you switch a model in production, and get each new model breakdown as it ships.