Opus 5.5: Cheaper Tokens, But Cheaper Tasks?

We do not set out to buy tokens. We set out to finish a migration, ship a feature or get a stubborn task over the line. That is why Anthropic’s Opus 5.5 price change matters—but only once it reaches the whole loop of work.

Anthropic says the model is intended as a daily driver for coding and agentic work. Its published prices are lower; the bill for a completed task can still rise when the session runs long, repeats work or produces more output than the job needs.

A long coding session is not one clean transaction. It is a sequence of conversation, files, tool calls, checks and next moves. Every extra loop can add fresh input, output or thinking to the work.

That does not cancel the price cut. It changes the claim we can make about it. A cheaper model may make the same task less expensive; it does not make every task inexpensive by default.

Anthropic’s model documentation lists Opus 5.5 at $4 per million input tokens and $20 per million output tokens, with cache reads at $0.20. Anthropic says input and output are 20% cheaper than Opus 5, while cache reads are 60% cheaper.

Those are published prices, not a completed-task guarantee. The unit price is one part of the receipt; the number of turns, the cache share, the output produced and the effort used remain part of what the task costs.

Anthropic says Opus 5.5 performs at the level of Fable 5.1 and is around 30% faster and 40% cheaper per task than Opus 5. That is meaningful launch positioning, but it remains supplier-published performance language.

Anthropic’s own cost material supplies the important limit: codebases, prompts, habits and task shapes differ. The useful question is not whether the headline can be repeated; it is whether the same work produces a better receipt in our own environment.

Two things changed: the price, and how much work the model does.

Anthropic

Anthropic’s case is not simply that Opus 5.5 costs less per token. It is that the model can do enough useful work to be chosen more often for demanding coding and knowledge tasks.

That distinction matters. A model can be cheaper at the meter and still be costly in practice if a task takes more correction, more supervision or more turns to complete. Conversely, a higher-priced route can sometimes finish cleaner. We need the completed result and its receipt together.

Claude Code works through a loop: it reads the conversation and files, calls a tool, checks what happened, then decides what to do next. Each additional turn can bring more context and more output into the work.

Anthropic says adaptive thinking is always on for Opus 5.5, with medium as the default effort setting. Compaction can summarise older turns while retaining recent context. Neither feature removes the need to notice when a task is looping without improving the result.

The practical levers are ordinary: how many turns the task takes, how much context is reused, how much output or thinking is produced, and which model price applies.

Choose a real task with a result we can check: a bug fix, a migration step or a bounded feature. Run it under comparable conditions, then retain the outcome alongside the path it took.

The comparison does not need a universal benchmark. It needs enough detail to show whether fewer unit-price dollars were outweighed by more turns, retries, output or supervision.

The saving is not in the price cut alone. It appears when the same work reaches a checked result with less unnecessary looping.

Based on Anthropic’s published pricing and task-cost guidance

Anthropic has made a concrete price move. Its published API rates are lower, and its daily-driver ambition is clear. That is a useful change for teams doing long-running coding and knowledge work.

The stronger reading is also the more cautious one: the price cut creates the opportunity, while workflow shape decides whether it becomes a lower completed-task cost. We should measure the work we actually do, not inherit a headline as a conclusion.