Models 3 min readChoose a model
Your model got cheaper. Did your finished answer?
A lower token price is useful. The comparison changes when you count retries, checking and the answers you can actually accept.
The short answer
Not necessarily. Count the cost of all attempts that produced the accepted work. Keep quality, waiting and human review visible alongside the model bill.
On this page
The invoice is only part of the answer
Imagine a support team comparing two AI models. One produces a cheaper first draft. Some replies need another attempt; others take longer for a person to correct. The model bill falls while the support queue grows.
This is a fictional example, not a finding about a named product. It separates two questions: did generation get cheaper, and did producing an acceptable reply get cheaper? Decide what acceptable means before comparing the answers.
What changed
Anthropic’s September 22 release of Claude Opus 5.5 emphasizes efficiency alongside capability. The company attributes lower typical running costs to pricing and token usage. It also cautions that benchmark margins can be a less reliable guide to differences in real work. These are developer claims, not measurements by Curious Compute. [1]
The decision this changes
Our interpretation: compare completed jobs. For the support team, that means a reply that is accurate, follows company policy and is ready to send after required review.
Count spending on rejected attempts too. Report accepted replies separately from all attempted replies. Otherwise a system can look inexpensive because it leaves difficult cases unfinished. Keep money and review time as separate measures unless you have a defensible way to price that time.
For builders Methods, implementation details and source evidence
Make the comparison repeatable
Keep questions, documents, tools and acceptance rules fixed. Record the exact model version and effort setting—the amount of processing the model is allowed to use. Comparing defaults answers a different question from comparing equal budgets.
Record model charges, tool charges, attempts, review minutes and accepted results. Divide all model and tool charges, including failed attempts, by accepted results. If nothing passes, report no accepted result; do not turn that into a zero-cost success. Keep failed cases available for inspection.
What we don’t know
We have not evaluated Opus 5.5 or compared its cost with another product. Vendor benchmarks do not establish performance on your documents. Prices and availability may change. A small test also cannot establish rare-failure rates.
Try this Open the full exercise and its limits
Try this
Write ten made-up support questions, including two that cannot be answered from the supplied documents. Set a pass condition for each before running either model. Ask a reviewer to assess replies without knowing which model produced them.
Record cost, time, rework and acceptance for every case. Inspect where a cheaper draft becomes a more expensive accepted reply. This is a proposed pilot, not a completed benchmark or purchasing recommendation.
What to watch next
For the next cheaper-model announcement, look for four things: workload, acceptance rule, attempts and human work excluded from the price. Which missing detail could reverse your team’s decision?
One AI decision, made clearer.
Get a short email with one visual explanation and one practical check. Follow the full article when you want the evidence.
Send me the briefingOpens our email signup page. Confirm by email to receive the briefing. Free; unsubscribe anytime.
Preview a short email →Follow the evidence
Sources & further reading
- Anthropic: Introducing Claude Opus 5.5 ↗
September 22, 2026. Vendor announcement; no results independently reproduced here. Checked September 27, 2026.
Back to cited passage ↑
A correction or a different perspective? Write to us.