Claude Sonnet 5: Fix These 3 Breaking Changes Now

Claude Sonnet 5 launched on June 30. If you swapped the model ID and moved on, there’s a reasonable chance you’re already getting 400 errors you haven’t tracked down yet — or worse, silent cost increases you haven’t noticed. Anthropic introduced three breaking changes that affect most existing integrations, plus a tokenizer update that won’t throw any error but will quietly increase what you pay. Here’s what changed and how to fix it before your next deploy.

Breaking Change 1: Sampling Parameters Are Gone

The most widespread change: setting temperature, top_p, or top_k to any non-default value now returns an HTTP 400 error. This catches two groups simultaneously — developers who raised temperature for creative variation and those who set it to zero for determinism. Both patterns break identically on Sonnet 5.

The fix is to remove those parameters entirely. For behavior you previously controlled through sampling, Anthropic’s official release notes recommend system prompt instructions as the replacement path.

# This breaks on Sonnet 5 — even temperature=0
response = client.messages.create(
    model="claude-sonnet-5",
    temperature=0.7,   # 400 error
    messages=[{"role": "user", "content": "..."}]
)

# Fix: remove the sampling parameters entirely
response = client.messages.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "..."}]
)

One nuance worth knowing: the literal default value — temperature=1.0 — is still accepted. Only non-default values error. So if your framework passes temperature explicitly to satisfy a type constraint, check whether it’s sending the default or something custom before assuming everything is broken.

This constraint was already in place for Opus 4.7 and Opus 4.8. Rolling it down to Sonnet-tier is consistent with Anthropic’s push toward adaptive thinking across the model line. The reasoning: adaptive thinking requires the model to control its own sampling during reasoning. External temperature overrides conflict with that architecture.

Breaking Change 2: Manual Extended Thinking Is Removed

If you used extended thinking with thinking: {type: "enabled", budget_tokens: N}, that syntax is gone. It was deprecated on Sonnet 4.6; Sonnet 5 removes it entirely and returns a 400 error. The replacement is adaptive thinking with the effort parameter, which lets Claude determine how much reasoning each request actually needs rather than always consuming your full budget allocation.

# Breaks on Sonnet 5
client.messages.create(
    model="claude-sonnet-5",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},  # 400 error
    messages=[{"role": "user", "content": "..."}]
)

# Working replacement
client.messages.create(
    model="claude-sonnet-5",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}]
)

The effort parameter accepts five levels — max, xhigh, high (default), medium, and low — and acts as soft guidance on thinking depth. See the adaptive thinking documentation for how each level affects latency and token spend.

The Silent Change: 30% More Tokens

This one won’t throw an error. Sonnet 5 uses a new tokenizer that produces approximately 30% more tokens for the same input text. Per-token pricing is unchanged — $3 per million input tokens, $15 per million output at standard rates — but that means the same workload costs roughly 30% more. A request that ran you $0.30 on Sonnet 4.6 may cost $0.39 on Sonnet 5 after the introductory period ends.

Two practical consequences beyond cost: max_tokens limits tuned for Sonnet 4.6 may now truncate your responses mid-output, and the 1M token context window holds proportionally less text in character terms. If your application has tight output requirements, re-run token counting against Sonnet 5 before switching. Do not reuse counts measured on earlier models — they will be wrong.

Introductory pricing ($2/$10 per million tokens through August 31) softens the immediate impact, but plan for the full increase when standard rates take effect on September 1, 2026.

Adaptive Thinking Is Now Default

On Sonnet 4.6, omitting the thinking field meant no thinking. On Sonnet 5, omitting it enables adaptive thinking. If you never used extended thinking in your integration, you’ll still get it now unless you explicitly opt out. This matters for latency and cost: thinking tokens count against your max_tokens limit, so a budget comfortable on Sonnet 4.6 may now leave too little room for actual response text.

# Explicitly disable thinking if you don't want it
response = client.messages.create(
    model="claude-sonnet-5",
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "..."}]
)

# Or opt in with display set to "summarized" to see Claude's reasoning
response = client.messages.create(
    model="claude-sonnet-5",
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[{"role": "user", "content": "..."}]
)

Note that the default thinking display is "omitted" on Sonnet 5. Thinking still happens and you’re still billed for it — you just won’t see it in the response unless you add display: "summarized" explicitly.

Migration Checklist

• Update model ID from claude-sonnet-4-6 to claude-sonnet-5
• Remove temperature, top_p, and top_k parameters, or confirm they are set to defaults
• Replace thinking: {type: "enabled", budget_tokens: N} with thinking: {type: "adaptive"}
• Re-run token counting against Sonnet 5 — do not reuse counts from Sonnet 4.6
• Audit max_tokens limits for potential truncation given the 30% token increase
• Add thinking: {type: "disabled"} if you want no thinking behavior
• Test in staging before deploying to production

When to Migrate

If you’re running agentic workloads or code-heavy pipelines, the capability jump is worth the migration cost. Anthropic reports the largest Sonnet 5 gains in coding and agentic tasks — and the official migration guide shows these are mechanical changes: find where you set sampling parameters, remove them, re-benchmark your token budgets, and you’re done.

The introductory pricing window closes August 31. Migrating now gives you two months to tune your prompts and token budgets under favorable pricing before standard rates take effect. That’s a reasonable window — and the three issues above each take an hour or less to address once you know where to look.