We tested 30 AI models to measure the 
Sonnet 5.5 or Opus 5.5 for coding: what the extra money buys
For most of the last year, choosing between Anthropic’s two main models for coding work was easy to describe. Opus was the careful one you paid for. Sonnet was the fast one you used when the task didn’t need Opus. Sonnet 5.5 blurs that line enough that we wanted real numbers before telling anyone on our team which to use, so we ran both through the same benchmark of real coding work, on the same day.
At its default, Sonnet 5.5 lands about four points behind Opus 5.5 for well under a third of the cost. Turned up to high effort, it closes half that gap and still costs about half as much.
The numbers
Across our full set of tasks:
| Score (out of 50) | Cost per session | Time per session | |
|---|---|---|---|
| Sonnet 5.5, medium (default) | 38.5 | $0.78 | 3.8 min |
| Sonnet 5.5, high | 40.7 | $1.50 | 6.2 min |
| Opus 5.5, medium (default) | 42.7 | $2.71 | 8.5 min |
Task by task:
| Task | Sonnet 5.5 medium | Sonnet 5.5 high | Opus 5.5 medium |
|---|---|---|---|
| Long session: rate limiting in a Slack bot | 36.5 | 41.2 | 44.5 |
| Long session: trace id across two services | 40.1 | 43.7 | 42.1 |
| Vague bug report | 38.0 | 40.0 | 40.8 |
| Test-first fix | 42.0 | 42.4 | 45.0 |
| Design review with pushback | 35.9 | 36.6 | 42.9 |
| Quick fix | 38.4 | 40.4 | 41.0 |
On one task, the cross-service trace id, Sonnet 5.5 at high effort scored higher than Opus. On most of the rest the two are within a few points. Two places stand out where Opus pulls well ahead, and they have something in common.
Where Opus earns its price
The first is the rate-limiting session. Its second turn asks what happens to a user’s request when Redis goes down, and the honest answer depends on a detail of the Redis client: while it’s trying to reconnect, it still reports itself as open, and requests quietly queue up with no timeout. Opus 5.5 got this right in all four runs, scoring 46 to 49 on that turn. Sonnet 5.5 at high effort got it wrong in three of four, confidently describing the simpler “connection is closed” behaviour, and scored 33 to 35 on those. The same mistake then shapes the fix it writes two turns later.
The second is the design review. The agent reviews a pull request, the author pushes back, and then the agent is asked what it would build instead. Sonnet 5.5 handles the pushback well: it went back to the code and showed the author was wrong in every run. Where it falls behind is the review itself and the alternative. Its first-pass reviews scored about 35 against Opus’s 42, and its proposed alternative designs about 32 to 37 against Opus’s 40.5. The problems it flags are real, but Opus finds more of them and proposes a better fix.
What these have in common is judgment about things that aren’t written down: how a library behaves in a state nobody tested, or what else a design will break. That’s the work Opus is better at. On straightforward implementation, like threading an id through two services and a queue, Sonnet 5.5 is as good.
Where the savings come from
Sonnet 5.5 costs half as much as Opus 5.5 per token: $2 against $4 per million input tokens and $10 against $20 per million output tokens, going by what Claude Code billed. Both pay the same 20 cents per million to read from the prompt cache, which is most of what a long agent session reads.
It also does less work. On the long sessions, Sonnet 5.5 at medium made about 41 model requests per session, at high about 70, and Opus about 87. Each request takes 10 to 12 seconds for all three, so the number of requests is most of the speed story.
How we tested
The benchmark is a battery of agentic coding tasks taken from real work on our own services. Some are short: a vague “it isn’t working” bug report, a test-first fix, a design review where the author pushes back, a quick fix. Others are long multi-turn sessions, where one Claude Code conversation goes from finding the relevant code, to analysing how something fails, to planning and implementing a fix, and then auditing that fix. Every setup gets the same fixed prompts, and we ran each task several times per setup. This comparison alone used several hundred million tokens.
Every turn is scored out of 50 against an answer key: the facts a correct answer needs, false claims earlier answers have made, and what a good plan or implementation must do. The keys were checked against the code, and the grader is Opus 5.5 reading the answer, the code and the key. That means Opus is grading its own homework here, which is worth keeping in mind, although the keys tie it to facts rather than taste and it marked Opus down plenty.
We ran Opus 5.5 at Claude Code’s default (medium effort) and Sonnet 5.5 twice: at its default (also medium) and at high effort.
What we’d tell a team
If most of your work looks like building and changing features, Sonnet 5.5 is the default we’d start with. At medium it’s fast and cheap enough that you stop thinking about it, and at high it’s close to Opus on implementation work for about half the cost.
Keep Opus for the sessions where being slightly wrong is expensive: reasoning about failure modes, reviewing someone else’s design, anything where the question is “what could go wrong here.” Those are the tasks where it still clearly wins on our benchmark, by seven to twelve points on the turns that matter, well beyond the point or two that separates runs of the same model.
