Claude Sonnet 5.5: Same $2/$10 Price, 30% Faster, Fewer Tokens

What changed on 28 September

• A new mid-tier model. Anthropic released Claude Sonnet 5.5 on 28 September 2026, six days after Opus 5.5 cut its token prices by 20%. The API identifier is claude-sonnet-5-5.
• Same list price. $2 per million input tokens, $10 per million output tokens and $0.20 per million cache reads — identical to Sonnet 5. Batch processing still carries a 50% discount.
• Faster output. Anthropic says Sonnet 5.5 generates output more than 30% faster than Sonnet 5.
• Cheaper per task, by claim. Anthropic says it costs up to 30% less for most work, because it uses fewer tokens and fewer tool calls to reach the same result. That is an effective-cost claim, not a price change.
• One headline benchmark. 70.6% on Terminal-Bench 4.0, against 10.3% for Sonnet 5 and 66.4% for Opus 5.5 — with an effort-setting caveat we come to below.
• Wide availability from day one. The Claude Platform, Amazon Web Services, Google Cloud and Microsoft Azure, plus the Claude apps. GitHub began a gradual rollout into Copilot on the same day.
• Specs. A 1M-token context window, up to 128K output tokens and a June 2026 knowledge cutoff, per launch coverage. Anthropic says Haiku 5.5 will follow in the coming weeks.

"Same price" — and which price that is

"Unchanged from Sonnet 5" needs one line of history to read correctly. Sonnet 5 launched in June at an introductory $2 per million input tokens and $10 per million output tokens, with a scheduled step up to $3 and $15 on 1 September. We flagged that step-up at the time in our Sonnet 5 launch coverage and told teams to budget for the higher rate.

On 10 August Anthropic made the introductory price permanent, and the September increase never happened. So the $2/$10 that Sonnet 5.5 "keeps" is the rate you have actually been paying all summer. If your finance team followed the cautious advice and forecast $3/$15 from September, there is headroom sitting in that budget line already, before Sonnet 5.5 does anything at all. Correct the forecast first; it is the cheapest saving in this whole story.

Against Opus 5.5, the gap is now a clean factor of two on the main lines: Opus 5.5 lists at $4 input and $20 output. Cache reads, unusually, are the same $0.20 on both. Cache writes are $2.50 on Sonnet 5.5 against $5 on Opus 5.5.

Per million tokens (USD, list)	Sonnet 5 (now)	Sonnet 5.5	Opus 5.5
Input	$2	$2	$4
Output	$10	$10	$20
Cache read	$0.20	$0.20	$0.20
Cache write	—	$2.50	$5

That identical cache-read line matters more than it looks. On a workload dominated by a large, stable, cached prefix — a long system prompt, a fixed tool schema, a repository map — a big share of your input bill is priced the same whichever model you pick, and the real difference between the tiers narrows to output and uncached input. If you have not yet split your bill that way, our guide to prompt caching in production is the place to start.

Where "up to 30% cheaper" actually comes from

You are billed per token. If the rate is fixed, the only way a task gets cheaper is that it consumes fewer tokens: shorter reasoning, fewer correction loops, fewer tool round-trips that each re-send context. That is exactly what Anthropic is claiming, and the customer figures it chose to publish at launch are all about volume, not rate. They are vendor-selected launch claims, not independent tests.

Launch customer	Claimed result (Anthropic launch quotes)	What it measures
Balyasny Asset Management	About 121K tokens per answer versus 497K on Sonnet 5, across 2,441 finance tasks	Token volume
Base44	3.6 iterations per app build versus 7.7 for Opus 5, across 118 builds, with apps scoring level	Iterations to done
Box	2.4x faster, 12% fewer total tokens	Latency and volume
Slack	Roughly 14% fewer output tokens	Output volume
Lovable	One-third fewer tool calls, roughly half as many shell executions	Agent steps
Zendesk	Tickets processed 20% faster	Latency

Read the spread, not the best row. Balyasny's figure is roughly a three-quarters cut in tokens per answer; Slack's is 14% on the output side alone. Take both at face value and they are still more than five times apart, because token efficiency is a property of the pairing between a model and a workload. A tightly-scoped extraction endpoint with a fixed output schema has little slack to remove. A long-running agent that plans, reads files, retries and corrects itself has a great deal. These are also vendor-selected launch quotes, chosen because they look good; treat them as an upper envelope, not a forecast.

GitHub's own note is usefully modest by comparison: in its testing, Sonnet 5.5 matched Sonnet 5 on coding tasks while using significantly fewer steps, tokens and tool calls, and finished noticeably faster. "Matched" is the word to hold onto. The pitch is the same quality for less consumption, not a step change in capability for everyday coding.

Reading the benchmarks without fooling yourself

The number in every headline is 70.6% on Terminal-Bench 4.0. Here is the slice of Anthropic's published table that matters for the Sonnet-or-Opus decision.

Benchmark	Sonnet 5	Sonnet 5.5	Opus 5.5
Terminal-Bench 4.0	10.3%	70.6% (Max effort)	66.4% (Xhigh effort)
CursorBench 4.0	34.1%	55.5%	57.8%
OSWorld 2.1	57.0%	80.1%	81.8%
GDPval-AA v2.1 (Elo-style)	1449	1844	1846
Humanity's Last Exam (with tools)	54.9%	64.5%	67.7%

Three things to notice. First, the Terminal-Bench comparison is not like-for-like: Anthropic's own footnote reports Opus 5.5 at Xhigh effort, while the Sonnet 5.5 figure is at Max. "Sonnet beats Opus at agentic coding" is a fair summary of one row measured at different settings, and nothing more. On CursorBench 4.0, which is closer to day-to-day editor work, Opus 5.5 still leads, and Opus leads on most of the remaining rows in Anthropic's table.

Second, effort is now a first-class cost lever, and the headline number sits at the top of it. Anthropic sets Medium as the default effort in the Claude apps and Claude Code, and High as the default on the Claude Platform. According to Digital Applied's reading of Anthropic's chart, Sonnet 5.5's Terminal-Bench score at High effort is 43.0% — a long way below 70.6%. If you call the API with defaults, you are not buying the headline score. You are buying something cheaper and lower, which may well be the right trade.

Third, Anthropic's most interesting claim is about that trade: on several benchmarks, Sonnet 5.5 at Low or Medium effort beats Sonnet 5's best score for about a tenth of the cost per task. If that holds on your work, the biggest saving in this release is not the model swap. It is the chance to run the new model at a lower effort setting than you ran the old one.

Sonnet 5.5 or Opus 5.5? Do the arithmetic

The list prices make Opus 5.5 exactly twice the cost of Sonnet 5.5 on input and output. So the question is never "which is better" but "is Opus enough better, on my tasks, to cover a 2x rate". The numbers below are illustrative. The token volumes are assumed, not observed, and they exist only to show the shape of the calculation. Cache writes are left out for simplicity.

ASSUMED TASK: on Sonnet 5, one agentic coding task consumes 100K uncached input tokens, 300K cache-read tokens and 40K output tokens.

Scenario	Uncached input	Cache reads	Output	Cost per task	Per 10,000 tasks
Sonnet 5, baseline volume	$0.20	$0.06	$0.40	$0.66	$6,600
Sonnet 5.5, 30% fewer tokens (assumed)	$0.14	$0.042	$0.28	$0.462	$4,620
Opus 5.5, same volume as Sonnet 5.5 (assumed)	$0.28	$0.042	$0.56	$0.882	$8,820

On these assumptions, Opus 5.5 costs about 1.9 times as much per attempt as Sonnet 5.5 — slightly under 2x, because the cache-read line is priced the same on both. That gives you a usable break-even rule: Opus 5.5 only wins on cost if Sonnet 5.5 needs roughly two attempts for every one Opus needs to reach an accepted result, or if a Sonnet failure costs you something real — a human review hour, a broken deploy, an unhappy customer — that the token bill does not show.

In practice that sorts work fairly cleanly. Well-scoped, high-volume tasks — bug fixes against a clear failing test, document and spreadsheet generation, ticket triage, extraction — are Sonnet territory, which is roughly how Anthropic positions it. Long-horizon work where one wrong judgement early wastes an hour later, and where a human has to unpick it, is where the Opus premium earns its keep. Our guide to cost per successful task rather than per token sets out the full method, including how to price the human time that never shows up on an invoice.

In GitHub Copilot from day one

According to GitHub's changelog, it started rolling Sonnet 5.5 into Copilot on 28 September for Pro, Pro+, Max, Business and Enterprise plans, across VS Code, Visual Studio, JetBrains IDEs, Xcode, Eclipse, the Copilot CLI, the Copilot coding agent, github.com and GitHub Mobile. The rollout is gradual, so not every seat will see it at once.

Two details matter for whoever owns the Copilot budget. GitHub bills the model at provider list pricing under usage-based billing — the same model we covered when Copilot moved to usage-based billing — so token efficiency flows straight through to your bill rather than being absorbed into a flat seat price. And GitHub says new models are enabled by default for Business and Enterprise unless an administrator has turned them off in model policy settings. If your organisation has a policy of qualifying models before developers can pick them, check that setting this week rather than discovering the new option in someone's pull request.

How to requalify before you switch

A same-price release is easy to let drift for a quarter, because nothing is broken. Our three-day requalification drill was written for a price cut, but the method transfers directly. Compressed:

1. Freeze a task set. Twenty to fifty real tasks from your own backlog with known good outcomes. Generic benchmarks will not tell you about your prompts; a private harness on your own repository will.
2. Pre-register the thresholds. Write down before you run anything what pass rate, cost per accepted task and latency would justify a switch. Deciding afterwards is how a 5% improvement becomes a strategy.
3. Measure per completed task, not per call. Input, output and cache-read tokens per task, wall-clock per task, and failures counted separately.
4. Sweep effort. Run at least Medium and High. The comparison that matters may be Sonnet 5 at High against Sonnet 5.5 at Medium.
5. Assert the model identifier on every response. Anthropic says higher-risk security requests on Sonnet 5.5 fall back to Sonnet 5 under its new cyber safeguards. Routine debugging should be unaffected, but if your workload includes security tooling, a share of your "Sonnet 5.5" results may have come from the older model. Log it and check.
6. Cut over partially. Move a slice of traffic, watch a week of production numbers, then move the rest.

What it means for INR- and GBP-budgeted teams

These are dollar prices. A startup in Pune invoicing in rupees and a scale-up in Leeds paying in pounds both carry an exchange-rate line that moves independently of Anthropic's pricing page. A 30% token saving is a 30% saving in dollars; what it is worth in your currency depends on the rate on the day of the invoice. Model the saving in the currency you actually pay in, and re-check it each quarter rather than once at switch-over. Our guide to forecasting an LLM bill before launch covers building that into the model properly.

Availability does quieter work. Because Sonnet 5.5 is on Amazon Web Services, Google Cloud and Microsoft Azure as well as Anthropic's own platform, most teams in Hyderabad, Chennai, London or Edinburgh can route the spend through a cloud commitment they already hold. For many, drawing down existing committed spend is worth more than the efficiency gain itself. Zero data retention is also available, which UK teams selling into regulated buyers will want documented before procurement asks. Check data-processing location and retention terms on whichever route you choose, rather than assuming they match across clouds.

For high-volume consumer products, which are common on the Indian side of our readership, token efficiency is the lever that matters, because volume multiplies every wasted token. For UK teams under assurance processes, the more useful consequence is procedural: the evaluation evidence you gather to verify the cost claim is the same evidence a model-change review will ask for. Run it once, use it twice.

Two smaller notes worth knowing. Anthropic says Sonnet 5.5 includes invisible text watermarking, which content teams should factor into any disclosure policy. And it is the first Sonnet launched with cybersecurity safeguards similar to those on Opus 5.5 — the source of the fallback behaviour above.

What to do this week

1. Fix the forecast. If you budgeted Sonnet at $3/$15 from September, bring it back to $2/$10. That is a committed number.
2. Pull your token split by feature. Uncached input, output, cache write, cache read. It tells you how much of the Sonnet-versus-Opus gap you will actually feel.
3. Run the comparison at more than one effort setting, with the model identifier asserted on every response.
4. Check Copilot model policy if you run Business or Enterprise seats.
5. Decide Opus per workload, never globally. Keep it where a failed attempt is expensive; move volume work to Sonnet 5.5 once your own numbers say so.

The honest summary is unglamorous. Sonnet 5.5 changes nothing on the price sheet and possibly a great deal on the invoice. The teams that benefit first will be the ones already measuring cost per accepted task, because they will know within a week whether "up to 30%" means 30, 10 or nothing for them.