What Sonnet 5.5 costs by the time the fix is accepted

A developer gets a patch, spots a missed condition, and sends it back. The next version needs one more correction. By the time the fix is accepted, three model responses have contributed to it, though only the last one looks ready to ship. That is the bill worth comparing when a model promises cheaper work.

In its September 28 Sonnet 5.5 announcement, Anthropic reports output generation more than 30% faster than Sonnet 5 and task costs up to 30% lower in its tests. AIOpsSRE has not measured those savings. The basic idea is plausible: even at the same price per token, the small units used to count model input and output, a job can cost less if it needs fewer of them. But the saving has to survive the corrections and review.

Pricing rechecked November 2, 2026: The standard USD rates in Anthropic’s pricing documentation remain $2 per million input tokens, $10 per million output tokens and $0.10 per million cache-read tokens. Cache reads reuse previously stored input rather than processing it all afresh. The October 7 announcement dates the reduction from $0.20 to $0.10. The Sonnet announcement now shows the lower rate too, and the migration guide describes it as half the Sonnet 5 rate.

Anthropic lists availability through its platform, AWS, Google Cloud and Microsoft Azure, with claude-sonnet-5-5 as the Claude Platform identifier. Its proposed division of labor puts Sonnet on well-scoped everyday jobs such as bug fixes, and Opus on more open-ended complexity. Before comparing either model’s repair bill, though, the application needs to send requests the newer model accepts.

First, make sure the repair can start

Suppose the client still sends thinking.type: disabled. The request fails before Sonnet 5.5 can prepare a patch. The migration guide instead specifies between_tools at low, medium or high effort when up-front thinking should be off. Intermediate updates between tool calls may still arrive as thinking blocks, separate from the final answer. Read each block’s type rather than assuming the first one contains the explanation of the patch.

Then there is the lookup the repair depends on. Older code may force a call to fetch the current configuration using any or tool; Sonnet 5.5 rejects both choices. Changing that setting to auto lets the request run, but also lets the model answer without making the call. Before accepting the patch, the client must check that the required lookup happened. A smaller bill is not much of a saving if the repair skipped the information it needed.

Keep the first two attempts on the bill

For a hypothetical comparison, hand each model the same failing configuration and put its patch through the normal checks and review. Our developer’s first patch misses a condition and needs two corrections. None of those earlier attempts disappears when the third version finally passes.

Give the three attempts invented charges of $0.02, $0.03 and $0.01. The accepted fix has used $0.06 in model charges, not just the last response’s $0.01. Those numbers are arithmetic for the example, not Sonnet rates or measured results. Record reviewer time alongside them; converting that time to money requires its own labor-cost assumption.

Keep rejected and unfinished attempts in the comparison too. Initially hold prompts, permissions and acceptance tests steady, then put accepted-job counts beside total spend and review time. A run that costs less because it completed less work is a different outcome from one that repaired the same problems more efficiently. The task-level cost guide follows the accounting through retries.

Now return to the developer with the accepted patch. The client handled the thinking blocks, checked the necessary tool call, and kept every attempt attached to the job. If those usable fixes still require fewer paid tokens, the advertised efficiency has become a saving on this team’s work. The final response no longer has to pretend it did the whole job alone.