Claude Sonnet 5.5: same price, fewer tokens, and 5 breaking changes

What Claude Sonnet 5.5 actually is

Claude Sonnet 5.5 is the mid-tier model from Anthropic, and it is the second release in the Claude 5.5 family, coming six days after Opus 5.5. The way Anthropic pitches it is as "a faster, lower-cost complement" to Opus, with Opus kept for complex work that needs careful judgment and Sonnet taking the well-scoped everyday tasks. There is also a Haiku 5.5 promised "in the coming weeks".

Here are the specs, as listed on the model overview page:

• The model ID is claude-sonnet-5-5 on the Claude API, Google Cloud, Microsoft Foundry and Claude Platform on AWS, and anthropic.claude-sonnet-5-5 on Amazon Bedrock.
• Context is 1M tokens in and 128K out, or 300K out on the Batch API with a beta header.
• Reliable knowledge cutoff is June 2026, the same as Opus 5.5 and Fable 5.1.
• Thinking is adaptive, and the default effort is high on the API but Medium in the Claude apps and Claude Code.
• Retirement is "not sooner than September 28, 2027", which gives you at least one year before you need to move again.

The tokenizer is the same as Claude Sonnet 5, per the what's new page, meaning the same text gives you the same token counts. This detail matters more than it sounds like it does. It means every saving Anthropic is claiming comes from the model writing less, and not from some friendlier way of counting.

The real story: same price tag, smaller bill

On the sticker price, nothing moved. Sonnet 5.5 costs exactly what Sonnet 5 costs: $2 input, $10 output, $0.20 cache reads. The part that changed is how many tokens it spends to get a job finished.

The early-access numbers in the launch post are specific in a way you don't usually see:

• Balyasny Asset Management ran 2,441 finance tasks and saw Sonnet 5.5 use about 121k tokens per answer where Sonnet 5 used 497k, while scoring higher.
• Slack saw better results on "almost all" of its offline Slackbot evals "with about 14% fewer output tokens", and that was without changing any prompts.
• Base44 had it finishing app builds in 3.6 iterations on average, where Opus 5 needed 7.7.
• Lovable measured "a third fewer tool calls and roughly half the shell runs to finish a task".

Anthropic's own side-by-side makes the same point, just visually. When both were asked to build a 400-starling murmuration in one HTML file, Sonnet 5 was still writing code at 4,520 tokens:

Sonnet 5.5 was already done at 4,158 tokens, and by that point its flock had been flying for 12.5 seconds:

The spread between the customers is where the honest reading sits. Balyasny's 4x token drop and Slack's 14% cut are both real, which tells you the saving depends a lot on how bloated your Sonnet 5 runs were in the first place. Anthropic's headline says "up to 30% less per task", and the "up to" is doing a lot of the work in that sentence. Sonnet 5 had a known habit of running long: in Artificial Analysis testing it took 183 turns per task at max effort, the worst on the chart. If your workload hit that, you can expect the big number, and if your prompts already kept answers short then expect something closer to Slack's.

How close it gets to Opus 5.5

For anyone paying Opus prices, this is the part where the release gets interesting. On Anthropic's launch benchmark table, Sonnet 5.5 closes most of the gap to a model that costs twice as much per token.

A few things jump out. First, the Terminal-Bench jump from 10.3% to 70.6% is enormous, and on that one Sonnet 5.5 actually beats Opus 5.5. GDPval-AA, a test of real work across 44 occupations, has it two Elo points behind Opus 5.5 and about 400 ahead of Sonnet 5. Then against GPT-6 Sol, which is the rival Anthropic chose to chart, Sonnet 5.5 at its best effort setting leads on every row where OpenAI's model has a score, and at High effort it matches GPT-6 Sol's best FrontierCode result for about a fifth of the cost per task.

I appreciate that Anthropic is candid about the limit here. The launch post says that "in our own testing, and in that of external testers, Opus 5.5 remains clearly stronger at complex, open-ended work requiring sustained judgment". Benchmarks tend to reward the tasks that have a clear right answer. Open-ended calls, like deciding whether an angry enterprise customer needs a refund or an apology, or maybe an escalation, are exactly where the extra Opus spend still earns its keep. The Opus 5.5 vs GPT-6 Sol comparison goes into that top tier in more depth.

One more footnote that is worth reading: FrontierCode scores drop at Max effort (46.2%) versus Xhigh (52.1%). Anthropic's explanation is that at Max, Sonnet 5.5 more often split the code review across subagents, and this caused timeouts or edits going beyond the task's scope. More thinking is not always better, which is a pattern the Opus 5 effort guide also saw.

What Sonnet 5.5 means for support teams

If I had to put one quote from the launch post in front of any support lead, it would be this one. Zendesk's Director of AI tested the model on real tickets:

"We fed Claude Sonnet 5.5 hundreds of real support use cases across replies and escalation requests. It made fewer wrong decisions and resolved tickets faster than the Claude models we use in production today. Tickets were processed 20% faster, getting our customers the help they need without the wait."

Abhinay Kathuria, Director of AI at Zendesk, in Anthropic's announcement

"Fewer wrong decisions" is the part that matters here. Speed is nice, but on a support queue a fast wrong answer costs more than a slow right one: it creates a second ticket and an angry follow-up, and sometimes a refund on top. Zendesk AI already runs Claude models in production, so when it claims better escalation decisions against its own current setup, that carries real weight. Atlassian made a related point about scale, saying teams will run their Rovo agents "up to 30% faster than they could with Sonnet 5", and Slack AI is already testing it for Slackbot.

Looking at it from the queue side, this is how I would map the Claude lineup to support jobs:

Sonnet 5.5 is the natural default for the bulk of a queue, meaning order questions, how-to answers, policy lookups and first drafts for an agent to approve. Haiku stays the cheap choice for ticket triage and tagging. Opus 5.5 is where I would send the tickets that need judgment, which are the ones your senior agents would take anyway. Where the 30%+ speed gain matters most is live chat, since there a customer is sitting and watching the typing indicator.

The honest caveat: a better model does not fix a missing answer. I have watched a support bot confidently tell a customer that a product was supported because the help center said "we support all models", and I have seen another one invent answers when retrieval came back empty. Neither of those was a model-quality problem. Both were grounding problems, and a smarter model can actually make a confident wrong answer sound even more convincing. That is why eesel simulates every rollout against historical tickets before an AI replies to anyone, whichever model is underneath.

Before you migrate: five things that now return errors

Most launch coverage will skip this section, and it is the one that will actually eat your afternoon. Changing claude-sonnet-5 to claude-sonnet-5-5 is one line. Behind it, the what's new page lists five breaking changes, and there is one more rule that belongs on the same checklist.

1. thinking: disabled returns a 400. Send thinking: {"type": "between_tools"} instead, which turns off up-front thinking. It only works at high effort or below; at xhigh or max it errors too.
2. Forced tool use is gone. tool_choice set to any or a named tool returns an error. The fix is auto plus strict tool use.
3. Thinking blocks are tied to the model and the account. If you edit earlier messages, the system prompt or the tools and then replay a Sonnet 5.5 thinking block, newer accounts get a 400. So keep conversations append-only.
4. The old computer_20251124 tool is rejected on the Claude API and Google Cloud. Bedrock still accepts it.
5. Some advisor pairings are rejected. Opus 4.8, Opus 4.7 and Sonnet 5 can no longer advise a Sonnet 5.5 executor.

About that extra rule, the docs note that setting temperature, top_p or top_k to a non-default value returns a 400 on this model.

The support trap is number two. A lot of helpdesk bots force a tool call to guarantee structured output: "always call classify_ticket", "always call draft_reply". On Sonnet 5.5, that request just fails outright. If you built your own integration on the Anthropic API, grep for tool_choice first, before you touch the model ID.

There is also a quieter change, one that does not error but will still confuse users. Text the model writes between tool calls now comes back inside thinking blocks, and at the default display: "omitted" that text is empty. If your chat widget streams "Checking your order status..." while the agent works, it will go silent until you set a display value. Anthropic has also recalibrated the effort levels, so re-run your effort tests rather than carrying the Sonnet 5 settings over. The AI agent handoff guide is worth a read if a model swap changes when your bot escalates.

Last thing is safety. Sonnet 5.5 is the first Sonnet to launch with cyber safeguards, because its cyber capabilities are comparable to Opus 5's. Higher-risk cybersecurity requests "visibly fall back to Sonnet 5", and a declined request returns HTTP 200 with stop_reason: "refusal". For a support bot this will rarely fire. But if you serve security or IT customers, it is worth handling the refusal case rather than showing a blank reply.

Claude Sonnet 5.5 pricing and access

This is the full rate card from Anthropic's pricing docs, per million tokens:

A couple of notes on that table. Thinking is billed as output tokens, so a high-effort run pays $10 per million for its reasoning too. And the minimum cacheable prompt is now 512 tokens, per the model overview, and that makes it easier to cache a stable support system prompt.

To put these rates in support terms, here is some illustrative math that uses only the published prices. Say a ticket reply sends 6,000 input tokens (the ticket plus retrieved help articles) and gets back 800 output tokens. That is $0.012 of input and $0.008 of output, or about 2 cents per ticket. If 5,000 of those input tokens are a cached system prompt, the input side drops to about $0.003 and the whole reply lands near 1.1 cents. At 10,000 tickets a month, that is roughly $200 uncached versus $110 cached, before thinking tokens. Your own numbers will vary depending on effort and retrieval size, but it does show why the model line on the invoice is rarely the big cost in an AI support agent.

Here is where you can use it:

• The Claude API, as claude-sonnet-5-5, with prompt caching and the Batch API. Zero data retention is available.
• Claude apps. Anthropic says "anyone can chat with Claude using Sonnet 5.5 on Claude.ai" on web, iOS and Android. The paid tiers are covered in the Claude Pro pricing guide.
• Claude Code, where the default effort is Medium. The Claude Code pricing guide covers the subscription-versus-API maths, and pinning a model takes one setting.
• The clouds: Amazon Bedrock, Google Cloud, Microsoft Foundry and Claude Platform on AWS, all on day one.

If what you are weighing is providers rather than tiers, the three-way API comparison and the GPT-6 Sol pricing breakdown are the fastest sanity checks.

What developers are saying

The launch thread on Hacker News passed 550 comments in a day, and the reaction splits pretty neatly. People like the speed and they respect the benchmarks, while the pushback is mostly about where it fits next to Opus 5.5.

"Playing around with it for a few minutes, Sonnet 5.5 feels very fast, much quicker than Opus 5.5. Can't tell yet if it's a lot worse but the speed is definitely welcome."

croemer, Hacker News

The sharpest criticism has to do with the high effort settings. Simon Willison measured his usual SVG test at every effort level and found low at 1.6 cents, medium at 1.8 cents and high at 2.3 cents, but max burned through its whole thinking budget:

"Sonnet 5.5 has the same problem as Opus 5.5: on "max" thinking effort it burned through 128,000 thinking tokens (taking 15 minutes to do that) and ran out before it had produced the final SVG."

simonw, Hacker News

A Reddit user pulled the same pattern from Artificial Analysis, reporting that "sonnet 5.5 max has a cost per task of $7.60 while opus 5.5 max has $5.98", with Sonnet using 193k tokens per task to Opus's 119k (u/ex-procrastinator, Reddit). Another commenter summed up what the charts are implying:

"Per the charts, there is largely no point to using Sonnet 5.5 at high+ as opus low generally will give similar performance at similar or lower cost."

usaar333, Hacker News

Anthropic says much the same in its own launch post: Sonnet 5.5 "complements Opus 5.5 best when running at lower effort settings", and "at higher settings, it can perform comparably at a similar cost". So the practical takeaway, and the thing I would tell any team that is switching over, is this. Run Sonnet 5.5 at Low or Medium effort, where the savings actually are. The API defaults to high, so the cheap version of this model is one you have to ask for. Support replies are exactly the kind of well-scoped work Medium handles well.

There is one regression worth knowing about. A developer who runs an adversarial benchmark found Sonnet 5.5 scored lower than Sonnet 5 "mainly because it is more reluctant to keep going to get an answer, instead it returns to ask the user questions" (dom96, Hacker News). For a coding agent that is annoying, but for a support bot, stopping to check instead of guessing is often exactly what you want.

A faster model still needs a teammate around it

Every model launch prompts the same conversation with technical customers: this is cheap and good enough now, so why not build our own support bot on the raw API? It is a fair question, and Sonnet 5.5 makes the model half of it easier than it has ever been.

What the rate card leaves out is everything around the model. Sonnet 5.5 is a superb engine. It is not a support agent until someone builds the retrieval over your help center and past tickets, plus the escalation rules and refusal handling, the effort tuning, and now also the migration work for five breaking changes. The model is the infrastructure, and the employee is what you build on top of it.

eesel sells that part already built. Its AI helpdesk teammate joins your existing queue in Zendesk, Freshdesk, Gorgias and more. It learns from your past tickets and help center, then drafts or sends replies with a frontier model underneath. When Anthropic ships a model like this, the switch and the breaking changes are eesel's problem, not yours.

If you do want programmatic control, eesel has a CLI that operates the same teammate and workspace the dashboard does. You can drive it from a terminal or script it, and you can also let a coding agent like Claude Code run it, so you get the agentic workflow people build on raw models without owning the grounding and retry stack. My write-ups on the AI agent CLI and MCP servers show how that fits together.

Pricing works on fixed monthly credits: a ticket or chat handled is one credit, the free plan includes 100 credits with no card, and paid plans start at $299 for 500. You can simulate the teammate against your own historical tickets before it replies to a single customer. Try eesel on your Zendesk queue free, and see the Sonnet-class speed-up on tickets you already know the answers to.

Is Claude Sonnet 5.5 worth it?

If you run Sonnet 5 today, yes, and it is one of the easier upgrades Anthropic has shipped. You pay the same rate for a model that scores far higher and finishes in fewer tokens, and it runs faster too. The only real cost is the migration work, and that is a known list of five items, not a mystery.

If you run Opus 5.5 for everyday work, test Sonnet 5.5 on your own traffic at Medium effort before renewing that habit. For well-scoped tasks, the benchmark gap is a couple of points and the per-token price gap is 2x. Once you go past high effort that advantage disappears, so if a task needs max reasoning, send it to Opus instead. Keep Opus for the open-ended judgment calls where Anthropic itself says it is still clearly stronger. One Hacker News commenter described a pattern, "80% Sonnet 5.5, Opus 5.5 to finish the last 20%", and it is a sensible way to split a queue too. For the wider field, my Sonnet 5 review and Opus 5.5 alternatives roundup are the next reads.