Verdict: partly held. The task-specific positioning held up, but Haiku’s arrival narrowed Sonnet’s role in high-volume work and real-world savings look more dependent on clean prompts and environments than the launch framing implied.
Original analysis: Anthropic’s Sonnet 5.5: 30% faster, 30% cheaper—but only for tightly scoped tasks, published 2026-09-29 (6 weeks ago).
What we said
New Runtime argued that Sonnet 5.5’s claimed 30% speed and cost gains could make it a new baseline for cost-sensitive, high-throughput tasks, provided token efficiency translated into measured savings without unacceptable quality loss. It urged builders to benchmark bounded workflows against their current model, while noting that independent evidence about broader performance and complex reasoning was still lacking.
What happened since
- Anthropic’s October 2 model summary describes Sonnet 5.5 as a faster, lower-cost complement to Opus 5.5, strongest at well-scoped everyday tasks, bug fixes, and polished documents, slides, and spreadsheets. That backs the original task-specific framing, but it remains Anthropic’s characterization rather than independent confirmation of a general cost/performance advantage. [1]
- On October 7, Anthropic introduced Haiku 5.5 for high-volume, cost-sensitive, repetitive tasks including summaries, database queries, and classification. The same announcement says Sonnet 5.5 cache-read pricing was halved, making it about 20% cheaper on most agentic work; together, these changes leave Sonnet useful but no longer the obvious cheapest choice across repetitive workloads. [2]
- A November study on a coding task with a stale test command found Sonnet 5.5 needed about two additional tool calls per run, roughly one-third more than with a corrected command. For teams budgeting by task, that makes prompt and environment hygiene a material cost-control measure alongside model choice, and complicates any expectation that model-level speed or token reductions will flow straight through to savings. [3]
What we missed
The earlier note treated Sonnet’s high-throughput position as a potential baseline and focused its proposed experiment on model-level token use, latency, and quality. It did not anticipate a cheaper, faster Haiku option carving out repetitive tasks, or show how stale workflow instructions can raise realized tool-call cost. Those developments make the right unit of comparison the whole task, including context and tool use, not just model pricing or speed. The available developments still do not establish independent benchmarks or realized savings across production workloads.
Forecast check
- Teams processing 10M tokens/month will see a $1,200 annual savings by switching 50% of their bounded tasks to Sonnet 5.5, assuming a 30% token reduction and no quality degradation. (70%, due 2027-03-29): unclear. The forecast is due March 29, 2027, and the developments so far do not report monthly token volumes, the assumed switch rate, or measured annual savings.
- Independent benchmarks (e.g., MLPerf or LLM-Bench) will confirm a 20-30% latency improvement for Sonnet 5.5 on document-generation tasks within the next quarter. (80%, due 2026-12-29): unclear. The forecast is due December 29, 2026. The company summary supports Sonnet’s positioning, while the November study concerns extra tool calls from stale instructions; neither establishes an independent 20–30% latency gain on document-generation tasks.
- OpenAI will not lower GPT-4o mini pricing in response to Sonnet 5.5, as its $0.15/$0.60 per million token model remains competitively priced for ultra-low-cost use cases. (60%, due 2027-09-29): unclear. The forecast is due September 29, 2027. Nothing in the developments so far says whether OpenAI changes GPT-4o mini pricing.
What to do now
Builders should keep the original controlled-benchmark discipline, but compare the best-fit model for each workload rather than treating Sonnet 5.5 as the default for all bounded tasks. Test Haiku on repetitive, cost-sensitive work and Sonnet on broader everyday tasks, while retaining a stronger model where judgment or quality warrants it. Measure end-to-end cost, latency, and output quality on representative tasks, including cache behavior and tool calls; audit test commands, prompts, and other environment instructions before drawing conclusions from a model comparison. A lower quoted or nominal cost is not a saving if a task needs extra calls or rework, and the company’s claims should not substitute for an independent result.
Next check
The next useful check is an independent, controlled comparison of Haiku 5.5 and Sonnet 5.5 on representative production workloads, measuring end-to-end cost, latency, and quality with clean and stale workflow instructions.