Sonnet follows the Opus update
Anthropic released Claude Sonnet 5.5 on September 28, following Opus 5.5 on September 22. The announcement focuses on well-defined coding and knowledge work, including finished documents, spreadsheets, slides, and design tasks.
Anthropic reports a speed improvement exceeding 30% and cost reductions of up to 30% for most work. These are vendor-reported results under its test conditions, not a measured improvement on this website or a promise for every prompt. Keep that qualification when sharing the news.
The release positions Opus 5.5 for more demanding judgment and Sonnet for everyday work. It describes Haiku 5.5 as forthcoming. As of this September 30 check, that announcement is not evidence that Haiku 5.5 has already launched.
The practical API details
The Sonnet 5.5 overview gives the model ID claude-sonnet-5-5, a one-million-token context window, a maximum output of 128,000 tokens, and adaptive thinking with high effort as the default. Standard native API pricing is $2 per million input tokens and $10 output, with cache hits at $0.20.
The platform documentation lists Claude's own platform and cloud-provider availability. An API model being available does not establish that every consumer plan, region, or managed workspace has identical access. Check the product you actually use, not only the API catalog.
The Claude price guide separates normal input from cache writes and reads. The Pro/Max guide explains the subscription side.
Make the comparison fit a real workflow
For a site like vsike, an evaluation should include more than a fluent paragraph. Ask the model to draft from supplied primary sources, preserve canonical URLs, update the directory, and check that a price table can be read on a narrow screen. These are suggested test tasks, not results from an evaluation already conducted.
Prepare the review checklist before either model starts. A source must support its claim, a release date must match the event, and hypothetical token arithmetic must not be described as an actual invoice. Both candidates should face those same checks.
For a coding comparison, start from an identical fixture or saved revision. Running the second model after the first has already repaired the code would make the second task easier and distort the conclusion.
Count the revision loop
Time to the first answer is only one part of the work. Record how many follow-ups were needed, whether the result passed the acceptance rules, and how long a person spent repairing it. Keep the reasoning setting and supplied context in the log.
A useful trial has two groups: routine, well-specified work and ambiguous work with competing requirements. This prevents a success on straightforward tasks from being generalized to everything. It also helps identify where retaining a stronger escalation model is worth the cost.
Switch deliberately
Adopt a new default only after the routine set is consistently acceptable. Keep important failures as regression cases and rerun them when settings change. A release can be a good reason to test; it is not itself the test result.
Read our Opus 5.5 launch note for the earlier family update and GPT-6.1 Sol guide for the parallel OpenAI release. The same quality-first review method can be applied to both without declaring a universal winner.