Claude Sonnet 5 vs Sonnet 4.6: What Changed and Should You Upgrade?

Anthropic released Claude Sonnet 5 on June 30, 2026, and it is a drop-in replacement for Sonnet 4.6. You change the model ID and, in most cases, your code keeps working. But “in most cases” is doing some work in that sentence. Sonnet 5 ships with a new tokenizer, adaptive thinking on by default, and a few request parameters that now return errors instead of running. This article walks through exactly what changed, what it costs, and whether the upgrade is worth doing for your workload.

The short version: same price per token, better scores on coding and agentic tasks, three small code changes, and one non-obvious tokenizer catch that affects your token counts and budgets. Read the details before you flip the switch in production.

The upgrade at a glance

Sonnet 5 keeps the same per-token pricing as Sonnet 4.6, so on a per-token basis nothing about your bill changes. It improves on the benchmarks that matter for tool use and coding. And it changes enough about default behavior that a blind swap can surprise you.

Here is the side-by-side.

Everything else that runs on Sonnet 4.6 runs on Sonnet 5 with no other code changes: structured outputs, vision, prompt caching, tool use, and batch all carry over. The one platform feature you lose is Priority Tier, which is not available on Sonnet 5.

What got better: benchmarks

Sonnet 5 is positioned as the most agentic Sonnet model yet, and the reported figures back that up on tool-heavy work. These are Anthropic’s launch benchmarks, corroborated across launch-day writeups. Treat them as reported numbers, not as independent testing.

That is a real jump on the tasks where Sonnet gets used most: writing and fixing code with tools in the loop, and driving a computer or terminal. Anthropic also reports Sonnet 5 lands close to Opus 4.8 once tools are involved, within a few points on agentic tasks, while costing far less. If your app is agent-shaped, this is the upgrade you were waiting for. For the head-to-head against the premium model, see Sonnet 5 vs Opus 4.8.

Sonnet 5 is also safer than 4.6 on Anthropic’s measures: a lower rate of undesirable behaviors, lower hallucination and sycophancy, and better resistance to prompt injection. It is the first Sonnet-tier model with real-time cybersecurity safeguards. One behavior to know: a refusal of a prohibited request comes back as a successful HTTP 200 with stop_reason: "refusal", not as an error. Handle that stop reason in your response parsing.

The three real code changes

Most migrations only touch these three things. Review them, adjust where needed, and the rest of your integration is unchanged.

1. Adaptive thinking is now on by default

On Sonnet 4.6, no thinking field meant no thinking. On Sonnet 5, a request with no thinking field runs with adaptive thinking on. The model decides how much to think based on the task, and you steer the depth with the effort parameter (low, medium, high, or xhigh).

This matters because max_tokens is a hard cap on total output, and total output now includes thinking tokens plus your response text. A max_tokens that was sized for response text alone on 4.6 may now truncate your answer on Sonnet 5, because thinking eats into the same budget.

If a workload previously ran without thinking and you want to keep it that way, turn thinking off explicitly:

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    thinking={"type": "disabled"},
    messages=[
        {"role": "user", "content": "Return the OpenAPI 3.1 path object for GET /invoices/{id}."}
    ],
)

print(response.content[0].text)

To use adaptive thinking with a controlled depth, set the effort instead of disabling it:

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=8192,
    thinking={"type": "adaptive"},
    effort="medium",
    messages=[
        {"role": "user", "content": "Draft integration tests for the POST /orders endpoint."}
    ],
)

Note the shape: thinking={"type": "adaptive"}, not a token budget. That leads to the next change.

2. Manual extended thinking is removed

The old thinking: {type: "enabled", budget_tokens: N} pattern returns a 400 error on Sonnet 5. It was already deprecated on 4.6, so most current code has moved off it, but check for it. Replace any manual budget with adaptive thinking and the effort parameter. If you were setting a large budget_tokens for hard tasks, effort="high" or effort="xhigh" is the replacement lever.

3. Sampling parameters now return 400

Setting temperature, top_p, or top_k to a non-default value returns a 400 error on Sonnet 5. Omitting them, or leaving them at their default, is fine. This constraint was already on Opus 4.7 and later; it is new for the Sonnet class.

If you relied on temperature=0 for deterministic-feeling output, remove it and steer behavior through your system prompt instead. Be explicit about format, tone, and constraints in the instructions rather than through sampling. A quick grep for these parameters across your codebase saves a round of production 400s.

One thing that did not change from 4.6: assistant-message prefilling is still not supported and returns a 400. If you were forcing a response start by prefilling the assistant turn, use structured outputs or output_config.format or system-prompt instructions instead.

The tokenizer catch nobody warns you about

Sonnet 5 uses a new tokenizer. The same input text produces roughly 30% more tokens than it did on Sonnet 4.6, about 1.3x. This is not an API change. Request, response, and streaming shapes are identical, and you write no new code for it. But it changes anything you measure or budget in tokens.

Here is what to re-measure:

• Token counts and usage fields. The same prompt reports more tokens under Sonnet 5. Do not reuse your 4.6 counts. Re-run token counting against claude-sonnet-5 for any prompt you track.
• Your 1M context window holds less text. Each token now covers less text on average, so the same window fits fewer characters of your content. If you were packing context near the limit, verify it still fits.
• max_tokens budgets sized near expected output may truncate. A budget that comfortably held your typical response on 4.6 might clip it on Sonnet 5. Combined with adaptive thinking sharing that budget, this is the most common cause of unexpectedly short answers after an upgrade.
• Per-request cost of equivalent text can be higher. The per-token rate is unchanged, but more tokens per request means more you pay for the same text.

That last point deserves a worked example. Say a prompt plus response was 10,000 tokens on Sonnet 4.6. The same text is roughly 13,000 tokens on Sonnet 5. At an identical per-token rate, that request costs about 30% more even though the price sheet looks unchanged. Model your real workloads with token counting before you assume flat cost parity. The Sonnet 5 pricing breakdown goes deeper on this with the intro-versus-standard math.

You can measure the shift yourself with the token counting endpoint:

curl https://api.anthropic.com/v1/messages/count_tokens \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-5",
    "messages": [
      {"role": "user", "content": "Summarize the changelog for our billing API v3 release."}
    ]
  }'

Run the same call with claude-sonnet-4-6 and compare the counts. That difference is your real budget impact.

What the upgrade costs

Per token, Sonnet 5 costs the same as Sonnet 4.6: $3 per million input tokens and $15 per million output tokens at standard rates. There is an introductory rate of $2 per million input and $10 per million output in effect through August 31, 2026, after which it moves to the standard $3 / $15.

So during the intro window, equivalent text is cheaper per token than 4.6’s standard rate, which partly offsets the tokenizer’s ~30% token increase. After August 31, the per-token rates match 4.6 again, and the tokenizer effect means an equivalent request can cost more than the same request did on 4.6. Model this against your actual traffic. For batch and prompt-caching rates, check Anthropic’s pricing page rather than assuming a fixed discount.

If you are also weighing the older generation on cost, the Sonnet 4.6 pricing and Claude API cost guides give you the baselines to compare against.

Should you upgrade? A verdict by user

The model ID swap is trivial. Whether you flip it depends on what you run.

Upgrade now if you build agents, coding tools, or tool-heavy workflows. This is the clearest win. The SWE-bench Pro and OSWorld gains land exactly where agentic apps live, and the safety improvements reduce undesirable behavior in autonomous loops. Do the three-parameter review, re-measure your token budgets, and ship it.

Upgrade, but test carefully, if you run high-volume production workloads. Same per-token price is good news, but the tokenizer means your total token spend and your max_tokens truncation behavior both shift. Run a token-counting pass and a regression suite before you route real traffic. The intro pricing through August 31 gives you a window to validate at a lower rate.

Upgrade deliberately if you depend on temperature, budget_tokens, or prefilling. These now return 400. The migration is straightforward, moving determinism into your system prompt and swapping budgets for effort, but it is not zero work. Fix these before the swap, not after.

Hold if you specifically need Priority Tier. It is not available on Sonnet 5. If your SLA depends on it, stay on 4.6 for those paths until your requirements change.

For most teams the answer is upgrade, and soon, because you get better agentic performance at the same headline price. Treat it as a real migration with a test pass, not a one-character edit you ship on a Friday. If you are comparing generations more broadly, the Sonnet 4.6 API guide documents the surface you are moving off of.

Catch regressions with a saved request suite in Apidog

The safest way to upgrade is to compare Sonnet 5 against Sonnet 4.6 on your own prompts, not on a benchmark table. That is exactly the kind of before-and-after testing an API platform is built for.

Apidog is an all-in-one API development and testing tool. When you call the Claude API, you are hitting an HTTP endpoint with auth headers, a JSON request body, and a JSON response. Apidog lets you save that request once and re-run it as a reusable collection, which turns a model migration into a repeatable test rather than a manual retry.

A practical migration workflow looks like this:

1. Save your production Messages API requests as an Apidog collection, one per representative prompt.
2. Store your ANTHROPIC_API_KEY as an environment variable so you never paste it into a request body.
3. Set up two environments that differ only by the model value: claude-sonnet-4-6 and claude-sonnet-5.
4. Add assertions on the response shape and on usage token counts, then run the collection against both environments.
5. Compare the two runs. The token-count deltas show you the tokenizer’s real impact on your prompts, and any failed assertion is a regression to investigate before you ship.

You can also mock the Claude endpoint in Apidog to build and test your surrounding integration, including the stop_reason: "refusal" path, without spending tokens. If your app is agent-shaped and calls other tools, Apidog is where you test and mock those downstream APIs too.

Download Apidog to build the comparison suite, or open Apidog in the browser to start from a request. If you are moving off Postman for this, the API testing without Postman guide covers the equivalent flow.

FAQ

Is Claude Sonnet 5 a drop-in replacement for Sonnet 4.6? Mostly. You change the model ID from claude-sonnet-4-6 to claude-sonnet-5, then review three things: adaptive thinking is now on by default (which affects max_tokens), budget_tokens extended thinking returns 400, and non-default sampling parameters return 400. Everything else carries over. See the Sonnet 5 API guide for the full request setup.

Does Sonnet 5 cost more than Sonnet 4.6? Per token, no. Both are $3 per million input and $15 per million output at standard rates. But Sonnet 5’s new tokenizer produces about 30% more tokens for the same text, so an equivalent request can cost more even at the same per-token rate. There is an intro rate of $2 / $10 per million through August 31, 2026.

Why is my response getting cut off after upgrading? Adaptive thinking is on by default on Sonnet 5, and thinking tokens share the same max_tokens budget as your response text. A budget that fit your answer on 4.6 can truncate it now. Raise max_tokens, or set thinking={"type": "disabled"} if you do not want thinking on that call.

Do I need to change my code for the new tokenizer? No. Request, response, and streaming shapes are identical, so no code changes are required. But you should re-measure anything budgeted in tokens: token counts, max_tokens sizing, and per-request cost estimates. Do not reuse your Sonnet 4.6 token counts.

What happened to temperature and budget_tokens? Both now return a 400 error on Sonnet 5 when set to non-default values. Remove non-default temperature, top_p, and top_k, and steer behavior through your system prompt. Replace budget_tokens extended thinking with adaptive thinking plus the effort parameter. The Fable 5 and Mythos API changes guide covers the same pattern on the higher tier.