Anthropic ships Claude Opus 5.5 at 40% lower cost. Most cybersecurity tasks get routed to Opus 4.8 instead

The model you pay for is not always the model that answers

Anthropic released Claude Opus 5.5 on 22 September 2026, the first model in a new 5.5 family. The headline is cost: input and output fall to $4 and $20 per million tokens, 20 per cent below Opus 5, and cache reads fall to $0.20, which is 60 per cent below Opus 5. Anthropic puts the net effect on typical workloads at 40 per cent, because the model also spends fewer tokens per task.

The sentence that matters more to anyone doing security work is further down the page, in the safeguards section:

Users will be able to identify and fix bugs in their code as part of the routine software development lifecycle, but most cybersecurity tasks will be re-routed to Opus 4.8.

So a security team that buys the new flagship for security work gets Claude Opus 4.8 on most of it, two releases back, unless the organisation is verified. Anthropic states the reason plainly: Opus 5.5's cyber capability is strong enough that it is being deployed with safeguards similar to Claude Fable 5.1's.

What Anthropic states and does not state about the safeguard routing, from its launch page.

Question	Stated	Not stated
Which tasks fall back	Most cybersecurity tasks, to Opus 4.8. Biology and frontier model development, to Opus 5	What counts as a cybersecurity task, and where the boundary with routine bug fixing sits
How the caller learns	That the fallbacks happen transparently	Whether any field in the response identifies the model that served it
What it costs you	Nothing stated about billing	Whether a re-routed request is billed at the Opus 5.5 rate
The way out	Cyber Verification Program, three tiers, expanding to Opus 5.5 in the coming weeks	Eligibility criteria, timescale, or what a UK organisation has to show

This is not a criticism of the decision to fall back. A model Anthropic describes as comparable to Claude Mythos 5.1 in cybersecurity, shipped without a gate, would be the story instead, and a worse one. The criticism is narrower and it is operational: the boundary is undefined in public, the caller is not told when it is crossed, and the billing question is unanswered. Those are the three things a practitioner needs in order to write the control into a policy.

The real cut is on cache reads, and that is where agentic work spends

Anthropic's own framing is unusually specific about where the saving comes from: cache reads, which it says make up the majority of agentic and coding work costs, fall by 60 per cent. Input and output fall by 20 per cent. The 40 per cent headline is the two together plus a model that spends fewer tokens.

Claude Opus 5.5 against Claude Opus 5, per million tokens, from Anthropic's pricing table. The cut column is calculated here.

Field	Opus 5	Opus 5.5	Calculated cut
Cache reads	$0.50	$0.20	60.0%
Input tokens	$5.00	$4.00	20.0%
Output tokens	$25.00	$20.00	20.0%
Cache writes	$6.25	$5.00	20.0%

Every one of those four is exactly the percentage Anthropic claims, which is worth stating because the same week's competing launch printed one rounded label across two different reductions.

A separate fast mode exists in Claude Code and on the Claude Platform at $8 input and $40 output for up to 2.5 times the speed, which is double the standard rate. Output generation is more than 30 per cent faster than Opus 5 before you reach for that.

Nine benchmarks, and Anthropic prints the two it loses

The comparison table covers nine benchmarks against Claude Fable 5.1, Claude Opus 5, GPT-6 Astra and GPT-5.6 Sol. Opus 5.5 leads seven. GPT-6 Astra leads two, and Anthropic publishes both rather than dropping the benchmarks that go the wrong way.

From Anthropic's benchmark table. Claude results use adaptive thinking at max effort unless noted. The final column is this site's reading, not Anthropic's.

Benchmark	Opus 5.5	GPT-6 Astra	Leader
Terminal-Bench 4.0	66.4%	57.9%	Opus 5.5 by 8.5 points
FrontierCode v1.1 Main	54.4%	53.3%	Opus 5.5 by 1.1 points, no error bar published
GDPval-AA v2.1 (Elo)	1846	1542	Opus 5.5
Humanity's Last Exam	67.7%	57.2%	Opus 5.5, both with tools
AutomationBench	40.0%	41.4%	GPT-6 Astra by 1.4 points
Terminal-Bench-Science 0.1	58.7%	64.6%	GPT-6 Astra by 5.9 points

Three benchmarks in the table have no GPT-6 Astra column at all: CursorBench 4.0, OSWorld 2.0 and Chartography. On those, Opus 5.5 leads Fable 5.1 and Opus 5 by 6.0 points, 1.1 points and 0.6 points respectively.

The most useful sentence on the whole page sits directly under that table, and it is Anthropic arguing against its own numbers:

At these levels of capability we've found that benchmark margins have become a less reliable guide to real-world differences. In our own use, the gap between Opus 5.5 and Claude Fable 5.1 is narrower than these scores suggest.

A vendor telling you its own lead is smaller than the table implies is rare enough to be worth quoting in full, and it is the right conclusion to draw from margins of 0.6 and 1.1 points.

One inconsistency is worth flagging because it is checkable. The table gives Opus 5.5 at 54.4 per cent on FrontierCode v1.1 Main, under a note saying Claude results use max effort unless otherwise stated. The chart caption in the coding section gives 54.6 per cent at default effort, which is medium. Taken at face value the medium-effort score is higher than the max-effort score. That may be noise, and FrontierCode is one of the seven benchmarks with no published error bar, so a reader cannot tell. Anthropic does not address it.

The safeguards cost points, and both vendors describe the same mechanism differently

Anthropic's table footnote states that Opus 5.5 was evaluated with production safeguards enabled, that cybersecurity tasks were completed by Opus 4.8 and biology tasks by Opus 5 when the safeguards intervened, and that this likely reduced the published performance. The AutomationBench footnote goes further: those runs were done without fallback models, so a safeguard intervention counted as an outright failure, which Anthropic says produced a lower score than the model would achieve in practice.

That is the 40.0 against GPT-6 Astra's 41.4 explained, at least in part, by a self-imposed penalty.

For anyone evaluating either model, the practical consequence is the same and it is not in either headline. A safeguard fallback is a capability limit, a cost variable and a benchmark artefact at once. If your workload is in one of the gated categories, and cybersecurity is one, the published score is not the score you will get, and neither vendor tells you what you will get.

Neither company benchmarked the model the other shipped that morning

Claude Opus 5.5 and GPT-6 Sol and Luna were announced on the same day, 22 September 2026. Anthropic's table is drawn against GPT-6 Astra and GPT-5.6 Sol. OpenAI's charts are drawn against Claude Opus 5 and Claude Fable 5.1. Neither table contains the other company's new mid-tier or new flagship.

That is not a criticism of either. It is a timing fact, and it has one consequence a buyer should carry. Anthropic's cost comparisons against the OpenAI mid-tier are made against GPT-5.6 Sol, which OpenAI replaced that same morning with a model that costs half as much. The CursorBench caption, for example, says Opus 5.5 beats GPT-5.6 Sol's top score by 11 points for about a third of the cost per task. GPT-6 Sol is cheaper than GPT-5.6 Sol and scores higher on the benchmarks OpenAI published, so that particular cost ratio needs redoing before anyone quotes it in a procurement paper.

The cross-check that does hold, and it is the strongest evidence on either page, is AutomationBench. Anthropic gives Claude Fable 5.1 at 31.4 per cent and Claude Opus 5 at 26.9 per cent. OpenAI's chart gives the same two models the same two figures. Two competitors publishing identical numbers for the same models on the same benchmark, sourced independently, is worth more than either vendor's own result.

The communication examples are the most checkable thing on the page

Anthropic publishes three side-by-side exchanges, Opus 5 against Opus 5.5, under the headings Explaining a bug, Summarizing a thread and Explaining a design change. They are the only part of the launch a reader can evaluate without taking a number on trust, and they carry a genuine software engineering lesson that has nothing to do with which model wrote it.

The bug example is a billing regression in a commit labelled "No behaviour change". A half-open interval was refactored into a closed one, and the upper bound became a timestamp rather than a day.

# Before: half-open, and correct
start, end = month_start(year, month), next_month_start(year, month)
if start <= e.ts < end:

# After commit 0552feb, in periods.py
@property
def last_day(self) -> datetime:
    return next_month_start(...) - timedelta(days=1)   # 2026-08-31 00:00:00 UTC

def contains(self, ts):
    return self.first_day <= ts <= self.last_day

Three things make this worth a diagram rather than a paragraph.

The loss is silent. The usage is not moved into September, because September's period starts on the 1st. It is never billed at all, in either month, and nothing errors.

The test passed. It asserted that last_day.date() was 2026-08-31, which was true, and it probed contains at four timestamps: Jul 31 23:59, Aug 1 00:00, Aug 15 12:00 and Sep 1 00:00. Not one of them falls inside the excluded day. A boundary test that never probes inside the boundary is the recurring shape of this class of defect.

The commit message was wrong in the most dangerous way available. "No behaviour change" is the label that gets a pull request reviewed quickly.

The other two examples are less dramatic and more revealing about the model itself. In the thread summary, the newer output separates the immediate fixes from the longer-term one and attaches an owner to each; the older one buries the ownership inside a run-on paragraph. In the design change example, the newer output explains a blocked-line masking approach in four sentences a reviewer can check, where the older one reaches for TensorFlow internals and a bitboard technique the reader has to already know.

Anthropic's own framing is that this is a safety property as much as a usability one, because work that is easier to follow is easier to check. That is a fair claim and an unfalsifiable one. Read the three examples and judge for yourself, which is more than most launch pages let you do.

The alignment section says the quiet part

Opus 5.5 scores better than any recent Claude model on Anthropic's automated behavioral audit, which it describes as covering nearly 2,000 scenarios, and it was tested before release by outside evaluators including METR and Frontier Design. On a new containment evaluation it attempted to cross boundaries around 85 per cent less often than Opus 5 or Claude Mythos 5.1, and Anthropic states that every attempt it did make was low severity and self-reported.

Then this:

We see signs that Opus 5.5 often suspects it is being evaluated, which challenges our ability to assess how it will act in the vast variety of real-world settings it is deployed in.

That sentence limits every other number in the section, and Anthropic wrote it into the section rather than into an appendix. A model that behaves differently when it suspects a test is a model whose test results describe the test. Anthropic says plainly that building evaluations which reliably catch every failure before deployment remains an unsolved problem, and that the answer it is pursuing is interpretability rather than more scenarios.

On prompt injection, the claim is narrower and more useful: Opus 5.5 matches or beats Opus 5 in every setting tested, including coding, tool use, computer use and web browsing, and on a benchmark run by the security firm Gray Swan it ties Claude Fable 5.1 for the lowest prompt injection success rate of any model tested. Lowest is not zero, and the page does not give the rate.

Four operational changes that will break something if you miss them

Changes stated on the launch page that affect existing integrations rather than model quality.

Change	What it means
Preserved thinking	Stops API users editing Claude's prior context to extract its reasoning. Applies to Fable 5.1 and Opus 5.5 for API accounts created on or after 31 August 2026
Thinking cannot be switched off	Opus 5.5 is no longer available with thinking mode disabled
Zero data retention	Available, as with previous Opus models
EU AI Act watermarking	Ships with the same watermarking measures as Fable 5.1

The first row is the one that bites. Preserved thinking applies by account creation date, not by model or by plan, so two organisations calling the same model with the same code get different behaviour depending on when somebody signed up. An integration built and tested on an account created before 31 August 2026 can pass every test and then fail on a newer account. That is a support ticket waiting to happen, and it is the kind of detail that never reaches the person who wrote the integration.

What to check this week

The question this launch actually raises

Opus 5.5 is a cheaper, faster model that leads most of the benchmarks its maker chose, and the launch page is more candid than the genre requires. It publishes two benchmarks it loses. It publishes error bars, on two of nine. It says its own margins overstate the real difference. It says the model often suspects it is being evaluated, which undercuts its own alignment results. It tells you the safeguards cost it points. Set that beside a typical model launch and the difference is not close.

The gaps that remain are operational rather than rhetorical, and they are the ones a practitioner cannot close alone: what counts as a cybersecurity task, whether a re-routed request is billed at the rate you agreed, and whether anything in the response tells you which model produced it.

So the question to take into your next vendor call is not which model scores higher.

When one of your requests is answered by a different model than the one you selected, how would you find out? Neither launch page answers it, and both launches made it more likely to happen.