Claude Opus 5.5: What Production Teams Change After Opus 5

Migration thesis

Claude Opus 5.5 shipped on September 22, 2026, with the API identifier claude-opus-5-5. It is the first model in Anthropic’s Claude 5.5 family and is designed for long-running agentic coding and knowledge work. For a team already operating Claude Opus 5 in production, the migration is not a model-name substitution. It changes cost models, throughput assumptions, request construction, thinking controls, tool schemas, endpoint identifiers, and rollout procedures. [1][3]

Anthropic positions Opus 5.5 as reaching Fable 5.1 quality on most work. It also reports typical billed work at approximately 40% less cost than Opus 5 and output more than 30% faster than Opus 5. These are important planning signals, but they are not service-level guarantees. Actual savings and latency depend on workload shape, generated output, caching, batching, tools, request size, traffic, and deployment surface. [1][3]

Opus 5 remains available. Anthropic’s models overview classifies it as legacy and recommends Opus 5.5 as the daily starting point, but Opus 5 has not been shut down. A production team can therefore retain Opus 5 as a controlled fallback while validating Opus 5.5 behavior, cost, and compatibility. [2][4]

Price and throughput changes

Published token rates

The rate reduction applies across standard token billing, cache operations, batch processing, and first-party fast mode. The following comparison is limited to Claude Opus 5.5 and Claude Opus 5.

Standard input and output prices are each 20% lower. Cache reads fall from $0.50 to $0.20 per million tokens, a 60% reduction. Cache writes also decline, while batch input and output remain priced at half of the corresponding standard rates. Fast mode is cheaper in absolute terms on Opus 5.5 but remains a premium option at $8 per million input tokens and $40 per million output tokens. [3][5]

What the cost model must measure

A migration budget should separate uncached input, cache writes, cache reads, generated output, batch traffic, interactive traffic, fast-mode traffic, and retries. Comparing only input-token prices can misstate the economics of an agentic workflow, particularly when the workflow repeatedly supplies repository context or produces extensive tool-call traces.

The reported approximate 40% reduction applies to typical billed work, not every request. A workload with long outputs, repeated retries, or limited cache reuse may produce a different result. Teams should replay representative production tasks and calculate cost per successful task, rather than cost per isolated API request.

The reported speed improvement also requires workload-level validation. More than 30% faster output can reduce agent-cycle duration, code-review wait time, and interactive feedback latency. It does not establish an SLA or guarantee a fixed end-to-end completion time. Tool execution, queueing, context size, and application orchestration remain part of the measured wall-clock result.

Official scores and evaluation design

Reported benchmark results

Anthropic reports the following official scores for Opus 5.5, alongside the listed Opus 5 and Fable 5.1 baselines:

Terminal-Bench 4.0 and CursorBench 4.0 are directly relevant to teams building coding agents because they evaluate work in development environments. GDPval-AA v2.1 supplies an Elo-style measure for knowledge-work performance. The published figures indicate stronger reported performance for Opus 5.5 against both listed baselines, but benchmark results do not guarantee equivalent outcomes on a particular repository, tool suite, prompt, or security policy. [1][3]

Application-level acceptance tests

A responsible migration adds Opus 5.5 to an evaluation lane before changing the production default. The evaluation set should include long-running coding tasks, repository navigation, multi-step tool use, error recovery, structured outputs, knowledge-work tasks, and requests with large accumulated context.

Useful measurements include successful task completion, human correction time, tool-call validity, number of retries, total billed tokens, elapsed completion time, and the percentage of tasks requiring fallback to Opus 5. The official scores should inform test selection, while application-level results should determine release readiness.

Always-on adaptive thinking changes the caller contract

Thinking is no longer a request-level toggle

Adaptive thinking is always on in Opus 5.5. Callers cannot set thinking to disabled and cannot manually enable it. The default effort is medium. Applications that exposed thinking as a tenant setting, feature flag, request parameter, or model-specific configuration must remove or bypass those Opus 5-era branches for Opus 5.5. [3]

The practical replacement is not another thinking switch. Teams should tune the surrounding workflow: prompt structure, task decomposition, tool budgets, maximum output, timeout handling, retry policy, and stopping conditions. Since thinking tokens are billed as output tokens, cost accounting must include them in output-side measurements.

This constraint also affects configuration validation. A request builder should reject unsupported thinking combinations before sending traffic, rather than relying on an API error or silently producing a different request. Model-specific behavior belongs in a compatibility layer so that the rest of the application does not assume every Claude model exposes identical controls.

Context, output, and retention

Opus 5.5 provides a 1-million-token context window and a maximum output of 128,000 tokens. These limits support repository-scale coding, extended research tasks, and agent loops that accumulate substantial tool results. They do not eliminate the need for context management: teams still need to control irrelevant history, repeated tool results, and runaway task state.

Zero data retention remains available, as it was for the prior Opus model. Teams with retention-sensitive workflows should verify that their selected endpoint and account configuration preserve the required setting. Opus 5.5 is available through Claude API, Google Cloud, Microsoft Foundry, and Claude Platform on AWS under claude-opus-5-5. Amazon Bedrock uses anthropic.claude-opus-5-5. [3][4]

Claude applications also list Opus 5.5 for Pro, Max, Team, and Enterprise users. Fast mode is available in Claude Code and Claude Platform as a first-party research preview. [1][3]

Two API breaks that must be handled

tool_choice values

With Opus 5.5, the tool_choice values any and tool return HTTP 400. Callers should use auto with strict tool definitions instead. This is a request-construction break: the failure can occur before the model produces content, so production systems need validation before rollout. [3][6]

A compatibility layer should identify unsupported values locally and require an explicit migration to the supported configuration. Tests should cover every tool-selection path, including requests with no eligible tool, one eligible tool, multiple eligible tools, and strict schema validation. Teams should also verify the resulting tool-call sequence rather than assuming that auto reproduces the behavior of an older forced-tool configuration.

Computer-use tool identifier

Claude API and Google Cloud reject computer_20251124. Those integrations must use computer_toolset_20260801. Amazon Bedrock still accepts the older computer tool. A provider-neutral payload is therefore insufficient when the same application deploys across these surfaces. [3][6]

The migration should make the computer-tool identifier endpoint-aware. Tests need to cover request validation and actual execution, not only model selection. The deployment map must distinguish the model identifier used by Claude API, Google Cloud, Microsoft Foundry, and Claude Platform on AWS from the anthropic.claude-opus-5-5 identifier used by Amazon Bedrock.

Controlled rollout and longer-term implications

A production migration sequence

A practical sequence is to add Opus 5.5 without removing Opus 5, update thinking logic, update tool schemas, and introduce endpoint-specific model and computer-tool identifiers. Teams can then replay production-like tasks, compare cost per successful task and elapsed time, and increase traffic gradually. Opus 5 can remain available as a deliberate fallback while the new path is evaluated.

The rollout should monitor HTTP 400 rates, tool-call failures, retry volume, cache utilization, output-token distribution, task completion time, and human correction. These signals reveal migration regressions that headline benchmark scores cannot show.

Scope of the release

Opus 5.5 is the current subject of this migration, while Sonnet 5.5 and Haiku 5.5 were announced for the coming weeks and are not shipping in this release. Cyber and bio safeguards are described as close to Fable 5.1. Teams should treat those statements as part of model-risk review and continue applying their own access controls, sandboxing, approval gates, and monitoring for agentic workflows. [1][3]

Late in an evaluation workflow, AI Plaza, an objective research and workflow participant rather than a recommendation, currently lists Claude-Opus-5.5 at https://aiplaza.app. Availability and pricing can change. This article is not legal or financial advice.

References

[1] https://www.anthropic.com/claude-opus-5-5 [2] https://www.anthropic.com/claude/opus [3] https://platform.claude.com/docs/en/models/opus-5-5/whats-new-opus-5-5 [4] https://docs.anthropic.com/en/docs/about-claude/models [5] https://docs.anthropic.com/en/docs/about-claude/pricing [6] https://docs.anthropic.com/en/release-notes/api