# Opus 5.5 made token efficiency a task-accounting question

How to evaluate Opus 5.5 token efficiency using equivalent accepted tasks, including retries, validation and changes in work scope.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-09-22
Original announcement: https://www.anthropic.com/claude-opus-5-5
Canonical URL: https://retrivium.ai/retrospectives/opus55-token-efficiency-task-accounting/

## Efficiency moved beyond the token price

[Opus 5's release record dates to July 24, 2026](https://platform.claude.com/docs/en/models/opus-5/overview). The [Fable 5.1 and Mythos 5.1 release followed on September 1](https://www.anthropic.com/claude-fable-and-mythos-5-1). On [September 22, Anthropic introduced Opus 5.5](https://www.anthropic.com/claude-opus-5-5) with claims about both pricing and work performed per task. These are different levers. A lower unit price changes the bill for an unchanged quantity of work; a more direct solution can change the quantity itself. Their combined effect cannot be inferred from either lever in isolation.

## A short run can still be an incomplete run

An illustrative code migration ends after the main transformation but omits a required compatibility case. Its token count is low, yet it has not produced the accepted deliverable. Another run spends more tokens identifying the compatibility requirement and completes the migration correctly. Ranking these solely by generated length would reward the wrong outcome. Task efficiency therefore needs a stable acceptance boundary, including meaningful validation. The definition should be established before comparing runs so that a convenient early stopping point does not quietly become success.

## Retries belong to the same outcome

A failed attempt followed by a successful retry consumes resources that belong to the eventual resolution. Counting only the final successful call hides this overhead. Likewise, manual repair can make an apparently inexpensive result costly to finish. A reviewable accounting record links attempts and repairs to the accepted artifact without pretending that human effort has an automatically known monetary value. The purpose is attribution: distinguish resources used to obtain the result from resources visible in its last response.

## A fixture with a preserved contract

Consider an illustrative library migration with a fixed public interface and an established regression suite. For each candidate run, retain the patch, validation outcome, tool interactions and available usage records. The acceptance rule requires the same behavior across candidates. A cheaper run that changes the interface is then visible as a scope change rather than an efficiency gain. No local result or saving is asserted here. The fixture explains how fewer steps could become meaningful evidence while preventing brevity from substituting for the original requirement.

## The release suggests a measurement question

The September announcement provides a reason to test task-level efficiency, not a universal reduction that can be transferred to every workload. Different repositories, tools and review burdens can alter the outcome. The useful retrospective lesson is to keep unit rates, resource quantities and accepted work separate until the final comparison. This allows an evaluator to explain whether an improvement came from a cheaper token, a better plan, fewer failed attempts or a narrower task. Only the first three can support an equivalent-work efficiency claim.

## Related reading

- [Task-level resource accounting](/journal/inference-economics/)
- [Equivalent acceptance criteria](/journal/inference-benchmark-method/)