A long-running coding agent can spend much of its bill reading the same repository, instructions, and accumulated work. Claude Opus 5.5 makes that repetition substantially cheaper. But collecting the savings requires keeping the session intact—and updating the software that decides what happens next.
Anthropic released Opus 5.5 on September 22 at $4 per million input tokens and $20 per million output tokens, down from Opus 5’s $5/$25. The more interesting price is cached input: $0.20 per million tokens, a 60% reduction. The 1M context window and 128K synchronous output ceiling are unchanged from Opus 5.
RohitAI’s read: this is an upgrade to the economics of sustained work, accompanied by a migration of responsibility into the agent harness. Thinking stays on. Forced tool calls are rejected. Replayed reasoning depends on which model receives it and whether earlier context changed. A successful response can still leave the interface silent or the job unfinished.
For builders, the useful question is whether Opus 5.5 can carry a complete work phase at lower cost without losing the evidence needed to trust the result. Start there, before changing every model identifier in production.
The launch in numbers—and the limits of those numbers
The model reference identifies the API model as claude-opus-5-5, accepting text and images and returning text. Anthropic lists availability through its API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry. Bedrock uses anthropic.claude-opus-5-5; the other listed routes use the unprefixed identifier.
Treat those as documented routes, not confirmation of your account’s quota or region. Consumer Claude and Claude Code plan eligibility also needs its own product-specific check; an API release does not establish every subscription’s rollout.
The coordinated Python v1.8.0, TypeScript v0.128.0, and Go v1.75.0 releases add the model alongside inline-tool definitions and MCP tool-list pinning. These are pieces of the same launch, not separate capability breakthroughs.
Anthropic’s prompting guide reports over 30% faster output-token generation than Opus 5 and says the new model at medium effort matches or exceeds the predecessor at high on coding and knowledge-work evaluations. Those are vendor findings, not measurements reproduced for this article. Faster generation does not automatically shorten database waits, test runs, or human review. The verified evidence here does not support declaring an independent leaderboard winner.
The larger discount is on context you keep using
All figures below are standard USD list prices per million tokens, from Anthropic’s pricing documentation. Cache writes and reads are distinct billing categories; storing a prefix is not charged at the read rate.
Billing category | Opus 5 | Opus 5.5 | Reduction |
|---|---|---|---|
Uncached input | $5.00 | $4.00 | 20% |
Output | $25.00 | $20.00 | 20% |
Five-minute cache write | $6.25 | $5.00 | 20% |
One-hour cache write | $10.00 | $8.00 | 20% |
Cache read | $0.50 | $0.20 | 60% |
Here is a transparent illustration, not a benchmark: across a collection of requests, assume 1M five-minute cache-write tokens, 20M cache-read tokens, and 200,000 output tokens, with no other input category. These are aggregate billing totals, not a single million-token request with extra output squeezed into it.
Same aggregate token mix, standard pricing:
Opus 5: (1 × $6.25) + (20 × $0.50) + (0.2 × $25) = $21.25
Opus 5.5: (1 × $5.00) + (20 × $0.20) + (0.2 × $20) = $13.00
Difference: $8.25, or about 38.8%The example holds cache hits and billed output constant. Cache expiry, new input, tool fees, retries, residency premiums, and changed model behavior would alter the total. It shows why a 20% headline understates the opportunity for some workloads without promising anyone a 38.8% production saving.
A second consequence is less obvious: Sonnet 5 and Opus 5.5 have the same $0.20 cache-read rate. Sonnet’s base input/output rates remain half Opus’s, but the illustrative workload costs $8.50 on Sonnet versus $13 on Opus—a roughly 53% premium, not 100%.
That changes what is worth testing. A team routing every second turn down to Sonnet may find that keeping one capable model on a cache-heavy work phase is competitive once handoff failures and repeated work are counted. This is an architectural hypothesis, not proof that Opus replaces Sonnet. Output-heavy jobs still face a much larger premium.
Recalibrate effort before claiming a cheaper agent
Opus 5.5’s default effort is medium, where Opus 5’s was high. The available settings run from low through medium, high, xhigh, and max. Effort is a behavioral control, not a fixed token allocation or a directly comparable amount of computation across models.
The practical migration is to remove disabled or manually budgeted thinking and set output_config.effort deliberately. Those older thinking configurations return HTTP 400 on Opus 5.5; omitting thinking or selecting adaptive mode is supported. See the breaking-change reference.
Do two comparisons: the defaults a new customer would receive, and the configurations that reach the same acceptance threshold on your work. Identical setting names alone are a poor control. If a cheaper configuration generates more revisions, the revision cost belongs in the comparison.
For an uncached workload with an unchanged input/output mix, 25% more tokens exactly cancels a 20% unit-price reduction: 0.8 × 1.25 = 1. That is break-even arithmetic, not a forecast of token growth. It is a reason to measure complete runs instead of multiplying last month’s bill by 0.8.
Anthropic also warns that the same named effort can produce more thinking per turn, especially at xhigh and max, and that thinking consumes max_tokens even when hidden. Leave output headroom and test truncation. Its effort-calibration guidance also notes that changing top-level effort breaks the prompt cache; supported per-message effort changes are the beta alternative for mid-session adjustments.
A required tool call now needs a workflow check
The release’s tool-choice rules reject tool_choice values any and tool, including on the token-counting endpoint. auto and none remain supported. This is a hard validation change, not merely a model becoming less obedient.
Anthropic recommends automatic selection with strict tool use or structured outputs where appropriate. But strict tool use constrains the arguments of a call. It does not guarantee that the call happens, that its business meaning is correct, or that execution is authorized.
Imagine a support agent required to retrieve an order before proposing a refund. A perfectly shaped optional lookup is not evidence that the order was retrieved. Your application should refuse to advance the workflow until a successful lookup result exists for the relevant order. A prompt saying “always check” remains useful guidance; it is not the acceptance condition.
RohitAI’s rule: if skipping an action would invalidate the result, encode the requirement in application state—not only in the prompt.
Separate three records: the model’s requested action, the executor’s result, and the condition that lets the workflow proceed. This also makes retries easier to reason about. You can determine whether a mandatory operation succeeded without asking the next model turn to reconstruct it from prose.
A fallback can succeed while losing reasoning
Opus 5.5 reasoning is not portable to every Claude model. Anthropic documents the following asymmetric transitions in what’s new. The table concerns thinking blocks, not whether visible messages or external files can be carried forward.
Transition | Previous thinking | Routing implication |
|---|---|---|
Opus 5 → Opus 5.5 | Readable by the new model | An upgrade can retain reasoning. |
Opus 5.5 → Fable 5.1 or Mythos 5.1 on Claude API | Readable by the target | The documented exception is route-specific. |
Opus 5.5 → other models | Incompatible blocks dropped | HTTP success can hide a reasoning reset. |
Fable or Mythos → Opus 5.5 | Not readable by Opus 5.5 | Returning to Opus is not the reverse of escalation. |
Dropped incompatible blocks are not billed. That does not make the transition free: the application may need to recover facts, decisions, or failed approaches that were never recorded outside opaque reasoning. With thinking-binding-controls-2026-08-01, the API exposes drops through input_transformations.
RohitAI’s interpretation: routing should understand work phases, not just price tiers. Escalating a difficult investigation and then immediately downgrading can destroy the continuity that justified escalation. Save explicit evidence—files inspected, decisions, test results, unresolved questions—at a handoff boundary. Do not make correctness depend on reading or preserving private reasoning.
This extends the issue raised in our Grok 4.7 analysis: fitting the history is different from preserving the state needed to continue. Anthropic adds a particularly concrete deployment trap.
For accounts created on or after August 31, 2026 at 00:00 UTC, changing the system prompt, tools, or earlier messages before replayed Opus 5.5 thinking triggers a 400 by default. Older accounts can opt into enforcement. The migration guide describes the account split across the Claude API and cloud platforms.
An old staging account can therefore conceal a bug that appears in a new deployment. Include account cohort in migration fixtures. Store instruction and tool changes as new events rather than rewriting history. A “drop incompatible state” option may keep requests moving, but it should be a deliberate recovery policy, not a way to hide a corrupted session.
Inline tools and MCP pinning reward append-only sessions
Two platform betas announced alongside the model help applications evolve a session without rewriting its start. They are not exclusive Opus 5.5 intelligence features.
With inline-tools-2026-09-15, a mid-conversation tool_addition can carry a full tool_definition. That supports introducing a previously unknown tool or replacing its schema from that point onward. The inline-tools documentation explains how this preserves the earlier cache prefix.
There is an important exception: if the initial tools array has no non-deferred tool, the first by-value definition incurs a full cache miss. Some types, including computer use, cannot yet be defined inline. Declare known tools up front; use additions for genuine changes instead of turning every request into catalog reconstruction.
The mcp-client-2026-09-15 beta records fetched server catalogs as mcp_tool_listing blocks. Replaying those blocks, with the header retained, pins the list. The MCP connector guide also documents explicit pinning in a toolset’s tools field. Inline addition of an MCP toolset requires both beta headers.
Think of a pinned catalog as the session’s interface snapshot. It preserves what the model was offered: names, descriptions, and input schemas. It does not freeze the remote implementation, external data, or authorization. If a server deployment changes what a tool actually does, a pinned schema cannot prove execution stayed equivalent.
The design opportunity is to preserve both histories: what interface the model saw and what the executor actually ran. Together they make a failed long job much easier to replay and explain. Separately, each leaves a blind spot.
Watch for quiet agents and premature finishes
Two regressions can survive an otherwise successful migration. First, progress narration moves from text blocks into thinking blocks, whose text is empty with the default display setting. The progress-display migration guidance recommends display: "updates" with thinking-display-updates-2026-08-18 for progress summaries while reasoning stays hidden. Summarized display is another option, with different presentation behavior.
Keep rendering separate from replay storage. Dispatch content by type; do not assume the first block is the answer. Preserve original assistant blocks unchanged even when the interface displays only a small status message.
Second, Anthropic’s unattended-run guidance describes turns ending with a progress report before the whole job is done. A harness that interprets end_turn as task completion can stop halfway through a migration. Its guidance caps automatic continuations at two or three before review, rather than repeating “keep going” indefinitely.
Suppose an agent updates four of six API handlers and says the remaining two are next. That is a useful status report and an incomplete deliverable. An external checklist should distinguish those states. Our earlier Claude Projects analysis separated producing work from accepting it; this release makes that distinction a concrete runtime requirement.
Accepted coding task =
required changes present
+ relevant checks passed
+ outstanding work explicitly resolved
+ no required execution still running
A model stop signal alone satisfies none of these conditions.Similarly, a refusal can arrive with HTTP 200. Inspect stop reasons and category details rather than treating transport success as useful output. The migration guide’s refusal section adds bio and reasoning_extraction handling; server-side fallback does not retry the latter. Record the outcome and surface a blocker when appropriate.
Computer use and Fast mode need separate route tests
For desktop agents on the Claude API or Google Cloud, replace computer_20251124 with computer_toolset_20260801. Bedrock continues accepting the older tool. The computer-use documentation describes member calls and ordered action batches: dispatch by member name, execute in sequence, and echo toolset_name on results. Renaming the request type without updating the execution loop is insufficient.
For example, a click, typing action, and screenshot can arrive together. Running them concurrently because your generic tool executor supports parallel calls would change their meaning. Test a complete desktop workflow, not merely successful request validation.
Premium Fast mode is a separate, access-gated research preview on the Claude API, priced at $8/$40. Anthropic describes up to 2.5× output throughput using the same weights, not a first-token or full-job speed guarantee. It has separate rate limits; switching speeds causes a cache miss.
Pay for it only after locating the bottleneck. An agent waiting on a slow build might gain little from faster generation. A writing-heavy interactive task may benefit more. Keep standard-speed Opus 5.5’s reported generation improvement separate from this premium option.
The rollout test I would run
The manual protocol work above primarily concerns custom Messages API harnesses. Anthropic’s migration guide says Claude Managed Agents needs no code change beyond updating the model name. That removes integration work, not the need to check output quality and cost.
For a custom harness, build a small, representative migration suite before a canary. Include an interrupted repository task, a long-document job with verifiable source references, a mandatory-tool workflow, and a desktop task if you support one. Run repeated attempts where variability matters and retain failures, not just the best demonstration.
Establish the baseline. Record model, route, SDK version, explicit effort, acceptance criteria, and a fixed starting artifact. Compare Opus 5 against Opus 5.5 at low, medium, and high before experimenting with higher effort.
Exercise continuity deliberately. Resume after interruption, introduce a supported tool change, and force a legitimate model handoff. Confirm task evidence survives and inspect any dropped thinking blocks. Include the account-cohort mismatch case.
Test the executor. Check missing mandatory calls, malformed or failed tool results, and ordered desktop batches. Assert that the application does not mark a task complete merely because the model stopped.
Measure the user’s wait. Track time to useful progress, time to accepted completion, tail latency, continuation count, and review effort. A busier progress display is not necessarily a faster worker.
Rebuild the bill from usage. Separate uncached input, cache writes, cache reads, output, tools, and retries. Count failed jobs in total expenditure; dividing only successful-run bills by successes hides wasted work.
Canary with a rollback boundary. Move a limited workload first. Retain the old route and external checkpoints, and decide how a rollback resumes work without assuming newer thinking blocks remain readable.
Use cost per accepted task as the main economic comparison, alongside acceptance rate and review time. A model that completes more difficult jobs may justify a higher bill; a lower bill accompanied by more unfinished work does not.
Questions worth settling before the switch
Is the million-token context window new?
No. Opus 5 already offered 1M context and 128K synchronous output. The release changes pricing and behavior within that capacity envelope. A large advertised window still needs workload-specific retrieval and accuracy tests.
Can Opus 5.5 produce 300K tokens?
Only through the documented Message Batches extended-output beta using output-300k-2026-03-24. Ordinary synchronous output remains capped at 128K. Batch input/output prices are $2/$10 per million; evaluate its asynchronous service constraints separately.
Must teams leave Opus 5 immediately?
No immediate shutdown is documented. Opus 5 remains available as a legacy model. Opus 5.5’s reference gives an earliest retirement date of September 22, 2027—not a scheduled shutdown on that date. There is room for a measured migration.
Where I would place the first bet
Start with long, repeatable work that revisits substantial context and has an objective acceptance test. That is where cheaper cache reads could matter, where stronger persistence would be valuable, and where failures can be detected instead of argued about.
My prediction is that this pricing will push some teams toward keeping Opus on a whole work phase rather than switching tiers every turn. Whether that wins will depend on measured completion quality and continuity costs. Opus 5.5 makes the experiment worth running. Your harness must make the result worth trusting.