Anthropic introduced Claude Opus 5.5 on September 22, describing a model that reduced typical workload costs by 40% against Opus 5 at default settings. Announced prices were $4 per million input tokens and $20 per million output tokens. Cache reads were priced at $0.20 per million tokens, down from $0.50 for Opus 5. Anthropic also reported output generation more than 30% faster.

These are company measurements and launch prices, not a promise that every application’s bill falls by the headline percentage. The interesting engineering detail is that different parts of a session received different reductions. A workflow that repeatedly reads a stable codebase can have a different cost profile from one that produces long, mostly new answers.

Read the bill by category

Separate uncached input, cached input, cache writes, and generated output before estimating savings. A single average token rate conceals the effect of reuse. It also makes it difficult to notice when a harmless prompt change invalidates a cached prefix and increases the cost of every subsequent request.

For a hypothetical repository assistant, keep stable project instructions and commonly used context consistent where the application permits it. Put frequently changing information in the part of the request designed to change. Then inspect actual usage records rather than assuming that a repeated document automatically qualifies for a cache discount.

The model’s effort setting is another variable. A more capable default can reduce the need for maximum effort, but changing the setting and the model simultaneously makes a comparison harder to interpret. First compare the existing configuration with its closest replacement. Test alternative settings in a second pass.

Speed should shorten the whole job

Faster output helps interactive work, but a repository migration also spends time fetching dependencies, running builds, and waiting for review. Measure the complete path from assignment to accepted change. Otherwise, a large improvement in token generation can look like a large productivity gain that the team never experiences.

The migration decision should include a small set of difficult historical failures. Cheaper successful tasks are attractive; cheaper repetitions of the same mistakes are less useful. Keep the previous model available until the new configuration handles those cases acceptably.

Opus 5.5’s announcement therefore gives teams a reason to revisit both model selection and request design. The strongest savings may come from combining a better model with a workflow that reuses context deliberately and measures the cost of finished work.

Have a correction or a useful perspective?
Get in touch with the publication.