Claude Opus 5.5 Is Cheaper per Token—but Agents Need a Contract Migration
Anthropic released Claude Opus 5.5 on September 22, 2026, with lower standard token prices than Opus 5. The safe interpretation is not “same endpoint, smaller bill.” Opus 5.5 changes the Messages API contract around thinking, tool selection, response blocks, conversation state, computer use, progress updates, and refusals.
Some incompatibilities fail immediately with HTTP 400. Others return HTTP 200 while changing reasoning depth, hiding progress narration, dropping prior thinking during a model switch, or allowing a fallback model to complete the request. Transport success therefore does not prove behavioral equivalence.
A defensible migration has two gates:
- The request, response, transcript, streaming, tool-loop, refusal, fallback, and serving-route contracts still hold.
- The cost of producing an accepted result improves without weakening the acceptance standard.
Technical review: September 26, 2026. This article distinguishes documented API behavior, attributed external evaluations, and proposed validation steps.
Confirmed release specification
The Claude Platform model page confirms the following:
- Release date: September 22, 2026
- Claude API model ID:
claude-opus-5-5 - Amazon Bedrock model ID:
anthropic.claude-opus-5-5 - Google Cloud, Microsoft Foundry, and Claude Platform on AWS ID:
claude-opus-5-5 - Context window: 1 million tokens
- Standard maximum output: 128,000 tokens
- Message Batches beta maximum: 300,000 output tokens with the documented beta header
- Thinking: adaptive and always on
- Effort levels:
low,medium,high,xhigh, andmax - Default effort:
medium - Platforms: Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry
The standard 128,000-token output limit should not be conflated with the separate 300,000-token Message Batches beta.
What changes when an Opus 5 agent moves to Opus 5.5
Anthropic’s migration guide is specifically for Messages API integrations. It says Claude Managed Agents require only the model-name update, so the failures below should not be projected indiscriminately onto that managed product.
| Contract surface | Opus 5 | Opus 5.5 | What to detect |
|---|---|---|---|
| Thinking control | Thinking may be disabled; Opus 5 accepts that setting at supported effort levels | Disabled thinking and manual budget_tokens are rejected | HTTP 400 |
| Tool selection | tool_choice may force any tool or a named tool | Only auto and none are supported | HTTP 400 |
| Preserved thinking | Some applications rebuild or edit earlier context | Thinking blocks are bound to the model and conversation prefix | HTTP 400 or dropped blocks, depending on account and settings |
| Computer use | computer_20251124 can be used | Rejected on the Claude API and Google Cloud; still supported on Amazon Bedrock | Route-dependent HTTP 400 |
| Progress rendering | Inter-tool narration arrives as text | Narration arrives in thinking blocks whose display text is omitted by default | HTTP 200, but progress may disappear |
| Default effort | high | medium | HTTP 200 with different depth, latency, and token use |
| Classifier refusal | Successful response can contain a refusal | Additional refusal categories and optional fallback behavior apply | HTTP 200 with stop_reason: "refusal" |
This split between hard errors and successful-but-different responses is the core migration risk. A canary that checks only status codes can detect rejected payloads while missing a lower reasoning setting, an apparently stalled interface, a model handoff, or discarded reasoning state.
Always-on thinking changes request and response handling
Disabled thinking and manual budgets now fail
For Opus 5.5, applications must either omit the thinking field or send adaptive thinking explicitly. These two earlier patterns are rejected:
thinking: {"type": "disabled"}thinking: {"type": "enabled", "budget_tokens": N}
Thinking depth is controlled through output_config.effort. The supported values are low, medium, high, xhigh, and max; the default is medium.
That default matters because Opus 5 defaults to high. An application that leaves effort unspecified therefore changes configuration even if every request continues to succeed. Anthropic also says Opus 5.5 tends to think more per turn than Opus 5 at the same named effort level, particularly at xhigh and max. Effort should consequently be calibrated against the target workload rather than copied from an older model.
max_tokens includes hidden thinking
The migration guide states that max_tokens is a combined ceiling for thinking and visible response text. Thinking tokens are billed as output tokens even when their text is not displayed.
A limit sized around a model or configuration that did not use thinking may therefore truncate visible output earlier than expected. Code should also stop assuming that content[0] is a text block: an Opus 5.5 response can begin with one or more thinking blocks. Consumers should select blocks by their type.
Check inherited sampling and prefill settings
Older client wrappers may still attach sampling overrides or an assistant prefill. The current migration guide rejects non-default temperature, top_p, or top_k and rejects a prefilled final assistant turn. Inspect the payload after middleware has transformed it; a clean call site does not prove that the transmitted request is compatible.
Forced tool choice is gone
Opus 5.5 rejects these tool_choice forms:
{"type": "any"}{"type": "tool", "name": "..."}
The supported choices are auto and none. Anthropic recommends auto with strict tool schemas or structured outputs where schema-valid arguments are required.
Strict validation addresses the shape of a tool call if one occurs. It does not recreate the old API-level instruction that the next response must call a particular named tool. Workflows that require a tool invocation should verify the invocation as an outcome rather than infer it from a valid request.
Conversation history is now signed application state
Thinking blocks should no longer be treated as disposable response decoration.
In a tool-use loop, Anthropic requires the preceding assistant response—including thinking blocks—to be sent back complete and unmodified with the tool result. A serializer that drops empty blocks, changes their order, strips unfamiliar types, or reconstructs the assistant turn can invalidate the conversation.
The broader preserved-thinking documentation also binds a thinking block to the conversation prefix that produced it. That prefix includes the system prompt, tools, and earlier messages. For accounts created on or after August 31, 2026 at 00:00 UTC, the prefix check is enforced by default. A mismatch normally returns HTTP 400, although applications can opt into dropping affected blocks instead.
This expands the migration surface beyond the API client. Transcript databases, queue workers, gateways, retry handlers, redaction layers, history compaction, dynamic tool registries, and session-resume code can all alter the prefix.
Model switches can succeed after discarding reasoning
Compatibility is directional:
- Opus 5.5 can read thinking blocks from Opus 5 and earlier Opus, Sonnet, and Haiku models.
- It cannot read thinking blocks from Fable or Mythos models.
- On the Claude API, Fable 5.1 and Mythos 5.1 can read Opus 5.5 thinking blocks.
- Other models cannot read Opus 5.5 thinking blocks.
When the target model cannot read a block, the API can drop it before inference without failing the request. The request still succeeds, but the next model operates without that earlier reasoning. A successful fallback is therefore not evidence of equivalent reasoning continuity.
Progress can disappear while tools continue working
Opus 5 returns short narration between tool calls as ordinary text. Opus 5.5 returns that narration in progress-update thinking blocks.
The default thinking.display value is "omitted". Under that setting, the blocks retain their signatures but expose an empty thinking field. An agent can continue invoking tools while a user interface that previously rendered text blocks appears silent.
Anthropic documents two opt-in display modes:
"summarized"returns readable summarized thinking, including progress information."updates"is a beta option that returns progress updates while keeping other reasoning hidden. It requires thethinking-display-updates-2026-08-18beta header.
This is a product contract, not merely a parser detail. Migration testing should verify update ordering, time to first visible progress, accessibility behavior, and whether silent tool activity is interpreted as a stalled agent.
Computer-use compatibility is route-specific
On the Claude API and Google Cloud, Opus 5.5 rejects the earlier computer_20251124 tool and requires computer_toolset_20260801. Anthropic’s migration guide says the earlier tool continues to work on Amazon Bedrock.
The retrieved primary documentation does not establish equivalent behavior for every computer-use feature on Microsoft Foundry or Claude Platform on AWS. Teams using those routes should verify the current compatibility documentation and execute route-specific contract tests rather than extrapolating from the Claude API, Google Cloud, or Bedrock.
An HTTP 200 response may come from a refusal or a fallback
Anthropic’s refusal documentation defines a classifier refusal as a successful HTTP 200 response with:
stop_reason: "refusal"- a
stop_detailsobject whose category may identify the policy area
A refusal may arrive before output or during a stream. Applications should branch on stop_reason or stop_details.type, not on HTTP status or whether the content array is empty.
Server-side fallback is a beta feature of the Claude API. It is not available on the Message Batches API, Amazon Bedrock, Google Cloud, or Microsoft Foundry; Anthropic points those platforms to client-side fallback instead. When server-side fallback runs, the response identifies the model that actually answered and records the attempts in usage.iterations.
Fallback continuation is a special replay case
The ordinary tool loop in Figure 2 preserves the assistant turn. A streamed response containing a server-side fallback boundary needs the documented continuation rules: retain the boundary and text, keep blocks after the final boundary, and remove earlier thinking and client-side tool-use blocks as directed. Retain an earlier server-tool call only with its matching result. Treat this as an explicit fallback branch in the serializer, not a general reason to filter ordinary thinking blocks.
Operational monitoring should therefore record at least:
- requested model
- serving model
- refusal category
- whether fallback ran
- token usage for each attempt
- final acceptance result
Without those fields, availability can remain green even when the primary model declines and another model finishes the turn.
The list-price reduction is real—but it is not a 40% rate cut
The model pages for Opus 5.5 and Opus 5 publish these standard U.S.-dollar prices per million tokens:
| Standard token category | Opus 5 | Opus 5.5 | Recalculated change |
|---|---|---|---|
| Fresh input | $5.00 | $4.00 | 20% lower |
| Output, including thinking | $25.00 | $20.00 | 20% lower |
| Five-minute cache write | $6.25 | $5.00 | 20% lower |
| One-hour cache write | $10.00 | $8.00 | 20% lower |
| Cache read | $0.50 | $0.20 | 60% lower |
These are standard rates, not a universal invoice forecast. Anthropic’s pricing documentation separately documents:
- a 50% Batch API discount on input and output;
- a 1.1× multiplier for supported U.S.-only inference configurations;
- a 10% premium for relevant regional or multi-region partner-cloud endpoints;
- marketplace billing through consumption units on Claude Platform on AWS and Microsoft Foundry;
- provider-specific Bedrock and Google Cloud billing;
- negotiated enterprise discounts;
- additional charges for some server-side tools.
Anthropic’s launch announcement also lists Opus 5.5 fast mode at $8 per million input tokens and $40 per million output tokens. Fast mode is a Claude API research preview and should not be mixed into a standard-rate comparison.
Attributed vendor claim
In its September 22 announcement, Anthropic says its tests show that Opus 5.5 costs 40% less than Opus 5 on typical workloads at default settings and generates output more than 30% faster.
Those figures are Anthropic’s workload-level results, not the rate-card reductions. The 40% claim combines pricing with workload-dependent token consumption and compares each model at its default setting—medium for Opus 5.5 and high for Opus 5. It should not be presented as a guaranteed saving for a fixed prompt, effort level, tool loop, or acceptance standard.
A more useful production measure is accepted-task cost:
model tokens + cache operations + tool charges + retries + fallback attempts + reviewer correction required to produce an output that passes an unchanged rubric
That metric is an editorial inference from the documented billing and migration behavior, not an Anthropic metric.
Independent tests show why configuration matters
Artificial Analysis: maximum effort can consume the price advantage
Artificial Analysis evaluated all five effort levels with Anthropic’s default fallback enabled. On September 22, 2026, it reported an Intelligence Index score of 58 at maximum effort.
At that setting, Opus 5.5 used approximately 119,000 output tokens per Intelligence Index task, versus approximately 73,000 for Opus 5 at maximum effort. Artificial Analysis reported the two as roughly level on cost per task despite Opus 5.5’s lower token prices.
Output tokens alone do not reproduce the full invoice: input use, cache behavior and fallback attempts also matter. This result applies to Artificial Analysis’s index, harness, maximum-effort configuration, and fallback settings. It supports a narrow conclusion: higher output volume can offset lower unit prices. It does not establish equivalent cost across production agents generally.
Sonar: less Java output, but a different defect profile
Sonar’s pre-release Java evaluation used Opus 5.5 at high effort and recorded 4,444 tasks. Its functional pass rate covers the 544 HumanEval and MBPP tasks with executable tests; ComplexCodeEval contributed to code analysis but not to the pass-rate calculation.
Sonar reported:
- 87.68% pass rate for Opus 5.5 versus 88.6% for Opus 5;
- 664,890 generated lines versus 916,813, a 27.5% reduction;
- 40% fewer output tokens;
- 12% higher bug density, from 576 to 644 findings per million lines;
- 44% higher concurrency/threading finding density, from 205 to 295 per million lines;
- fewer absolute bugs and fewer total findings, aided by the lower volume of generated code.
These findings are bounded to Sonar’s Java prompts, analyzers, task set, model settings, and pre-release build. They justify testing concurrency-heavy code in an organization’s own stack; they do not predict a 44% change in other languages or repositories.
METR: a narrow AI R&D assessment, not a general product review
METR’s predeployment assessment used API access over 10 business days and five tasks focused on AI research and development capabilities.
METR concluded that Opus 5.5 was likely a modest, incremental improvement over Fable 5.1 rather than a discontinuous jump, and was unlikely to fully automate AI R&D. The report explicitly does not assess general coding quality, production cost, or alignment properties.
Its independence disclosures are material: the work was unpaid; METR drafted the initial summary; Anthropic could review and edit it; and METR approved the final text. A separate METR team supplied conclusions from a preliminary internal assessment without sharing the supporting evidence or reasoning with the team that wrote the public summary.
Proposed validation before migration
Tech Trend Insight did not perform these tests. They are proposed checks for teams evaluating their own integration.
-
Replay representative tasks at fixed effort levels. Compare Opus 5 and Opus 5.5 at explicitly set
low,medium, andhigheffort. Keep prompts, tools, timeouts, and the acceptance rubric unchanged. -
Test transcript preservation end to end. Pass fixtures containing
thinking,text,tool_use, andtool_resultblocks through databases, queues, serializers, proxies, redaction, compaction, retries, and session restore. Assert that assistant blocks return unchanged and in order. -
Verify required tool behavior. For workflows that previously forced a tool, assert that the expected call actually occurs. Schema-valid arguments are not sufficient evidence that the workflow still invokes the tool.
-
Exercise progress rendering. Compare omitted, summarized, and—where appropriate—the beta updates display modes. Check ordering, first visible update, screen-reader output, and perceived stalls.
-
Test each contracted serving route. Include disabled thinking, manual budgets, forced tool choice, the legacy computer-use tool, preserved-thinking mismatches, and configured fallback behavior. Do not use one route’s result as proof for another.
-
Measure accepted-task economics. Record acceptance rate, total input and output tokens, cache writes and reads, tool charges, retries, fallbacks, latency, and reviewer correction. Preserve the same quality threshold across models.
-
Target workload-specific defects. For generated code, run the organization’s own compiler, test suite, static analysis, security analysis, and concurrency or race-detection tooling.
Migration decision rule
Approve the production change only if both statements are true:
- Contract gate: request validation, content-block parsing, transcript replay, tool loops, streaming progress, refusals, fallbacks, and route-specific payloads pass.
- Outcome gate: accepted-task cost improves at an unchanged acceptance threshold while latency and visible progress remain within service requirements.
If either gate fails, keep Opus 5 on the affected workload while correcting the integration or recalibrating effort. The lower rate card makes Opus 5.5 a strong migration candidate; it does not make a blind model-ID swap a safe release procedure.
