A model can write a query quickly and still make an analyst’s afternoon longer. A plausible join, an unnoticed duplicate and a confident explanation are enough. That is why the interesting part of the latest Sonnet announcement is the unit of measurement: the completed task.
What Anthropic announced on September 28
Anthropic introduced Claude Sonnet 5.5 on September 28, 2026. The company says it generates responses more than 30% faster and can reduce cost per task by up to 30%, while keeping Sonnet 5’s token prices: $2 per million input tokens, $10 per million output tokens and $0.20 per million cache-read tokens. The claimed savings come from greater token efficiency, rather than a lower published token rate. Anthropic positions it for everyday, relatively scoped work; its more demanding, open-ended work remains a different evaluation question. These are the company’s claims, not results from an independent test conducted for this article. Read Anthropic’s announcement.
A useful result has to survive inspection
My interpretation is that this makes the case for a better purchasing metric. Token spend tells you what the API charged. It does not tell you whether someone can use the output.
For a reporting task, acceptance might mean that the totals reconcile, the date range is explicit and every claim points to a source table. For an ETL change, it might mean that the transformation passes existing checks and preserves the intended grain. Those definitions should be written before running a comparison. Otherwise the most fluent response tends to win, even when it quietly answers a different question.
Consider a hypothetical weekly revenue summary. One model produces a polished draft in a single attempt. Another produces a rougher draft that needs fewer factual corrections. The second can be cheaper overall, despite a larger API bill. Human review time belongs in the calculation.
I would record four things for each attempt: API spend, elapsed time, reviewer minutes and whether the result passed the acceptance criteria. Divide total effort by accepted outputs. Keep failed attempts in the denominator of the cost calculation; deleting them creates an attractive but misleading report.
Build the test around awkward cases
A small evaluation set should include the work that normally causes rework. Give it a join where both tables have repeated keys. Include a time-zone boundary, missing values and a metric whose business definition differs from its column name. Ask for an explanation of uncertainty when a source is incomplete.
Use the same inputs and instructions for each model. Review outputs without model names where practical. Keep the initial task separate from any later repair prompts so the number of retries remains visible.
For generated SQL, inspect the execution plan and run against a limited, non-sensitive test dataset. A query that executes is not necessarily a query that answers the question. Check row counts before and after joins, aggregation grain and exclusions.
Where the update could earn its place
The sensible first experiment is a narrow workflow with a stable definition of success: drafting a data dictionary, explaining a tested query, or preparing a report from validated figures. Expand only after the evidence supports it.
The same evaluation discipline applies to GPT‑6.1 Sol’s pricing and routing question. Better model economics become valuable when they reduce the cost of work you are willing to accept. A faster first draft is only the beginning.
News analysis based on announcements published September 28–29, 2026. Workflow examples and evaluation recommendations are the author’s analysis; no hands-on model benchmark is claimed.