Claude Opus 5.5: cheaper agents, with an API migration to plan

September 23, 2026 update: Opus 5.5

Anthropic released Opus 5.5 on September 22. Its practical appeal is lower-cost complex agent work. The company reports roughly 40% savings on typical workloads at default settings. That is a workload estimate, not a blanket price reduction or a guarantee for your pipeline.

The model documentation lists claude-opus-5-5, a 1M context window and 128k maximum output. Base rates are $4 per million input tokens and $20 per million output tokens, 20% below Opus 5. Cache reads cost $0.20 per million tokens; five-minute writes cost $5 and one-hour writes $8. These are API rates, separate from subscription allowances.

Where an existing integration can break

The migration guide removes disabled thinking and the old enabled setting with a manual budget. Use effort to control depth; the default is now medium. Forced tool_choice: any/tool fails: switch to auto with strict schemas. Strict validates arguments; it does not guarantee that an action happens. Your application must check completion.

The API changes also bind thinking blocks to conversation history. For accounts created from August 31, 2026, editing earlier messages, tools or the system prompt and replaying those blocks can fail. Test custom compaction and model fallbacks. On the Claude API and Google Cloud, the old computer_20251124 tool gives way to a toolset; Bedrock compatibility differs. Narration between tool calls moves into thinking blocks and can disappear from the UI with the default display setting.

How I would roll it out

Keep the cheaper layer classifying email and support tickets in n8n or Make. Give Opus 5.5 a small escalation sample first: conflicting invoices, incomplete CRM evidence or a bug spanning several parts of a repository. Hold inputs and acceptance criteria constant, with a fixed budget.

Measure cost per approved result, corrections and human review time. Include cases where the agent skips a tool, refuses a task or needs a fallback. CRM writes, outgoing email and code deployment still need their own approval gate. Lower token prices are no reason to expand permissions.

Original article: Claude Opus 5

The following section preserves the Opus 5 launch context. Its prices and options for disabling thinking describe version 5; use the update above for version 5.5.

Claude Opus 5 is the kind of release where two automatic reactions are easy and mostly wrong. One is: put it everywhere. The other is: just another row in the model table.

The practical reading is more useful: Opus 5 is a stronger working model for complex agentic work, coding, documents, and long context. It is not a cheap filter for every email, but it may become the better default for tasks where you previously used Opus 4.8 or escalated all the way to Fable 5.

I verified the hard facts primarily from Anthropic's docs and release notes. The important part is not a launch headline. It is the API contract: model ID, pricing, context window, output limit, effort, thinking, and migration behavior.

What shipped

Anthropic lists Claude Opus 5 with the API ID claude-opus-5. It is available through the Claude API, Amazon Bedrock, Claude on Google Cloud, and Microsoft Foundry. In Anthropic's model overview, it sits between Fable 5 and Sonnet 5: Fable 5 remains the highest public capability for long-running agents, while Opus 5 is positioned for complex agentic coding and enterprise work.

The useful specs are straightforward:

1M token context window as both default and maximum,
128k max output tokens in the synchronous Messages API,
adaptive thinking on by default,
$5 per million input tokens and $25 per million output tokens, the same pricing tier as Opus 4.8.

Fast mode is in research preview for Opus 5 on the Claude API only. It costs $10 per million input tokens and $50 per million output tokens. That is not free speed. It is a latency tradeoff.

Why this is more than a model-name swap

On Opus 4.8, thinking was off unless you explicitly enabled it. On Opus 5, thinking is on by default and depth is controlled through effort. That is a small integration detail and a large operations detail.

If you run automations in n8n, Make, or a custom agent runtime, you cannot just change the model string. You need to revisit max_tokens, because thinking and the final answer share the same hard output limit. You need to choose effort deliberately, because low, medium, high, xhigh, and max are different cost and latency modes.

There is also a breaking change: on Opus 5, disabling thinking is accepted only at effort high or below. Disabling thinking at xhigh or max returns a 400 error. That is exactly the sort of detail that can break a migration that looked fine in a branch.

Where I would use it

The first obvious candidate is a long-running coding agent. Not a typo fix, but work like: inspect a larger repository, understand the architecture, plan a change, edit multiple files, run tests, read failures, and iterate. Opus 5 is interesting here because Anthropic calls out improvements in long-horizon agentic work, code review, bug finding, and completing multi-step tasks without placeholders.

The second candidate is document analysis. Due diligence packs, tenders, internal policies, contracts, security audits, or vendor release notes. A 1M context window is not a plan by itself. The plan is to define what to extract, how to mark uncertainty, where citations are required, when to hand off to a person, and what the finished artifact should look like.

The third candidate is an enterprise research agent. Market monitoring, competitors, regulatory changes, product updates, or pricing pages. I would not let Opus 5 do unlimited research freestyle. I would place it after a cheaper collection layer: a lower-cost model clusters sources, Opus 5 synthesizes them into a memo and marks what still needs primary-source verification.

The fourth candidate is workflow that combines text, vision, and tools. Anthropic highlights stronger vision, document, chart, and UI/frontend understanding. In practice: an agent builds a page, Playwright captures a screenshot, the model reviews layout, finds overlap, and proposes a fix. That is more interesting than another component-generation demo.

Where I would not use it

I would not make Opus 5 the default for bulk support-ticket classification, simple CRM enrichment, routine invoice extraction, or first drafts of short emails. Sonnet, Haiku, a cheaper open model, or rules will often win there.

Not because Opus 5 cannot do the work. It can. The issue is economics. If a workflow runs thousands of times a day and each individual mistake is low-impact, a stronger model can become an expensive way to do work a cheaper layer already handles. Opus 5 should be used where the cost of a bad decision, lost context, or incomplete agent run exceeds the token bill.

What to change in the router

I would place Opus 5 as a specialist between Sonnet 5 and Fable 5.

The cheap layer handles volume: tagging, routing, normalization, simple JSON, basic extraction, and quick replies. The middle layer handles everyday knowledge work: longer support replies, CRM enrichment, content pipelines, document summaries, and input checks. Opus 5 belongs in the layer where complexity, risk, and run length start to matter.

A practical router could look like this:

low or medium effort for first serious analysis,
high for normal production agent work,
xhigh or max only for tasks with clear goals, review, and limits,
Fast mode only where latency materially changes value,
fallbacks for refusals or sensitive categories,
audit logs with model, effort, tokens, escalation reason, and review result.

Less romantic than "we use the best model". Much healthier in production.

Watch your old prompts

Anthropic's prompting guidance says Opus 5 verifies its own work more often and delegates to subagents more readily in multi-agent frameworks. That is good if you want long agent runs. It is less good if an old prompt already says three times: always verify everything, call another agent, and run a final check.

After migrating to Opus 5, I would evaluate not only answer quality, but also run length, tool calls, subagent count, latency, and cost per completed task. A smarter model can be worse for a specific workflow if the prompt makes it overwork.

Migration minimum:

set effort explicitly,
recalculate max_tokens,
remove redundant verification instructions,
test refusal and fallback paths,
compare cost per finished task against Opus 4.8, Sonnet 5, and Fable 5.

My read

Opus 5 is a good candidate for the new default in harder agentic work. Not everything. Tasks where you need long context, tools, iteration, self-checking, and a finished result instead of a draft with placeholders.

The biggest shift is not only "higher intelligence at Opus 4.8 pricing". The real shift is that Anthropic is making capability more controllable: effort, thinking, caching, fallbacks, Fast mode. That is the right direction for company AI stacks. Not one best model, but a managed system that knows when to classify cheaply, when to think harder, and when to stop for human review.

Sources: Anthropic Claude Platform release notes, What's new in Claude Opus 5, models overview, pricing, prompting Claude Opus 5, model deprecations, AWS Claude Opus 5 now available on AWS, and The Verge Anthropic releases Opus 5.