Opus 5.5's Price Cut Allows Only 25% More Output • The Weighted Average

Teams moving to Anthropic’s newly released Claude Opus 5.5 should recalibrate reasoning effort before banking its claimed 40% reduction in typical workload costs. The narrower, reproducible price calculation allows only 25% more output tokens before the new model loses its standard output-price advantage over Opus 5—and the migration changes more than the model identifier.

A cheaper token is a conditional bargain

Anthropic’s launch supplies a persuasive reason to evaluate the model. It says Opus 5.5 performs at Fable 5.1’s level on most work, generates output more than 30% faster than Opus 5, and lowers standard input and output prices to $4 and $20 per million tokens. These are vendor claims and published tariffs, not results from a benchmark conducted for this article. The decision is whether that combination improves accepted work in an existing agent, not whether the launch table looks impressive.

The original budget test combines two sources. The previous Opus 5 model page lists $25 per million output tokens; the new launch lists $20. Divide the old rate by the new one: 25/20 = 1.25. Thus 25% more output at the new price costs exactly as much as the old output volume. This is an output-line break-even condition, not an estimate of total task savings or a prediction that the model will generate that much more.

That limitation is important. Input and cache spending can fall even when output spending rises. Conversely, fewer tokens need not mean better economics if the result takes more human correction. Keep those observations separate rather than compress them into a single theoretical discount. The calculation gives a team a concrete threshold to watch in its own usage records; it does not replace those records with a universal customer profile.

Caching offers a larger unit-price improvement. Anthropic lists standard cache reads at $0.20 per million tokens, versus $0.50 on Opus 5, while ordinary input falls from $5 to $4. The value depends on which categories the workload actually buys. The caching documentation exposes separate read, creation, and uncached-input usage fields. Those fields are the evidence needed to decide whether a persistent agent benefits more than a collection of unrelated short requests.

This extends our earlier Fable analysis of cache reads as an agentic cost lever without importing its illustrative workload assumptions. Do not borrow another model’s cache-hit rate or discount multiplier. Opus 5.5 has its own tariff, and your harness has its own conversation shape. A procurement forecast should start from observed usage categories rather than a launch’s description of typical work.

The first candidates should be existing Opus users whose expensive jobs are already measurable: repository changes with tests, document work with checkable evidence, or recurring workflows with an explicit acceptance rule. Keep those rules fixed while comparing the models. Teams without that record should build it before promoting the new default; otherwise a lower invoice could hide unfinished work, while a higher invoice could conceal a worthwhile improvement in completion.

The default changed underneath the benchmark

The Opus 5.5 release notes list 4 breaking changes: thinking cannot be disabled, forced tool use is unsupported, thinking blocks have model and conversation bindings, and an older computer-use tool is rejected on the Claude API and Google Cloud. There is also a non-failing response-shape change: text between tool calls arrives in thinking blocks and is empty at the default display setting. A basic request succeeding therefore does not prove that the integration still behaves correctly.

Reasoning effort is the central budget control. Anthropic’s effort guide says Opus 5.5 defaults to medium rather than Opus 5’s high. Its release notes also say the new model tends to think more per turn at a given effort setting, especially at the highest levels. Carrying high or maximum effort forward by habit can therefore produce a different spending pattern from the default-setting comparison behind the advertised savings.

Set the effort explicitly, but do not assume identical labels imply identical computation. Compare the levels on the actual acceptance set, including total output usage rather than only the final answer’s visible length. The effort documentation says the control affects response text, tool arguments, and thinking. A concise answer can still have an expensive path to completion. The useful optimization target is the least costly setting that preserves the required result.

Speed is a separate purchase. Fast mode prices Opus 5.5 output at $40 per million tokens, versus the launch’s standard $20 and old Opus 5’s standard $25. Combining those sources, 40/25 − 1 = 60% more per output token than the incumbent standard route. The new model can be cheaper at standard speed and dearer under a faster configuration without either price claim being contradictory.

Fast Opus 5.5 output costs 60% more than old standard Opus 5

Output price, $ per million tokens. Excludes input, caching and regional modifiers.

Anthropic launch, model and Fast mode documentation · Sep 23, 2026

The choice is legitimate when speed earns its premium. But Anthropic describes the Fast benefit as output tokens per second, not a guaranteed reduction in time to first token or total job duration. Its documentation also says switching between standard and fast invalidates the prompt cache. A runtime that toggles speed casually can change two cost components at once. Measure the full task before treating faster generation as faster delivery.

The schema path needs its own test. Strict tool use guarantees conforming tool names and inputs; it does not replace forced selection by guaranteeing that a tool will be called. Structured outputs provide a separate JSON-response path. Applications that previously forced a tool solely to obtain structured data should choose the appropriate supported mechanism and verify the downstream consumer, rather than mechanically removing the rejected parameter and declaring migration complete.

Rollback is no longer just another model name

Conversation state makes the migration asymmetric. The preserved-thinking documentation describes model compatibility and prefix binding, while the release notes say Opus 5.5 can read thinking from Opus 5 but the reverse direction does not preserve the new model’s reasoning. A request carrying incompatible thinking can succeed after the API drops those blocks. A healthy status code can therefore coexist with a meaningful loss of context.

That does not make rollback impossible. It means the rollback plan must say what survives: user messages, tool results, application-owned state, and any reasoning artifacts the target model can actually consume. Test a resumed multi-turn task rather than only a new conversation. An evaluation that starts every request from scratch will miss exactly the compatibility boundary that matters to a long-running production agent.

Account age introduces another specific condition. Anthropic says prefix-binding enforcement applies by default to accounts created on or after August 31, 2026, on the Claude API and cloud platforms. Replaying a bound thinking block after changing earlier instructions or tools can return an error. The migration guide recommends preserving conversation structure and using supported update mechanisms. Do not treat a successful trial on one older account as proof that another account has identical enforcement behavior.

The display change can create a quieter failure. If the product streams only text blocks as progress updates, the new default may leave users watching silence between tool calls even while the agent works. This is a response-contract issue, not evidence that inference stopped. Exercise the real interface and inspect the returned block types. Budget qualification includes whether a human can understand and supervise the work, not merely whether an API client eventually receives a final message.

A second false-success boundary appears in Anthropic’s refusal and fallback documentation. A declined request can return HTTP 200 with a refusal stop reason, and partial output should be treated as incomplete. Record that outcome distinctly from accepted work. Any authorized fallback needs its own model identity, spending record, and acceptance check; it should not silently inherit the original model’s benchmark reputation.

The strongest counterargument is Anthropic’s own evidence that the new model uses fewer tokens and completes difficult work more efficiently. That may make these concerns immaterial for a well-maintained integration. But the launch says most headline benchmark results use maximum effort, with a different setting for Terminal-Bench, while its typical-cost claim uses defaults. Neither result can be transferred wholesale to an inherited high-effort production configuration. The relevant evidence is a matched workload with the desired quality and the actual bill.

Promote the configuration that finishes the work

Start with a small set of expensive, recurring tasks whose outcomes can be checked without asking the same model whether it succeeded. Preserve inputs, tools, reviewer expectations, and environment state. Record failed attempts alongside successful ones. These are proposed evaluation controls, not a claim that this publication has already run an Opus comparison. The vendor evidence justifies the experiment; your acceptance evidence decides the deployment.

Then vary the controls deliberately. Compare explicit effort settings before enabling Fast mode. Observe cache reads and writes before changing prompt structure. Test the supported tool-selection and structured-output paths separately from model quality. This keeps a regression attributable: a worse result after changing the model, harness, tool schema, and speed together is difficult to diagnose and expensive to reverse.

The archive’s OSWorld analysis showed why versioned evaluation conditions matter. The same standard should govern an internal rollout. Store model, effort, service speed, account or platform, schema version, and acceptance result with each run. A comparative score without those conditions is too easy to misread later, especially when defaults change while the human-readable model family remains familiar.

There is a wider purchasing choice, too. Today’s GPT-6 Sol brief calculates how request configuration changes the apparent launch discount. Today’s Snorkel brief asks buyers to contract for accepted data rather than a supplier’s headline quality gains. Model tariffs and evaluation inputs are becoming cheaper or more sophisticated; neither development removes the need to define the delivered work. They make that definition more valuable.

Evidence that would strengthen the switch case is repeatable acceptance at lower total request cost, acceptable latency, and preserved state through realistic resumes. Evidence that would weaken it is output growth that erases the tariff gain without better results, a required tool path that no longer works, or rollback that loses essential context. If quality improves enough, a higher bill may still be justified—but that is a productivity argument requiring measured human effort, not a token-discount argument.

Agent-platform owners: trial Opus 5.5 at explicit medium and task-appropriate alternatives. Watch the 25% output-growth threshold as one line item, while accounting separately for input, caching, retries, and accepted results.
Integration owners: test the four documented breaking changes, progress display, multi-turn resumes, and rollback. Budget engineering work for those contracts before switching production traffic; a model-ID edit is not a migration test.
Finance and latency owners: approve Fast mode separately. Its $40 output tariff is a premium configuration, and the documented throughput benefit must improve the actual completion time to justify the purchase.

Opus 5.5 deserves an evaluation now, particularly where old Opus runs are costly and well instrumented. It does not deserve an unconditional promotion based on the launch’s average. Cheaper tokens become cheaper work only when the integration preserves both the budget and the result.

A cheaper token is a conditional bargain

The default changed underneath the benchmark

Rollback is no longer just another model name

Promote the configuration that finishes the work

Sources