Claude Sonnet 5.5's Coding Gains Put Review Costs in Focus

Anthropic says Claude Sonnet 5.5 scored 70.6% on Terminal-Bench 4.0. For a maintainer facing a queue of proposed fixes, the number raises a practical question: how many of those fixes could reach a mergeable state without adding another round of review?

The company has released Claude Sonnet 5.5 at a listed price of $2 per million input tokens and $10 per million output tokens, the same rates as Sonnet 5. Anthropic also says the new model generates output more than 30% faster than Sonnet 5 and comes within two points of Opus 5.5 on GDPval-AA. Those are company-reported comparisons, as summarized by MarkTechPost; the supplied account does not establish independent verification or provide enough benchmark methodology to translate the scores into a prediction for a given repository.

A maintainer's unit of work is rarely a generated file. Consider a hypothetical dependency update that breaks a project's tests. An AI coding tool might locate the failing call, edit the code and add a test. The maintainer still has to check whether the change preserves supported behavior, whether the test exercises the failure, and whether the patch creates problems for downstream users. A faster draft helps most when it also survives those checks. If it does not, the tool has accelerated the arrival of work someone else must finish.

The Token Bill and the Review Queue

Anthropic says Sonnet 5.5 could reduce cost per task by up to 30% by using fewer tokens. That figure describes a potential outcome, not an observed saving for every workload. At unchanged input and output rates, a shorter exchange costs less; repeated prompts, extra test runs or a switch to another model can change the total.

At Anthropic's listed rates, a hypothetical task using 100,000 input tokens and 20,000 output tokens would cost $0.40 in model charges: $0.20 for input and $0.20 for output. Two identical attempts would cost $0.80. Neither example describes a Sonnet 5.5 result, and neither includes the time spent reading a patch, running checks or explaining a rejection. It shows why a price per million tokens cannot settle a cost-per-accepted-change question.

For an open-source project, some of that omitted cost may fall on volunteers. A company can pay for an agent to produce candidate patches across many repositories, while each receiving project decides whether to review them. The arrangement can be valuable when the patches solve wanted problems and arrive with useful tests and context. It can also move the expensive part of the workflow to people who did not choose the tool or its output volume. The model's invoice goes to the user; the review queue goes to the maintainers.

That is why a stronger coding result deserves attention without carrying the whole argument. A score on Terminal-Bench 4.0 is evidence for performance on that evaluation as reported by Anthropic. It does not tell a project how often Sonnet 5.5 will understand its compatibility policy, notice an undocumented edge case or respond well when a reviewer asks for a narrower patch. Those questions call for testing against the project's own work, rather than another round of debate over a single leaderboard number.

What a Faster Draft Changes

Anthropic's claimed output-speed increase could improve a developer's feedback loop. Waiting less for an initial answer makes it easier to try a different approach, inspect a proposed test or abandon a bad patch early. That benefit has a different shape from a lower token bill: output speed concerns generation, while elapsed time to a merged fix also includes tool execution, CI, review and revision.

The comparison with Opus 5.5 needs similar care. Anthropic's reported gap of under two points on GDPval-AA may make Sonnet 5.5 attractive to teams considering when a lower-priced model can handle work they might otherwise send to a more expensive one. It does not establish that the models behave alike on every task, or that the GDPval-AA gap predicts coding-review effort. The Opus pricing question already turns on workload details such as token use, cache use and safeguards. Sonnet's unchanged rates leave those details in place.

A useful trial would start with a defined set of issues a team already knows how to evaluate. Give Sonnet 5.5 and the current workflow the same repository context and acceptance criteria. Record tokens and model charges, but also whether the patch passes tests, how many revisions it needs and how much reviewer time it consumes before acceptance or rejection. Keep the failed attempts in the count. An average drawn only from merged patches would hide the work spent rejecting plausible-looking ones.

For maintainers, the test set should include work that strains project judgment as well as code generation: a bug fix constrained by backward compatibility, a test that initially passes for the wrong reason, or a change affecting a documented public interface. These are proposed evaluation cases, not reported Sonnet 5.5 results. They reflect the point at which repository knowledge and project policy enter a coding task.

Who Sets the Rules for AI-Generated Contributions?

A model upgrade can change contribution volume before it changes project capacity. If creating a candidate pull request becomes faster or cheaper, maintainers may need a clearer answer to a governance question: what must a contributor provide so the project can review that request responsibly?

One project might ask contributors to disclose substantial AI assistance. Another might care only that the author has run the tests, can explain the change and will respond to review. Either approach still leaves the project in control of its merge standard. Disclosure alone does not make a patch safe; a clean test run alone does not settle whether the change fits the project's support commitments. The appropriate rule depends on what reviewers need to make a decision and how much time the project can spend obtaining it.

Developers buying coding assistance have a different decision to make. If their team owns both the tool bill and the review queue, a quicker, cheaper first pass may be a clear gain even when some patches need correction. If they send changes upstream, their internal saving can depend on an external maintainer's unpaid attention. A responsible cost comparison would account for that handoff rather than treating merge as a free final step.

Sonnet 5.5's reported figures give teams a reason to run that comparison. They do not supply its answer. The result an open-source maintainer can use is a patch that meets the project's standards with less total work, including the work of deciding whether to merge it.