Claude Sonnet 5.5: What Improves, What It Costs, and When to Choose Opus

Claude Sonnet 5.5 arrived on September 28, 2026, six days after Opus 5.5. Anthropic says it generates output more than 30% faster than Sonnet 5 and can cost up to 30% less per task. The qualification matters: its token prices had not fallen at launch. The proposed saving comes from doing the work with fewer tokens. Those are provider claims in the launch announcement, not measurements made by ZharfAI.

For teams choosing a coding assistant or building document workflows, the useful question is where that efficiency survives contact with their own work. A quick first draft has value; a quick draft that needs another model and a long human correction has a different bill. Our reading of the evidence favors testing Sonnet on clearly bounded work while keeping a separate path for difficult decisions.

October 7 pricing update: the Haiku 5.5 announcement cuts Sonnet 5.5 cache reads from $0.20 to $0.10 per million tokens. The table and example below use the new rate; launch-day efficiency claims remain attributed to September 28. See our Haiku 5.5 release coverage for the smaller model and accompanying API credits.

What is available now

The model overview lists claude-sonnet-5-5, text and image input, text output, a one-million-token context window, and a normal output limit of 128,000 tokens. Availability includes the Claude API, Amazon Bedrock, Google Cloud, and Microsoft Foundry. Cloud-specific identifiers and feature support still need checking in the chosen deployment.

A large context window is useful when a task needs several documents together. It does not establish that the model will find every exception inside them. For example, comparing a contract, its amendments, and a pricing appendix should include an explicit requirement to identify conflicts and cite the governing passage. Uploading all three is only the starting point.

We already covered the larger model in our Opus 5.5 release analysis and our reading of its system card. Sonnet adds a cheaper candidate for recurring work; the two models need not take identical roles.

Close benchmark scores do not settle the choice

Anthropic's launch table puts Sonnet 5.5 at 70.6% on Terminal-Bench 4.0, ahead of Opus 5.5's 66.4%. GDPval-AA v2.1 is almost tied: 1,844 versus 1,846. But FrontierCode reports Sonnet at 52.1% with xhigh effort and 46.2% with max. These are published evaluation results, with different effort settings, not a universal ranking.

That last comparison is a useful warning against buying more computation by default. An agent may spend additional time making changes that do not help the requested outcome. If a review rejects those additions, a more elaborate response can become a worse result. For a team adopting the model, acceptance should include both the requested fix and the absence of unrelated edits.

A software task also contains several different judgments: locating a fault, deciding how much to change, verifying behavior, and explaining the result. An aggregate score can conceal a weak step. Evaluate the step that is expensive for your team rather than assuming that a strong terminal score guarantees careful review.

A smaller code-review study reveals different misses

In CodeRabbit's own evaluation, Sonnet 5.5 found six of 13 difficult known issues through actionable comments; Sonnet 5 found four. Opus 5.5 found eight in Standard and ten in Max. Sonnet 5.5 also missed two issues Sonnet 5 caught. The sample is small, and quality scoring for a separate 44-PR run was still pending when the report was published. ZharfAI has not rerun these tests.

The missed cases matter as much as the average improvement. Replacing an existing reviewer can change which defects escape, even when the total number found rises. Before switching, keep a record of the old model's useful catches and replay those examples. A release that improves layout reviews but loses sensitivity to duplicate payments needs a more selective rollout than a single overall score suggests.

This is evidence from a company evaluating a model inside its own commercial review product. It is useful precisely because its workflow is concrete, but that workflow is not every team's workflow. The appropriate next step is a reproducible trial, with the test cases and acceptance rules chosen before the answers arrive.

Pricing: the cache changes the comparison

Current standard rates from the Sonnet overview and the Opus 5.5 model documentation are shown below. All amounts are US dollars per million tokens; this is API pricing, not a Claude subscription comparison.

Here is our arithmetic example, not a measured workload. One turn reads 200,000 cached tokens, adds 10,000 fresh input tokens, and produces 5,000 output tokens, including thinking. Sonnet costs $0.09: $0.02 for the cache read, $0.02 for new input, and $0.05 for output. Opus costs $0.18. Sonnet is 50% cheaper in this fixed-usage example at the October 7 rates.

The calculation excludes writing the cache, tool charges, retries, and human review. It also holds token counts fixed, which real runs will not necessarily do. If Sonnet's answer is rejected and the same task is repeated with Opus, both attempts belong in the cost of the eventual result. A routing strategy only saves money if it avoids enough expensive runs without creating too many failed first attempts.

Set effort deliberately, then test the finish

Anthropic's prompting guide recommends starting bounded coding tasks at medium, moving harder work to high, and retesting effort rather than inheriting Sonnet 5 settings. It warns that lower effort can skip verification or stop before a long task is complete. The API default is high; the Claude apps and Claude Code use medium, as the launch page explains.

For an internal trial, give the model a finish condition that a reviewer can check. “Fix the duplicate-invoice bug, reproduce the failure, and show the relevant check passing” is more useful than “improve invoice handling.” Record whether the model actually executed the check and whether the change stayed within scope. A confident completion message is not evidence that either happened.

Run the same cases at two sensible effort levels before trying the extremes. Keep input documents, tool permissions, and acceptance rules stable. Otherwise a better answer may reflect a better prompt or broader access rather than a better model setting. Our model-evaluation guide describes how to retain those distinctions in the results.

Migration requires more than a new model ID

The migration guide replaces disabled thinking with between_tools, accepted through high effort. Forced tool selection also fails; use supported tool selection and validate the result. On the Claude API and Google Cloud, computer use needs the newer toolset. Older advisor-model pairings may also fail. Test actual stored requests, not just a fresh text prompt.

These changes touch different owners in a production integration. The request builder controls thinking and tools; the conversation store controls replay; the interface decides which response blocks become visible. An apparently successful smoke test of a single answer says little about the second turn of an existing session.

Build a migration check around one real tool-assisted conversation. Save a sanitized request and expected observable behavior: which tool is eligible, what result is returned, what the user sees, and what happens on a refusal. Replay the sequence with the new model in a test environment. Include a run that resumes saved history, since failures there may not appear until a user returns later.

Conversation history and progress need their own checks

The preserved-thinking documentation describes bindings between reasoning blocks and their originating model, account, and conversation. Sonnet 5.5-to-Opus 5.5 reasoning transfer is supported on the Claude API and Google Cloud; the reverse is not. Moving between unlinked accounts can silently drop Sonnet 5.5 reasoning blocks. A successful request therefore does not prove unchanged reasoning context.

This matters to a router that escalates difficult work and later returns to its cheaper model. Keep a readable task record of decisions, evidence, and unfinished work. Do not assume that opaque reasoning blocks can substitute for that record across every route. Test the return journey as well as escalation.

There is also a visible interface change. The what's-new guide explains that longer progress notes between tool calls arrive in thinking blocks, whose default display omits their text. It also documents refusals as HTTP 200 with stop_reason: "refusal". Opt-in server-side fallback can retry certain categories on Sonnet 5. Check progress rendering and the model that actually answered, not just HTTP success.

Persian quality remains an open evaluation question

We have not tested Sonnet 5.5 on Persian work. General benchmark gains and vendor praise for clearer writing do not answer whether it handles your terminology, figures, and editorial voice.

A useful Persian trial can combine three tasks: rewriting a customer letter without changing its commitments, extracting amounts and dates from a mixed Persian-English document, and reviewing an RTL form. Judge fluency separately from factual accuracy. A smooth sentence can still reverse a qualification; a correctly extracted number can still be assigned to the wrong unit.

Include a rial-versus-toman ambiguity, a Solar Hijri date, and an English product identifier inside a Persian sentence. Ask reviewers to flag meaning changes, missing information, and awkward phrasing before they see the model name. For the interface task, inspect the rendered result at a narrow mobile width. Correct text alone does not establish that mixed-direction content displays correctly.

These are proposed tests, not claimed Sonnet capabilities. Their value is that failures lead to a concrete decision: revise the instructions, add a deterministic check, keep human review, or route that class of work elsewhere.

Where we would start

Our recommendation is a limited trial on repeated tasks with clear answers and cheap recovery. Keep difficult architectural decisions, ambiguous requirements, and costly mistakes in a separately reviewed group. Compare Sonnet 5.5 with the system already doing the job; adding Opus as a third candidate is useful when the question is whether escalation earns its extra cost.

Report acceptance rate, critical misses, review minutes, total task cost, and completion time together. Keep results separated by task type so that many easy successes cannot hide a small but important failure group. Run a small share of eligible work first and preserve the previous route until resumed conversations, tool handling, and actual outputs have been checked.

Sonnet 5.5 makes the everyday tier more interesting. The strongest case for adopting it is a demonstrated reduction in the effort needed to obtain an acceptable result. That is something a team can measure; the model name alone cannot establish it.

Source notes — pricing updated October 7, 2026

The October 7 revision updates cache pricing and the cost example; other evidence was reviewed October 2. This article separates published evidence from ZharfAI's proposed tests and cost arithmetic. We did not run model benchmarks. The cover is Anthropic's official launch artwork, converted to WebP without changing its composition.

• Anthropic's Sonnet 5.5 announcement, September 28: release and reported performance.
• Sonnet 5.5 overview: specifications, availability, and rates.
• Opus 5.5 overview: comparison prices.
• CodeRabbit's Sonnet 5.5 review, September 28: task-specific evidence and limitations.
• Prompting Sonnet 5.5: effort and completion behavior.
• Migration guide: compatibility changes.
• Preserved thinking: model, account, and conversation boundaries.
• What's new: progress blocks, refusals, and fallback.
• Haiku 5.5 announcement, October 7: Sonnet cache-read price reduction.