Claude Sonnet 5.5: faster mid-tier coding without a list-price rise
Sonnet 5.5 kept Sonnet 5's $2 and $10 token prices, then had its cache-read price halved. What that does to coding costs, and where Opus 5.5 still leads.
For most teams using Claude for coding, the Sonnet tier is the daily driver: good enough for most tickets, cheaper and faster than Opus. Anthropic released Claude Sonnet 5.5 on 28 September 2026 at the same per-token prices as Sonnet 5, and on 7 October halved its cache-read price. With faster output and fewer tokens per task on top, the cost of a typical agent session has moved down twice in two weeks. This article sets out what changed, what the benchmarks do and don't show, and where Opus 5.5 remains the better choice.
What Anthropic released
The Sonnet 5.5 announcement positions it as a faster, lower-cost complement to Opus 5.5. Anthropic describes Opus 5.5 as built for complex work requiring careful judgement, and Sonnet 5.5 as strongest at well-scoped everyday tasks and bug fixing. The model ID on the Claude Platform is claude-sonnet-5-5, and it is available on Amazon Web Services, Google Cloud and Microsoft Azure as well.
Anthropic makes three cost and speed claims against Sonnet 5:
- Output is generated more than 30% faster.
- It "typically needs far fewer tokens to do the same work", and in Anthropic's testing costs up to 30% less per task.
- At low or medium effort it beats Sonnet 5's best score on several benchmarks for about a tenth of the cost per task.
Prices, and the 7 October change
At launch, Sonnet 5.5 kept Sonnet 5's prices. Nine days later, the Haiku 5.5 announcement cut its cache-read price by half. Current list prices per million tokens:
| Rate | Sonnet 5.5 at launch, 28 September | Sonnet 5.5 from 7 October | Opus 5.5, as listed on 28 September |
|---|---|---|---|
| Input | $2.00 | $2.00 | $4.00 |
| Output | $10.00 | $10.00 | $20.00 |
| Cache reads | $0.20 | $0.10 | $0.20 |
| Cache writes | $2.50 | $2.50 | $5.00 |
Anthropic says the cache cut makes Sonnet 5.5 about 20% cheaper on most agentic work, because cache reads are a large share of what agents consume. That makes sense for coding agents, which send a long, mostly unchanged prefix again with every step. The article on prompt caching explains why.
Two cautions on reading these numbers. First, the up-to-30% per-task saving and the 20% cache saving come from different comparisons (against Sonnet 5, and against Sonnet 5.5 before the cut) and should not simply be multiplied together. Second, both are Anthropic's measurements on its own workloads. Your mix of cached and fresh tokens decides how much of either applies.
What the benchmarks show
Anthropic's headline coding result is Terminal-Bench 4.0, where Sonnet 5.5 scores 70.6% against Sonnet 5's 10.3%. Opus 5.5 is listed at 66.4%, at its highest effort setting. On CursorBench 4.0, Sonnet 5.5 scores 55.5% against Opus 5.5's 57.8%. On FrontierCode 1.1, which checks whether an agent's change could be merged without human edits, Sonnet 5.5 scores 52.1% at Xhigh effort and 46.2% at Max, against 54.4% for Opus 5.5.
The FrontierCode result has an instructive footnote. Sonnet 5.5 scored lower at its highest effort setting than one step below, because at Max effort it more often ran a code-review skill that split work across many subagents, which in two cases examined by Cognition led to a timeout or to edits beyond the task's scope. More effort is not always better, and a benchmark that penalises out-of-scope changes will show it.
Anthropic is also clear about limits. It says benchmark scores capture only part of a model's capability, and that in its own and external testing Opus 5.5 "remains clearly stronger at complex, open-ended work requiring sustained judgment".
Small inconsistencies are worth noticing. The Sonnet 5.5 page reports a GDPval-AA score of 1844; the reference column in the Haiku 5.5 page, published nine days later, lists 1840. The difference is minor, but it is a reminder that vendor figures move between pages and runs, and that comparing models across vendors' tables is less precise than it looks.
Changes that affect existing setups
Effort defaults differ by surface. In Claude Code and Anthropic's apps the default effort is Medium; on the Claude Platform it is High. The same model can cost and behave differently depending on where it runs, before anyone changes a setting.
Thinking-off users must migrate. Anyone running Sonnet with thinking off needs to switch to the new between_tools setting, which keeps up-front thinking off, before moving to Sonnet 5.5.
Cyber safeguards are stricter. Sonnet 5.5 is the first Sonnet model to launch with cyber safeguards and fallbacks like those on Anthropic's most capable models. The system card says users "should expect increased refusals" even on benign security-related tasks. Requests blocked by the cyber classifiers fall back to Sonnet 5 automatically in Anthropic's own apps; on the API, developers must opt in to that fallback, and traffic through other platforms may behave differently. The policy allows vulnerability discovery in source code but blocks it in compiled binaries. Security teams that use Sonnet for defensive work should test their own tasks.
Account switching mid-session changed. Anthropic says Sonnet 5.5 expands preserved thinking, so a model's thinking cannot be separated from the account that created it. Teams that switch accounts mid-session in Claude Code should read Anthropic's documentation on the change.
What it means for engineering and security leaders
The decision most teams face is not "Sonnet or Opus" in general, but which one is the default for each kind of work. Anthropic's own framing suggests a split: Sonnet 5.5 for well-scoped tasks with clear acceptance criteria, Opus 5.5 for open-ended design and changes that need judgement across a large codebase. At half Opus's input and output prices, and with output arriving faster, Sonnet 5.5 is a strong default for routine work, provided your own evaluations agree.
The cache cut also changes the comparison with cheaper models. With cache reads at $0.10, a long Sonnet session with a high cache hit rate can cost less than the per-token list prices suggest. Measure cost per completed task, not cost per token.
Practical takeaways
- Re-run a fixed set of real tickets on Sonnet 5.5 at Medium and High effort, and record cost per task and pass rate.
- Check effort settings per surface; Claude Code and the Claude Platform start from different defaults.
- If you run Sonnet with thinking off, migrate to
between_toolsbefore switching models. - Track cache read tokens separately in cost reports, so the 7 October cut shows up where it applies.
- Keep Opus 5.5 as the default for open-ended or architectural work until your evaluations say otherwise.
- If you do defensive security work with Claude, test for refusals and decide whether to opt in to API fallbacks.
Where SpanDock fits
The SpanDock model proxy and budgets page describes rules that swap models, for example sending Claude Code's Opus requests to Sonnet; routing rules are on the Premium plan and up. SpanDock Mind, on Standard and up, looks at the start of each new conversation and chooses a cheaper model when it is good enough, and every call through the proxy records the requested and answering model, tokens and cost. For how the agent around a model affects cost, see the harness sets the bill.