Sonnet 5.5 task costs, cache prices and API changes

Claude Sonnet 5.5 launched with a counterintuitive cost claim: a task could cost less at the same advertised token prices. In its announcement for the September 28 release, Anthropic reports output generation more than 30% faster than Sonnet 5 and task cost up to 30% lower in its tests because fewer tokens are used. Those savings have not been measured by AIOpsSRE. For a coding workflow, the question is whether they last until a reviewer accepts the patch.

Pricing update, October 12, 2026: Anthropic’s current pricing documentation lists standard USD rates of $2 per million input tokens, $10 per million output tokens and $0.10 per million cache-read tokens. The migration guide identifies cache reads as half the Sonnet 5 rate. The September 28 launch announcement still lists $0.20 for cache reads. This update records what the current documentation says; it does not establish when that difference arose.

Anthropic lists its own platform, AWS, Google Cloud and Microsoft Azure, with claude-sonnet-5-5 as the Claude Platform identifier. It positions Sonnet for well-scoped everyday work such as bug fixes and Opus for more open-ended complexity. Before comparing bills, an existing integration has several behavior changes to accommodate.

Thinking settings and forced tool calls change

The Sonnet 5.5 migration guide says thinking.type: disabled now causes an error. To keep up-front thinking off, use between_tools at low, medium or high effort. Thinking blocks may still appear in responses, so a client that assumes the first block is answer text needs to inspect block types instead. Otherwise the comparison starts with a parsing failure rather than a fair test of the new model.

Forced tool choice using any or tool is rejected too. A workflow that requires a tool invocation cannot migrate merely by renaming its model. With auto, the model may answer without calling a tool, and application code must recognize that this is not evidence that the intended lookup or action occurred. That changes the workflow’s completion check as well as its request format.

What a completed fix costs

Consider a hypothetical job that fixes recurring configuration errors. Give each candidate model the same failing configuration, then submit its patch to the usual validation and human review. One model might use fewer tokens on its first proposal but need another attempt before the fix is usable. Keeping the correction cycle in view reveals whether the economical answer also produces an economical completed job.

Include rejected and incomplete attempts when calculating cost per accepted result. Hold prompts, tool permissions and acceptance tests fixed for the initial comparison, and report completed jobs beside total spend and review time. A smaller bill can otherwise describe less work accomplished rather than greater efficiency. The task-level token-cost guide explains how to carry retries into this accounting.

For the configuration-fix workflow, migration therefore has two parts. The client must accept the new thinking and tool-call behavior, and its completed patches must still pass the existing validation. Comparing effort settings after those integration changes shows whether fewer tokens also mean less spending on fixes the reviewer can accept.