Anthropic released Claude Sonnet 5.5 on 28 September at Sonnet 5's price, $2 in and $10 out per million tokens. On FrontierCode 1.1 it scored 52.1% at xhigh effort and 46.2% at max, the highest setting.
Anthropic's own footnote explains the drop. At max, the model more often ran Claude Code's code-review skill, which fans the review out across many subagents, and twice that ended in a timeout or in edits outside the task.
Effort is not a thinking-time dial with a guaranteed upward slope. It changes which tools and skills the model reaches for. Pin it per workload, test at least two levels on your own tasks, and put a ceiling on fan-out before you turn it up.
The footnote that matters more than the headline
Most of the launch coverage led with Terminal-Bench 4.0. Sonnet 5.5 scored 70.6% there, against 10.3% for Sonnet 5 and 66.4% for Opus 5.5 at xhigh. A mid-tier model beating the flagship on an agentic coding benchmark at half the list price makes a good headline.
The more useful line sits under the FrontierCode table. Here are the numbers as Anthropic published them:
- Opus 5.5: 54.4%
- Sonnet 5.5 at xhigh: 52.1%
- GPT-6 Sol: 49.3%
- Sonnet 5.5 at max: 46.2%
- Sonnet 5: 42.4%
Going from xhigh to max cost Sonnet 5.5 about six points and dropped it below GPT-6 Sol. The footnote says why, in plain terms: "At Max effort, Sonnet 5.5 more often ran Claude Code's code-review skill, which splits the review across many subagents, and in two cases this led to a timeout or to extra edits beyond the task's scope."
The model didn't get worse at reasoning with more budget. It got more ambitious about process. Given room, it decided the job deserved a multi-agent review, and the review itself became the failure.
Why this is a behavior change, not a tuning detail
Most teams treat effort the way they treated max_tokens: set it high when quality matters, low when cost matters, and assume the curve only goes up. That mental model worked for older reasoning models, where more budget mostly meant a longer chain of thought before the same kind of answer.
An agent with skills and subagents doesn't work that way. When budget grows, the options it can afford grow with it. It can open more files, run more checks, and call in a skill that spawns ten workers. Each of those choices is reasonable on its own. Together they add wall-clock time, and every subagent is one more chance to touch a file nobody asked it to touch.
FrontierCode penalizes both of those, which is why the drop shows up there. Your CI pipeline penalizes them too, just less visibly. A timeout reads as a flaky job. An out-of-scope edit reads as a noisy diff that a reviewer approves because the tests passed.
The same model ID behaves differently depending on where you call it
There's a second setting you may not realize you're running. Anthropic says Sonnet 5.5 defaults to medium effort in Claude Code and the Claude apps, and to high on the Claude Platform API.
So a prompt that behaves well in your terminal during development runs one level higher once it's in a backend service calling claude-sonnet-5-5 without an explicit effort value. Nothing in the model string tells you that. If your team prototypes in Claude Code and ships through the API, the prototype and the product are not running the same configuration.
ComputingForGeeks ran a small infrastructure test that shows the spread. Three Kubernetes deploy tasks, all passing at every level:
- Medium: 639 output tokens on average, $0.067 per task
- High: 1,562 tokens, $0.123
- Max: 23,323 tokens, $1.359
Same success rate, twenty times the cost from medium to max. Three runs is a small sample, but the shape matches what Anthropic's footnote describes: the top setting buys activity, and activity is not the same as a better result.
The 30% cheaper claim depends on which setting you run
Anthropic's efficiency pitch is real, with a condition attached. The company says Sonnet 5.5 at low or medium effort beats Sonnet 5's best score for under a tenth of the cost per task. Customers back up the direction: Lovable reports a third fewer tool calls, Slack 14% fewer output tokens, Base44 3.6 iterations per build against 7.7 on Opus 5.
Run it at max and the picture flips. Artificial Analysis measured Sonnet 5.5 at $7.60 per task on its Intelligence Index at max effort, against $5.09 for Sonnet 5. That's about 49% more, not 30% less.
If you migrated from Sonnet 5 by swapping the model string and keeping effort: "max" because that's what you ran before, you likely got a slower, more expensive model that scores lower on some coding work. The upgrade only pays off if you reset the setting along with the model.
What I would change this week
Set effort explicitly in every API call. Don't inherit the platform default. Put it in config next to the model ID so a reviewer can see both, and so the value in dev matches the value in production.
Sweep two or three levels on your own eval before picking one. Medium and xhigh are the obvious pair for Sonnet 5.5. Add max only if you have a reason. Score pass rate, cost per task, wall-clock time, and diff size. That last one is the metric that catches the failure Anthropic described.
Cap fan-out where the harness allows it. If your agent can load skills that spawn subagents, set a limit on concurrent subagents and a hard time budget per task. The FrontierCode failures were timeouts and scope creep, both of which a budget turns into a clean stop instead of a half-finished review.
Check diffs for files outside the task. A simple rule in CI that flags changes to paths the ticket didn't mention would have caught both of Anthropic's out-of-scope cases. It costs nothing and it catches the same thing when a human does it.
Keep Opus for the work that needs it. Opus 5.5 still leads on FrontierCode and CursorBench, and Anthropic positions it for work that needs careful judgment. Sonnet 5.5 is the better default for scoped tasks, at medium, with a budget.
More room to think used to be the fix
For two years the advice was simple: if an agent fails, give it more room to think. Sonnet 5.5 is the clearest public case so far where more room produced a worse result, and the vendor documented the reason in its own launch post.
Effort now picks a working style as much as a depth of reasoning. Treat it like any other production parameter. Choose it on purpose, measure it on your own tasks, and set limits on what the model is allowed to do with the extra budget.