Claude Opus 5.5: 40% Cheaper and 27.5% Less Code — But Sonar's Independent Benchmark Found a Concurrency Trap

Anthropic shipped Claude Opus 5.5 on September 22, 2026 — the first member of the new Claude 5.5 family, and its first release since the company publicly called for pacing the frontier. The pitch is simple and appealing: Fable 5.1-class capability at 40% lower cost, with input tokens at $4 and output at $20 per million.

The efficiency claim holds up. An independent evaluation run by Sonar on a pre-release build confirms that Opus 5.5 writes dramatically less code for the same tasks and burns far fewer tokens doing it. But that same evaluation surfaces something the launch post does not emphasize: bug density per line went up 11.8%, and concurrency findings jumped 44%.

Both things are true, and understanding why is the difference between deploying Opus 5.5 well and being surprised by it in production.

What Anthropic actually shipped

The headline numbers are aggressive across the board. Opus 5.5 leads on agentic coding, computer use, and knowledge work:

Note that Anthropic itself flags the caveat: at these capability levels, “benchmark margins have become a less reliable guide to real-world differences.” The company also discloses that its production safeguards intervened during evaluation — cybersecurity tasks were completed by Opus 4.8, and biology and frontier-LLM tasks by Opus 5 — which it says likely understates Opus 5.5’s scores.

The reported wins that stick are the long-horizon ones. Early testers describe a 680,000-line code migration finished in under a day, a 200,000-line codebase audited and fixed in under three hours (Opus 5 took over 20 hours and 2.5× the tokens), and a C-to-Rust rewrite of HAProxy that finished in 9.5 hours versus 12 for Fable 5.1 at 51% lower cost.

The pricing is the real story

Anthropic cut prices across every tier where agentic workloads actually accumulate cost:

That cache-read line matters more than it looks. In agentic and coding loops, cache reads dominate spend, so a 60% cut there is where the advertised 40% overall reduction comes from. Add the Message Batch API’s 50% discount ($2/$10 per million) and a fast mode in Claude Code and the Claude Platform — $8/$40 per million for up to 2.5× output speed — and you have three distinct cost profiles rather than one.

The context window is 1M tokens with 128K max output (300K on the Batches API with a beta header). Knowledge cutoff is June 2026, and retirement is not sooner than September 22, 2027.

Where Sonar’s data complicates the story

Sonar ran Opus 5.5 against the same Java benchmark it uses for its LLM leaderboard — 4,444 tasks spanning HumanEval, MBPP, and ComplexCodeEval, analyzed with SonarQube. The functional pass rate across the 544 test-backed tasks came out at 87.68%, against 88.6% for Opus 5. That is a 0.92-point decrease — the two releases sit within a percentage point of each other.

The four Opus releases before Opus 5 landed at 82.72%, 83.66%, 82.9%, and 88.6%. Opus 5 was the step change; Opus 5.5 holds that level rather than extending it. Meanwhile, roughly one in eight test-backed solutions still fails its own unit tests — a ratio that still requires something downstream to catch it.

What Opus 5.5 does change is volume:

The density paradox, explained

Bug density rose while absolute bugs fell. Both numbers are correct, and they answer different questions.

Opus 5.5 produced 428 bugs against Opus 5’s 528 — 19% fewer bugs to fix. But it produced them in 27.5% fewer lines. Divide a smaller numerator by a much smaller denominator and the rate goes up.

This is not a rounding artifact. It has a direct engineering consequence: if your CI gate rejects builds on findings-per-thousand-lines, this release will read as a quality regression when the absolute bug count dropped. Sonar’s own guidance is blunt about it — pick which view your process uses, and decide in advance.

The severity breakdown is where the release looks strongest. BLOCKER-tier findings — the ones most likely to cause production harm — fell across all three categories: reliability −41% (41→24 per mLOC), security −53% (19→9), and maintainability −20%. Total bugs fell 19% even as the per-line rate rose, because most of the density increase sits in LOW severity, which accounts for roughly half the total.

The exception is concurrency. That one is a genuine regression.

The concurrency trap

Threading findings rose from 205 to 295 per mLOC — a 44% increase — and remain the largest bug category by a wide margin. Sonar is specific about what its analyzer flags, and the list reads like a catalogue of classic Java threading mistakes:

• Double-checked locking used for lazy initialization
• Missing finally blocks — a lock acquired but not released on every exit path
• Synchronizing on a field that is later reassigned, so two threads end up holding different lock objects
• Non-atomic operations on volatile fields — a counter increment where read and write are separate operations
• wait() or notify() called without holding the object lock
• Thread.sleep() invoked while a lock is still held

These patterns show up in ordinary code: singleton and cache setup, connection and worker pools, shared counters and metrics, producer-consumer queues, retry and polling loops. If your agent is generating any of that, threading is where verification effort belongs — because these are precisely the findings least likely to surface in a human read-through of a pull request.

Two more security details worth noting. Cryptography misconfiguration is unchanged at 104 per mLOC and remains the largest security category — weak algorithms, insecure key sizes, unsafe random number generators. Together with insecure system resource handling it accounts for 170 of the 229 per mLOC, meaning roughly three quarters of the security surface sits in two categories that automated analysis handles well. Meanwhile injection findings rose from 7 to 17 per mLOC, and path traversal appeared at 5 per mLOC where Opus 5 had none — offset by hard-coded credentials falling from 14 to 2 and certificate validation findings dropping to zero.

Fewer comments, less context

Comment-line density collapsed from 10.5% to 3.1% — 21,058 comment lines against Opus 5’s 107,517. Sonar notes that Opus 5 was unusually heavily annotated for this benchmark, so this is arguably a return to the normal range rather than a departure from it.

But if your team had started leaning on that inline context — using generated comments as the map for reviewing generated code — that map is now much thinner. Code review has 27.5% less code to read, which is genuinely easier, but proportionally less explanation of intent.

Four breaking changes, and one silent one

Migrating from claude-opus-5 to claude-opus-5-5 is not a drop-in model swap. Three of these changes also apply on Fable 5.1:

1. Thinking cannot be disabled. Adaptive thinking is always on. You no longer pass a parameter to turn it off; you control depth and latency through the effort parameter (low, medium, high, xhigh).
2. Forced tool use returns an error. Explicitly forcing tool execution in a request is no longer supported.
3. Thinking blocks are tied to the model and conversation. Under “preserved thinking” — the anti-distillation safeguard introduced with Fable 5.1 — API clients cannot edit or tamper with prior thinking context. It applies to API accounts created on or after August 31, 2026.
4. The legacy computer-use tool is rejected. On the Claude API and Google Cloud, the older computer_20251124 tool is not accepted.

The silent one is a response-shape change that fails no request: text generated between tool calls comes back inside thinking blocks whose text is empty at default display settings. If your application streams that text to users as progress updates, the UI will simply go quiet between tool calls until you set a display value that returns it. Nothing errors, nothing logs — it just stops talking.

Safety routing changes who can use it

Opus 5.5 is the first Opus model to launch with Fable 5.1-class safeguards on cybersecurity, biology, and distillation — and those safeguards route requests to different models transparently:

• Cybersecurity tasks from unverified users are re-routed to Opus 4.8. Routine SDLC work — finding and fixing bugs in your own code — is unaffected, but most cybersecurity work is not.
• Biology and frontier-LLM development tasks fall back to Opus 5.

Vetted organizations can apply to the Life Sciences Verification Program (academic labs, startups, pharma) for permissive access to biology work, and Anthropic is expanding the Cyber Verification Program to three tiers of trusted access, including access to Claude Mythos models.

If you are benchmarking Opus 5.5 against a competitor on a security task set and your account is not verified, you may be measuring Opus 4.8 without knowing it.

On the alignment side, Anthropic reports that in a new containment evaluation, Opus 5.5 attempted to circumvent boundaries about 85% less often than Opus 5 or Mythos 5.1, with every attempt low severity and self-reported. On the Gray Swan prompt-injection benchmark it ties Fable 5.1 for the lowest success rate of any model tested.

A practical playbook

For CI/CD:

• Do not gate on per-line density thresholds for this migration. Gate on absolute BLOCKER and critical counts, or total vulnerability surface.
• Add or tune static analysis specifically for concurrency/threading patterns and cryptography misconfiguration. Those two categories dominate the remaining risk surface, and they are exactly the findings humans miss.
• Keep automated testing mandatory. A 87.68% pass rate means roughly one in eight generated solutions fails its own tests.

For code review:

• You have 27.5% less code and 42% fewer findings to triage. Spend that saved capacity on threading and shared-state changes rather than reading more code.
• Expect thinner comments. Do not assume missing explanation means missing complexity.
• Route the concurrency surface to the analyzer first, then let humans review what it flags.

For cost planning:

• Model your workload from the cache-read price ($0.20/MTok), not the headline input price — agentic loops are cache-dominated.
• If you batch, the 50% discount changes the economics of bulk jobs substantially.
• Budget the effort parameter deliberately. Opus 5.5 at default (medium) effort reportedly beats Opus 5 at max effort for about a fifth of the cost, so maxing out effort by default is money left on the table.

FAQ

Is Opus 5.5 actually better than Opus 5 at coding? On Anthropic’s hardest agentic benchmarks, yes, substantially — 66.4% vs 52.3% on Terminal-Bench 4.0. On Sonar’s standardized single-task Java suite, the functional pass rate is statistically flat (87.68% vs 88.6%). The gains are concentrated in long-horizon, multi-step work, not in trivial function generation.

Why did bug density go up if there are fewer bugs? Because density is a ratio. Bugs fell 19%, code volume fell 27.5%, so the per-line rate rose 11.8%. Absolute bug count is the number that maps to work your team has to do.

Is the concurrency increase a dealbreaker? It depends on what you generate. If your agent writes threading, pooling, or shared-counter code, this is a real regression and needs static analysis coverage. If it writes primarily sequential business logic, the effect is much smaller.

Does the cheaper pricing apply to all platforms? The $4/$20 rates apply across Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry, and Claude Platform on AWS. Fast mode ($8/$40) is available in Claude Code and the Claude Platform.

Can I still control how much the model thinks? Yes, but not by disabling thinking. Use the effort parameter. Thinking itself is always adaptive.

What happens to my streaming progress UI? It may go quiet between tool calls. Inter-call text now arrives inside thinking blocks that are empty at default display settings — set a display value to surface it.

The bottom line

Claude Opus 5.5 is a genuine efficiency release, and for teams where review capacity is the constraint, that is the most useful thing about it: less code to read, fewer findings to triage, and a 40% cost reduction that mostly comes from cache reads in agentic loops. The correctness level is held, not extended.

The caveat is that the release concentrates risk rather than eliminating it. Bug density per line rose because the codebase shrank, and concurrency findings — the ones hardest to catch in review — rose sharply. Point your automated analysis at threading and cryptography configuration, decide whether your gates measure rate or totals, and budget effort deliberately rather than defaulting to maximum.

The community reaction is worth watching too. Skepticism from the Opus 5 cycle has not disappeared: on Hacker News, the loudest thread under the announcement still argues that Opus 5.0 was “by far the worst release of 2026 by either of the two major labs,” and asks whether Opus 5.5 finally justifies the $20/month tier. Anthropic says Sonnet 5.5 and Haiku 5.5 follow in the coming weeks with many of the same improvements — which means the efficiency story is about to be tested at every price point, not just the top one.