Skip to main content

Claude Sonnet 5: The Field Guide

Intermediate

On 30 June 2026 Anthropic shipped Claude Sonnet 5 (claude-sonnet-5) and, quietly, made it the default model in Claude Code. On paper it's a drop-in for Sonnet 4.6 at the same list price. In practice, three API constraints will make naive migrations return 400 Bad Request, a new tokenizer produces roughly 30% more tokens for the same text (which changes both your context budget and your per-request bill), and the effort scale has shifted enough that "keep everything the same" isn't the same. If you were on Sonnet 4.6 at high, running Sonnet 5 at high is closer to Sonnet 4.6 at max.

This page is the practical field guide: what changed, what breaks, the exact migration checklist, the pricing math on the tokenizer shift, and the prompting patterns most teams re-tune first.

What you'll learn
  • Understand what Sonnet 5 actually is — 1M context by default, adaptive thinking on by default, first Sonnet with real-time cybersecurity safeguards
  • Know the three API constraints that will 400 your existing code and the one-line fix for each
  • Model the new-tokenizer pricing math: same $/token but ~30% more tokens = a different per-request bill
  • Re-calibrate effort levels: Sonnet 5 medium ≈ Sonnet 4.6 high, and Sonnet 5 high ≈ Sonnet 4.6 max
  • Adjust the prompting patterns that shift the most: verbosity, tool-use triggering, code-review recall, and design defaults

The one-paragraph version​

Sonnet 5 is the balanced "start here" Sonnet tier, positioned above Sonnet 4.6 at the same list price and now the Claude Code default. It supports the 1M-token context window by default (there is no smaller-context variant), a 128k max output, and adaptive thinking on by default. Three API contracts break on migration: manual extended thinking (thinking: {type: "enabled", budget_tokens: N}) is removed and returns a 400, non-default sampling parameters (temperature, top_p, top_k) return a 400, and the tokenizer changed — the same input text produces roughly 30% more tokens than on Sonnet 4.6. Priority Tier is not available on Sonnet 5. That's the whole shape of the release.

Why "drop-in" needs an asterisk​

Anthropic's own docs describe Sonnet 5 as a "drop-in replacement for Claude Sonnet 4.6" — and for prompt content, that's true. But the API surface changed enough that "swap the model string and ship" will produce errors on requests that ran fine yesterday. There are four things that will bite you, in order of how often we see them break integrations:

  • temperature, top_p, or top_k set to non-default values now return 400. Not silently ignored. Not clipped. A hard error. This is new for Sonnet-class models; Opus 4.7 introduced the same constraint. If your SDK wrapper always sends temperature: 0.7, it will now always fail.
  • Manual extended thinking is removed. thinking: {type: "enabled", budget_tokens: N} was deprecated on 4.6 and returns 400 on Sonnet 5. Use adaptive thinking with the effort parameter instead.
  • Adaptive thinking is on by default. Requests without a thinking field on Sonnet 4.6 ran without thinking; on Sonnet 5, they run with adaptive thinking. max_tokens is a hard cap on total output — thinking plus response text — so a limit sized for "just the answer" on Sonnet 4.6 can truncate the answer on Sonnet 5.
  • The new tokenizer produces roughly 30% more tokens for the same text. Not an API change — request and response shapes are identical — but everything you measure or budget in tokens now measures higher.

The API constraints that will 400 you​

Guided walkthrough1 of 4
  1. Remove any temperature, top_p, or top_k that isn't the API default. If your app needs stylistic variety, use system-prompt instructions instead of temperature (that's now the only lever). If you need diverse design outputs, ask the model to propose N distinct directions and pick one — that gives you variety across runs even with fixed sampling.

Minimal safe migration — one diff

# Before (Sonnet 4.6) — worked
response = client.messages.create(
  model="claude-sonnet-4-6",
  max_tokens=4096,
  temperature=0.7,                          # 400 on Sonnet 5
  thinking={"type": "enabled",
            "budget_tokens": 8000},         # 400 on Sonnet 5
  messages=[...],
)

# After (Sonnet 5) — one-liner replacements
response = client.messages.create(
  model="claude-sonnet-5",
  max_tokens=8192,                          # raise: thinking now shares the budget
  # temperature removed — use system prompt instead
  # thinking removed — adaptive is on by default
  extra_body={"effort": "high"},            # was implicit in budget_tokens
  messages=[...],
)

The tokenizer shift is a pricing story, not an API story​

The new tokenizer is the change most likely to surprise your finance team. Requests and responses look identical over the wire, but the same input text produces roughly 30% more tokens than on Sonnet 4.6. The exact multiplier depends on the content — code, English prose, non-English text, and structured data all shift differently — but 30% is the number Anthropic quotes.

Three things this changes at the same time:

  • Per-request cost. Per-token pricing is unchanged from Sonnet 4.6 at $3 / $15 per MTok standard (and $2 / $10 through 31 August 2026). But if the same text produces 30% more tokens, the same text costs about 30% more once the standard rate kicks in.
  • Context capacity in text terms. The context window is still 1M tokens, but each token now covers less text on average. The same document takes up ~30% more of your window.
  • max_tokens truncation risk. An output cap tuned for "roughly this much text" on Sonnet 4.6 can silently truncate equivalent output on Sonnet 5. Revisit any limit sized close to your expected output length.

The pricing math, laid out honestly:

PeriodList priceSame text → cost vs Sonnet 4.6
Now → 31 Aug 2026 (introductory)$2 in / $10 outRoughly 13% cheaper (30% more tokens × $2 vs. Sonnet 4.6 at $3)
From 1 Sep 2026 (standard)$3 in / $15 outRoughly 30% more expensive for equivalent text

If you're pricing an app on introductory tokens and haven't modeled the 1 September flip, you're going to notice.

Recount your prompts under the new tokenizer

# Recount before you migrate — don't trust old numbers
count = client.messages.count_tokens(
  model="claude-sonnet-5",     # count under the NEW tokenizer
  messages=[{"role": "user", "content": your_prompt}],
  system=your_system,
)
print(count.input_tokens)        # roughly 30% higher than on claude-sonnet-4-6

The effort scale shifted — recalibrate before you compare​

The effort parameter (low / medium / high / xhigh / max) still has the same five values, but Anthropic gives an explicit cross-model mapping when migrating that most teams miss on first read:

  • Sonnet 5 at medium ≈ Sonnet 4.6 at high.
  • Sonnet 5 at high ≈ Sonnet 4.6 at max.
  • xhigh is recommended for the hardest coding and agentic tasks.
  • max removes token-spending constraints entirely.

Two implications:

  • If you were running Sonnet 4.6 at high and swap the model without changing effort, you're now running with more thinking, more tokens, and probably better outputs — but a bigger bill. Consider dropping to medium.
  • If you were running Sonnet 4.6 at max and swap to Sonnet 5 at max, you may be paying for headroom you don't need. Try xhigh first.

Anthropic also warns Sonnet 5 respects effort strictly, especially at the low end. low and medium scope work to what was asked; they don't "go above and beyond." That's good for latency and cost, but on moderately complex tasks at low there's a real risk of under-thinking. The recommended fix is to raise effort rather than prompt around it.

Sonnet 5 is the Claude Code default now — what changes​

As of Claude Code v2.1.197 (30 June 2026), claude-sonnet-5 is the default model. If you don't set anything, your sessions run on Sonnet 5. Practical consequences:

  • You get 1M context, but your max_tokens and effort settings are inherited. Claude Code's defaults are tuned for the new model; custom CLAUDE.md configs that pinned max_tokens or set an effort override should be re-verified.
  • Faster, more agentic default behavior. Sonnet 5 is more agentic than Sonnet 4.6 out of the box — it reaches for tools and runs self-verification loops more readily. If you were used to Claude Code being conservative about running commands, expect more initiative.
  • Regular user-facing progress updates. Sonnet 5 already provides higher-quality interim updates on long traces. Prompt scaffolding like "after every 3 tool calls, summarize progress" can usually be removed.
  • Sonnet 4.6 is now a legacy model. Still available (pin claude-sonnet-4-6 if you have a reason), but no longer the on-ramp.

The four prompting patterns most teams re-tune​

1. Verbosity calibrates to task complexity​

Sonnet 5 chooses response length based on the complexity of the task rather than defaulting to a fixed verbosity. Simple lookups get shorter answers; open-ended analysis gets longer ones. If your product wants a consistent style, tune the prompt — Anthropic's own snippet works:

Tame verbosity when you need a fixed voice

Provide concise, focused responses. Skip non-essential context, and keep examples minimal.

Positive examples ("here's how to phrase this concisely") work better than negative ones ("don't over-explain").

2. Tool-use triggering is more agentic — and can be dialed​

Sonnet 5 reaches for tools more readily than 4.6. Two levers:

  • Effort. high or xhigh show substantially more tool usage in agentic search and coding workloads. low and medium scope the work tightly.
  • Thinking off. With thinking: {type: "disabled"}, the model is less likely to reach for tools. If you disable thinking but still rely on tool calls, add an explicit nudge in the system prompt.

3. Code-review harnesses may see recall drop — that's the model being more literal​

If your review prompt says "only report high-severity issues" or "don't nitpick," Sonnet 5 may follow that faithfully — investigating just as thoroughly, finding the same bugs, then not reporting findings it judges below your stated bar. Precision typically rises, recall can appear to fall. Anthropic's recommended fix separates the finding stage from the ranking stage:

Recall-oriented code-review prompt for Sonnet 5

Report every issue you find, including ones you are uncertain about or consider low-severity.
Do not filter for importance or confidence at this stage - a separate verification step will do that.
Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug.
For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

You don't need to actually build the second step for the prompt to help — moving confidence filtering out of the finding step is what changes behavior.

4. Design defaults settle into a "house style" — override it explicitly​

On open-ended frontend and design briefs, Sonnet 5 tends toward a consistent default visual style. That reads well for some products, wrong for dashboards, dev tools, fintech, healthcare, or enterprise apps. Generic pushback ("make it less generic") tends to shift the model to a different fixed style rather than producing variety. Two patterns that work:

  • Specify a concrete alternative — hex codes, typeface names, layout rules. Sonnet 5 follows explicit specs precisely.
  • Ask the model to propose N options before building. Because non-default temperature returns 400, this is now the recommended way to produce meaningfully different design directions across runs.

Force design variety without temperature

Before building, propose 4 distinct visual directions tailored to this brief
(each as: bg hex / accent hex / typeface, plus a one-line rationale).
Ask the user to pick one, then implement only that direction.

Cybersecurity safeguards: refusals as HTTP 200​

Sonnet 5 is the first Sonnet-tier model with real-time cybersecurity safeguards. When a request is declined, it returns as a successful HTTP 200 with stop_reason: "refusal" — not an error. If you have not built out a refusal-handling branch, your app will treat the empty response as a successful empty answer and quietly ship it to the user.

The fix is one branch on the response:

Handle refusals cleanly

resp = client.messages.create(model="claude-sonnet-5", messages=[...])
if resp.stop_reason == "refusal":
  # Show a graceful message. Optionally retry on a fallback model
  # (Opus 4.8 is a common choice). You are NOT billed for a refusal
  # returned before any output was generated.
  return handle_refusal(resp)
# Otherwise process resp.content as normal

This is the same shape as Fable 5's in-band refusals — if you already handle those, you're covered. If you're new to it, see the Fable 5 field guide for the fuller pattern including the fallbacks parameter.

Priority Tier is not available — plan around it​

Every other current Anthropic model supports Priority Tier for reserved capacity and predictable latency. Sonnet 5 does not. If you have an enterprise workload that depends on Priority Tier commitments today, your options are:

  • Keep the workload on Sonnet 4.6 (still supported, still on Priority Tier).
  • Migrate the workload to Opus 4.8, which is on Priority Tier and is the model Sonnet 5 gets compared against for hard tasks anyway.
  • Move to standard tier on Sonnet 5 and accept unreserved capacity.

There's no beta header workaround. If Priority Tier is load-bearing for you, this is the migration blocker to plan around first.

Sonnet 5 vs Sonnet 4.6 vs Opus 4.8 — the pick​

ChoicePick it when
Sonnet 5Default for anything new. Coding, agentic tasks, 1M context, and price sensitivity all point here.
Sonnet 4.6You need Priority Tier, you have prompts that depend on non-default sampling params you can't rewrite yet, or you're mid-eval and want a stable baseline.
Opus 4.8Reasoning depth or long-run stability that Sonnet 5 doesn't reach, or you need Priority Tier at the top end. Pair with an effort override — xhigh on Opus 4.8 is a common sweet spot.
Fable 5 / Mythos 5You've validated that Opus 4.8 isn't enough and you're willing to pay 5× Sonnet 5 output pricing for multiday autonomous runs. See the Fable 5 field guide.

Migration checklist​

Guided walkthrough1 of 6
  1. Use the token counting API with model="claude-sonnet-5" for every prompt whose length matters. Anywhere you compare against a fixed 1M-token budget, assume ~30% more usage. Anywhere max_tokens is tight, raise it.

Quick check​

Check yourself

0/5
  1. Your existing Sonnet 4.6 code sets temperature: 0.7 and thinking: {type: "enabled", budget_tokens: 8000}. You swap the model to claude-sonnet-5. What happens?
  2. You measured a system prompt at 40,000 tokens on Sonnet 4.6. Roughly how many tokens should you expect the same text to count as on Sonnet 5?
  3. You have an enterprise workload on Sonnet 4.6 with a Priority Tier commitment. You want to migrate to Sonnet 5. What's the blocker?
  4. According to Anthropic's cross-model effort mapping, running Sonnet 5 at effort=medium is roughly comparable in intelligence to running which Sonnet 4.6 setting?
  5. Your Sonnet 5 request returns an HTTP 200 response with content: [] and stop_reason: "refusal". What did NOT happen?

Sources & further reading​