What the announcement establishes
Anthropic attributes the saving to needing fewer tokens for the work, and also reports faster output generation. Those are vendor-reported findings; LOCATEWISE has not reproduced them. They do not establish an identical saving for every prompt, effort setting or customer workload. An API efficiency claim also does not by itself announce a reduction in a consumer subscription fee. [1]
Keep three questions separate: what each unit costs, how many units a task consumes, and whether the result passes your acceptance check. That last question should be decided before looking at which model produced the answer.
A fictional example of the wrong saving
The following numbers are invented to demonstrate the arithmetic. They are not Sonnet results, quotations or forecasts. Assume each of 100 tasks gets one attempt and the stated cost covers that attempt only.
| Measure | Workflow A | Workflow B |
|---|---|---|
| Cost per attempt | $0.012 | $0.009 |
| Cost of 100 attempts | $1.20 | $0.90 |
| Accepted results | 80 | 50 |
| Cost per accepted result | $0.015 | $0.018 |
B spends less overall but costs more per accepted result: $0.90 divided by 50, compared with $1.20 divided by 80. Rejected outputs still consumed money. Neither column includes staff time, extra attempts, platform fees or tax; adding these would create a fuller operating-cost comparison.
Run a comparison you can use
Our suggested evaluation starts with a fixed set of tasks you already understand. Keep the files, instructions and required output format the same. Write down what makes an answer acceptable: correct totals in a report, valid citations in a brief, or a working behavior in a code change.
- Record total billed usage across initial attempts and retries.
- Track accepted results separately from plausible-looking drafts.
- Time the whole task, including review and repair, rather than output generation alone.
- Record model version and effort setting so a later run has a meaningful comparison.
- Keep difficult cases in the set; do not quietly remove failures from the denominator.
This is a proposed method, not a completed benchmark. If the results vary by task type, routing routine jobs and ambiguous jobs differently may be a better experiment than switching every job at once.
For API users, test the migration as well
Anthropic’s migration guide documents parameter changes as well as a model-name change. For example, Sonnet 5.5 uses between_tools at supported effort levels to disable up-front thinking; the previous disabled setting is rejected. Existing integrations should follow the guide for their starting model and platform. We did not run migration requests against the API. [2]
The launch makes Sonnet 5.5 a candidate for evaluation. Your own accepted-output cost, with failures and review included, is the evidence that would justify a workflow change.
Read the underlying guidance.
- Introducing Claude Sonnet 5.5Anthropic · checked 2026-10-02. 28 September launch; vendor-reported task-cost/speed claims; unchanged input/output token prices. Not independent benchmark evidence.
- Migrating to Claude Sonnet 5.5Anthropic · checked 2026-10-02. Migration parameters and between_tools/disabled distinction; documentation read, API not exercised.
Researched and written with AI. The producing AI checked source attribution, scope and calculations where present. A separate AI reviewer independently read the primary sources and reviewed the English text on 2 October 2026. Human English and specialist review have not been completed. human English/technical review; controlled Sonnet 5 vs 5.5 workload evaluation, actual billing evidence and API migration execution.
