Claude Opus 5.5: Lower Prices, A Migration Worth Testing
Claude Opus 5.5 arrived on 22 September 2026. Anthropic reports stronger coding and professional work, with typical workload costs 40% below Opus 5 at default settings. That is a result from the provider's tests, not a saving we have measured in customer systems. The useful question for a team already using Claude is whether its own completed work gets better, cheaper or easier to review. Official announcement.
Our recommendation is a bounded comparison on one existing workflow. Start with the bill, check the integration, then inspect the deliverable. This article is a source review and proposed evaluation method, not a hands-on benchmark. Sources were checked on 22 September 2026.
What the new price actually buys
For Opus 5.5, uncached input costs $4, output $20 and cache reads $0.20 per million tokens. The following are standard Claude API prices in USD per million tokens. They are separate from Claude subscriptions and our services. Anthropic pricing.
| Token category | Opus 5 | Opus 5.5 |
| --- | --- | --- |
| Uncached input | $5 | $4 |
| Output | $25 | $20 |
| Cache write, five minutes | $6.25 | $5 |
| Cache read | $0.50 | $0.20 |
For an illustrative run with 100,000 uncached input tokens and 10,000 billed output tokens, the token charge falls from $0.75 to $0.60. That is a 20% reduction for an identical token mix. It excludes cache operations, tools, retries, taxes and other pricing modes. Count billed output, including thinking, rather than only the words a person sees.
The announcement's 40% figure also reflects how much work the model does to finish a task. Your mix of cache hits, output, effort settings and repeated attempts will differ. Record the complete bill for each accepted result before treating either percentage as a budget forecast.
What teams can try it on
The model specification lists API ID `claude-opus-5-5`, a one-million-token context window and a 128,000-token output limit. Anthropic positions it for sustained coding and knowledge work.
Our first candidates would be work with a clear reviewable output: a change spanning several modules, a comparison of conflicting documents, or a report whose figures must trace to source material. Large context gives you room to supply evidence. It does not establish that the model used every relevant passage or respected every constraint.
Choose a task that currently needs rework, and write down the failure you want the upgrade to remove. “Produces a convincing report” is weak. “Every number resolves to a supplied source, and missing figures stay missing” gives the reviewer something to check.
Check the API contract before changing traffic
The official changes guide identifies compatibility changes worth checking in your own client:
Thinking cannot be disabled; the default effort is now `medium`.
Forced `tool_choice` modes `any` and `tool` are rejected.
Replayed thinking depends on the model and conversation history.
The older computer-use tool is rejected on the Claude API and Google Cloud; Bedrock differs.
There is also a response-display change: progress between tool calls moves into thinking blocks and is hidden by default. Follow the migration guide for the supported display settings and platform-specific changes.
Turn those points into integration checks: an ordinary request, a tool round trip, a resumed conversation, a model switch, and a visible progress update. Inspect what your application actually sends through any compatibility layer. A successful HTTP response is only the start: your parser, user interface and saved result must still work.
A small evaluation your team can review
Use this as an initial screen, then expand it before broad rollout. These are proposed steps, not results from an Opus 5.5 trial.
1. Select ten authorised or synthetic examples from one workflow. Include a missing input, contradictory evidence and a tool failure. Keep expected results separate from the prompt.
2. Run the current setup and candidate with the same inputs, tools and acceptance rules. Set effort explicitly and record it; matching defaults is not a controlled comparison.
3. Have a reviewer check correctness, source support and scope. Record rework time, elapsed time, full token usage and failed attempts, including runs you cannot accept.
4. Divide total evaluation cost by accepted results. Keep reviewer time visible alongside that number. A cheaper answer that needs extensive repair may be a worse business choice.
5. Release a small portion of eligible work only if the result meets the agreed bar. Keep a rollback path and check how resumed conversations behave when the model changes.
Our acceptance-criteria guide can help turn a vague trial into a decision. A useful outcome may be “use Opus 5.5 for document synthesis, retain the current route for routine extraction”. There is no requirement to move everything together.
Make the next step concrete
Bring one input, the expected deliverable and the part that currently needs correction. Discuss a bounded workflow evaluation. We can scope the integration checks and acceptance evidence before a wider migration.