Claude Opus 5.5: what it changes for your agents in production

What was announced

Anthropic released Claude Opus 5.5 on 22 September 2026. The company presents it as its most capable model for coding, agents and knowledge work, with a clear gap over Opus 5 on its reference tests: Terminal-Bench 4.0 rises from 52.3% to 66.4%, OSWorld 2.0 from 74.0% to 81.8%, and AutomationBench from 26.9% to 40.0%.

The point that matters most to a company lies elsewhere: price and speed. The announced rate is four dollars per million input tokens and twenty dollars per million output tokens, twenty percent below Opus 5, with cache reads at twenty cents per million, sixty percent cheaper. Anthropic announces a bill forty percent lower than Opus 5 on typical workloads, and generation more than thirty percent faster. The model is available on the Claude platform and through Amazon Web Services, Google Cloud and Microsoft Azure.

On safety, the company states the model was tested before release by external evaluators including Frontier Design and METR, and that it achieves the best results to date on its automated behavioural audit. Official sources are listed at the end of this article.

Why a price per million tokens is not your cost

A rate cut is hard to read when you do not know what you consume. The cost of an agent in production never comes down to the listed price: it depends on the length of the instructions sent with each call, how much context is recalled, the number of exchanges per user, how much of that context is cached, and the number of calls the system makes invisibly, for instance to check an answer before displaying it.

Two companies using the same model for the same purpose can see very different bills depending on how their system is built. That is why we measure cost per run during the prototype, before announcing anything. Our article on the cost of an AI agent in production details the items to watch.

So the right way to read this kind of announcement is: unit price falls, therefore uses that sat at the edge of viability may now cross the line. What remains is to check which ones, in your context.

Reading benchmarks without fooling yourself

The gaps announced on Terminal-Bench, OSWorld or AutomationBench measure generic tasks: driving a terminal, coping in a desktop environment, chaining actions without help. They say something real about the model's ability to carry a long task without derailing, and that is exactly what matters for an agent working alone across several steps.

They say nothing about your case. An agent reading purchase orders from one specific supplier, with business vocabulary, in-house abbreviations and documents scanned crooked, succeeds or fails for reasons those tests do not cover. A ten-point gap on a public benchmark may translate into no gap at all for you, because the difficulty lay elsewhere, or into a much larger one, because your task is precisely what the model handled poorly.

The rule we apply is simple: vendor benchmarks decide whether an evaluation is worth running, never whether to switch. What decides is your own case set.

Speed or cost: an explicit trade-off

Anthropic also offers a fast mode, billed at eight dollars per million input tokens and forty per million output, twice the standard rate. That kind of option turns a technical question into a product question: for which use is speed worth its price.

The answer depends on who is waiting. A visitor in front of a chat gives up if the answer is slow, so speed has direct value. An overnight batch over a set of documents keeps nobody waiting: a few extra minutes cost nothing, and the standard rate is enough. In between, an internal agent used by a team that knows what it launched usually tolerates the wait if the result is good.

One system can therefore use both regimes depending on the path taken: fast for what is awaited on screen, standard for what runs in the background. That is a setting, not a rebuild, provided model and mode were treated as parameters from the start.

What a cost cut actually changes

When cost per run falls, it is not existing uses that change, it is the uses you had set aside that become arguable again.

• Batch processing. Reviewing every contract in a file, sorting an entire mailbox, checking each line of an export: these are volume plays, so unit cost decides whether they exist.
• Systematic checking. Having each answer reviewed by a second pass costs one more call. At a high price you arbitrate. At a lower price you can afford that safety belt on sensitive subjects.
• Wider context. Giving the model a full case history rather than a summary often improves relevance, and costs input tokens. Cheaper cache reads make that approach more accessible.
• Long-running tasks. An agent chaining dozens of steps on one case consumes more than an assistant answering a question. The announced speed gain matters as much as price here, because it shortens the wait.

Conversely, if your agent handles a few dozen requests a day, the rate cut will not change your budget much. It will show in comfort of use, not on the bill.

What a new model does not solve

A more capable model replaces none of the engineering decisions that make an agent usable in a company.

• What commits the company does not come out of the model. A price, an availability, a product reference, an address: these are computed server side, chosen from a closed list and checked before display, whatever the model. That is the subject of our article on why an AI agent must never quote a price.
• The knowledge scope. An agent that answers from your content needs that content to exist, be current and be accessible. No model compensates for an empty or outdated knowledge base.
• Data and permissions. Where data travels, who sees it, how long it is kept: these belong to architecture and contracts, not to the model. Our article on hosting an AI project in France presents the options.
• Regulatory duties. Informing users and transparency stay the same. See our article on the AI Act for smaller companies.
• The place of the human. What gets approved before it has an effect depends on the risk carried by the decision, not on model quality. It is one of the principles of our responsible AI memo.

Should you switch models? The method

Switching models is a production operation like any other: it is prepared, measured and reversible. Here is how we proceed.

• Replay your evaluation set. This is the first reason to build one: real cases with expected answers, including the hard ones. Without it, a model change is judged on impressions, and impressions do not catch regressions.
• Compare on your cases, not on public benchmarks. Vendor results measure generic tasks. Your agent reads your documents, with your business vocabulary and your edge cases.
• Measure real cost on a sample. The same volume of runs on the old and the new model, with the bill to back it. It is the only way to know what the announced cut gives in your case.
• Retest the guardrails. A different model phrases things differently. Filters that catch a forbidden value, expected output formats and refusal rules all need retesting.
• Switch gradually. Part of the traffic first, with the ability to roll back in one line of configuration. A model is chosen by setting, never hardcoded.
• Keep the trace. Record which version answered what, so an answer can be explained later.

None of this is exceptional: it is what we apply at every update, and it is what lets you benefit from a price cut without discovering a regression through a customer call.

The trap of chasing the latest model

Announcements come faster than projects do. A system built to follow every release spends its time migrating and never improving the service delivered. A system built to be indifferent to the model absorbs new releases effortlessly.

In practice that means three things: the model is a configuration, not a dependency buried in code; quality is measured on a case set of your own, kept and versioned; guardrails live server side, not in the prompt sent to the model. A team with those three can test a new model in a day and decide on numbers.

For the same reason, a project should never be paused waiting for the next model. The most solid gains almost always come from what surrounds the model: data quality, clarity of scope, integration with existing tools and adoption by the teams.

What we do with this release

We replay our evaluation sets on the agents we operate, compare measured cost on a representative sample, and switch where the gain is clear and the guardrails intact. Where the gap is small, we change nothing: a migration without measured benefit is a free risk.

If you run an agent in production and wonder what this announcement changes for you, the answer comes down to a measurement on your own cases. Our AI agent method describes the framework, and our AI diagnostic places your project in a few minutes.

Sources

• Anthropic, Claude Opus 5.5 (announcement and pricing)
• Anthropic, Claude Opus 5.5 System Card (22 September 2026)
• Anthropic, Introducing Claude Opus 5

Frequently asked questions

Should you migrate to Opus 5.5 right away?

Only after replaying your evaluation set on your own cases and measuring real cost on a sample. Where the gain is clear and the guardrails intact, switch gradually, with rollback available through configuration.

Does a rate cut cut my bill by the same amount?

Not mechanically. Your bill depends on instruction length, recalled context, calls per request and how much is cached. The unit price falls, your consumption stays yours: it has to be measured.

Does a more capable model make guardrails unnecessary?

No. Data that commits the company, prices, availability, references, stays computed server side and checked before display. A different model phrases things differently, so those filters are retested at every change.

Which uses become worthwhile when cost falls?

Volume plays: batch processing, systematic checking of answers, wider context given to the model, agents chaining many steps. For a few dozen requests a day, the budget effect stays small.

Should a project wait for the next model?

No. The most solid gains come from data quality, clarity of scope, integration with existing tools and adoption. A system where the model is a simple setting absorbs later releases without a heavy migration.