Anthropic switched the default model on the Free and Pro plans to Claude Sonnet 5 the day it launched, so most people reading this are already using it whether they picked it or not. The pitch is simple: the most agentic Sonnet yet, close to Opus 4.8 on real work, at a fraction of the price. Whether that holds up depends on what you actually run it against.
This guide covers what changed in Sonnet 5, how the specs and pricing compare to Opus 4.8 and the Sonnet 4.6 it replaces, the new tokenizer that quietly moves your bill, and how it did when we handed it five real DevOps tasks and graded every one with the actual linter. It ends with the part people skip: what that tokenizer change does to your token spend. Every figure below comes from running claude-sonnet-5 against the Claude API in July 2026.
What is new in Claude Sonnet 5
Sonnet 5 released on June 30, 2026 with the API model ID claude-sonnet-5. Anthropic positions it as a capability jump over Sonnet 4.6 at the same per-token price, landing close to Opus 4.8 on coding and agentic tasks. It is a drop-in replacement for Sonnet 4.6, but three behavior changes will bite anyone who upgrades on autopilot.
Adaptive thinking is on by default. On Sonnet 4.6, a request with no thinking field ran without thinking. On Sonnet 5 the same request thinks. Because max_tokens caps thinking plus response together, a limit tuned for the old no-thinking behavior can now truncate your output. Pass thinking: {type: "disabled"} to turn it off.
Sampling parameters are rejected. Setting temperature, top_p, or top_k to anything other than the default returns a 400 error. Remove them and steer behavior with the system prompt instead. Opus 4.7 introduced this constraint first; Sonnet 5 is the first Sonnet-class model to enforce it.
Manual extended thinking is gone. The old thinking: {type: "enabled", budget_tokens: N} block returns a 400 error. Use adaptive thinking with the effort parameter instead. If you are coming from a Sonnet 4.6 integration that still sets a token budget, this is the line that breaks.
Two more things worth knowing. Sonnet 5 ships a new tokenizer that produces roughly 30% more tokens for the same text, which matters more than it sounds and gets its own section at the end. And it is the first Sonnet-tier model with real-time cybersecurity safeguards: a refused request comes back as a normal HTTP 200 with stop_reason: "refusal", not an error, so handle that stop reason in code that touches security-adjacent prompts.
Sonnet 5 vs Opus 4.8: specs, price, and which to pick
The real decision for most teams is Sonnet 5 or Opus 4.8, because Sonnet 4.6 is now the model you are leaving. Here is how the two current tiers line up on the specs that change a buying decision.
| Spec | Claude Sonnet 5 | Claude Opus 4.8 |
|---|---|---|
| API model ID | claude-sonnet-5 | claude-opus-4-8 |
| Context window | 1,000,000 tokens (default and max) | 1,000,000 tokens |
| Max output | 128,000 tokens | 128,000 tokens |
| Thinking | Adaptive, on by default | Adaptive, effort levels |
| Sampling params | Rejected (400) | Rejected (400) |
| Standard price (in / out) | $3 / $15 per million | $5 / $25 per million |
| Intro price (through Aug 31, 2026) | $2 / $10 per million | Not applicable |
At standard pricing, Sonnet 5 costs 60% of what Opus 4.8 does on both input and output, so it is 40% cheaper per token, and cheaper still during the introductory window. On raw benchmark scores Opus 4.8 still leads on the hardest agentic coding, which is exactly what the price gap buys. Anthropic’s own framing is that Sonnet 5’s largest gains over 4.6 are in coding and agentic tasks; it still recommends starting with Opus 4.8 for genuinely complex agentic coding. In our own testing, Sonnet 5 landed close enough that most everyday workloads will not feel the difference. The published benchmark tables live on Anthropic’s Transparency Hub.
For most people, Sonnet 5 is the right default and the money-saver. Reach for Opus 4.8 when the task is genuinely hard agentic coding, a long autonomous session where an extra few points of reliability pays for itself, or when you need Priority Tier, which Sonnet 5 does not offer. If you were happy on Sonnet 4.6, Sonnet 5 is a straight upgrade at the same rate card. We tested the coding claim ourselves rather than take the benchmark chart on faith.
We ran Sonnet 5 on five real DevOps tasks
Benchmarks are abstract. What a DevOps engineer wants to know is whether the model writes config that passes the tools you already run in CI. So we gave Sonnet 5 five concrete asks over the API, extracted the file it produced, and graded each one with the real linter, the same way we put Grok 4.5 through graded DevOps tasks. No cherry-picking, no retries.
| Task | Graded with | Result |
|---|---|---|
| Multi-stage Node.js Dockerfile | hadolint | Pass, one style warning |
| PostgreSQL backup script (Bash) | shellcheck | Clean |
| Deployment + Service (Kubernetes) | kubeconform -strict | 2 resources valid |
| Pull-request CI (GitHub Actions) | actionlint | Clean |
| AWS VPC (OpenTofu) | tofu fmt + tofu validate | Both pass |
Four of the five came back completely clean under the strictest check we had. The Dockerfile was a genuine three-stage build on a pinned node:22.11.0-bookworm-slim base, installed production dependencies only, created a dedicated non-root user, and set a HEALTHCHECK. Its single hadolint hit was DL3008: it ran apt-get install curl without pinning the package version. A real nit, and the only one across the batch.
The Kubernetes manifest is the one worth calling out. Asked for a hardened Deployment, it set CPU and memory requests and limits, added liveness and readiness probes, and applied a security context with runAsNonRoot, readOnlyRootFilesystem, and every Linux capability dropped. That is the posture most hand-written manifests miss. It cleared kubeconform in strict mode with both resources valid.
Here is the graded run, top to bottom, with the exit status of each tool:
The whole run cost $0.0439 at introductory pricing and took 38.9 seconds across all five tasks, 578 input tokens and 4,272 output tokens in total. That is production-grade infrastructure config, tool-verified, for four cents. The bash script and the OpenTofu VPC were the token-heavy ones because they carried the most logic; the CI workflow came back tight and correct at 29 lines.
Switch Claude Code to Sonnet 5
If you use Claude Code, the switch is one slash command inside a session. Pick the model from the interactive picker:
/model claude-sonnet-5You can also launch a one-shot run pinned to the model and confirm the CLI is actually talking to Sonnet 5:
claude --model claude-sonnet-5 --print "reply with your model id"Not on Claude Code yet? The install steps for Ubuntu get you set up in a couple of minutes, and the same model switch applies once you are in.
For direct API and SDK users, the migration is a model-ID swap plus three cleanups. Change the identifier first:
model = "claude-sonnet-4-6" # before
model = "claude-sonnet-5" # afterThen drop any temperature, top_p, or top_k you set, remove budget_tokens in favor of adaptive thinking, and recount your prompts under the new tokenizer so a max_tokens limit sized for 4.6 does not clip your responses. The screenshot below is a raw API call confirming the model and the returned usage counts:
Tool definitions and response shapes are unchanged, so a well-behaved Sonnet 4.6 integration needs nothing else. If you are watching spend, our notes on how to keep Claude Code token usage down still apply, and matter more under the new tokenizer.
What the new tokenizer does to your token bill
This is the part that catches people, and it is why per-token pricing alone is misleading. Sonnet 5’s tokenizer produces roughly 30% more tokens for the same text than Sonnet 4.6 did. The per-token rate is identical at $3 and $15, so nothing changed on the price card, but the same request now counts more tokens and therefore costs more. The increase depends on content: Simon Willison’s testing put English text around 1.4x, Python code around 1.28x, and Simplified Chinese roughly flat.
Our five-task run is a concrete anchor. It metered 4,850 tokens and cost $0.0439 under the introductory $2 / $10 rates. After the introductory window closes on August 31, 2026, the standard $3 / $15 rates put the same work near $0.066. Now layer the tokenizer on top: an identical batch that would have metered around 3,700 tokens on Sonnet 4.6 lands near 4,850 on Sonnet 5, so a bill you sized against 4.6 undershoots by roughly a third before the rate change even lands.
The practical takeaway: if you budget or rate-limit by token count, do not reuse numbers measured against Sonnet 4.6 or any earlier model. Recount your real prompts with the token-counting endpoint, then reset your max_tokens limits and any per-request cost alerts. Sonnet 5 is still far cheaper than Opus 4.8 and a clear upgrade over 4.6, but the win is smaller than the flat $3 / $15 card suggests, and the gap between the sticker rate and the real invoice is entirely the tokenizer. See the official what’s-new notes for the full migration checklist before you flip production traffic.
