Sonnet 5.5 keeps token prices steady. Check what changes in your app.

Claude Sonnet 5.5 launched on 28 September 2026, with availability recorded that day across the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud and Microsoft Foundry. For teams using Sonnet, the useful question is whether it can finish their work more efficiently without breaking the application around it. Anthropic release notes

Our recommendation is to test a contained workflow before changing the production default.

The token rate has not fallen

Sonnet 5.5 and Sonnet 5 have the same published base API rates: US$2 per million input tokens and US$10 per million output tokens. Opus 5.5 is listed at US$4 and US$20 respectively. These are token prices, not subscription fees or the cost of a finished task. Anthropic pricing

Standard base rates checked on 29 September 2026. Caching, batch processing, geography modifiers and tool charges are outside this comparison. Check your provider's applicable pricing before budgeting.

Anthropic reports that Sonnet 5.5 uses fewer tokens for equivalent work and can cost up to 30% less per task in its testing. It also reports output generation more than 30% faster than Sonnet 5. Those are vendor-reported results, not Mimir measurements or a promise for your workload. Launch announcement

This distinction matters when estimating savings. An unchanged token rate can still produce a smaller bill if the model needs fewer tokens. It can also produce disappointing savings if retries, longer answers or manual corrections absorb the difference.

Check the application contract

The migration guide identifies changes that affect existing Messages API integrations. Forced tool selection using any or tool now returns a 400 error. Applications should also read response blocks by type and preserve thinking blocks in tool loops. Sonnet 5.5 migration guide

The model overview flags another visible change: text between tool calls moves into thinking blocks. An interface that expects ordinary text may appear silent unless its display handling is updated. Sonnet 5.5 model overview

For a business owner, this is a reason to involve whoever maintains the integration. For the developer, it is a reason to test the request, response parser and tool loop together. A successful single chat response is not proof that an existing automation still works.

Measure the completed job

Our suggested comparison starts with a repeatable task, such as producing a support-response draft from approved information. Keep the input, allowed tools and acceptance criteria fixed. Record the exact model and effort setting for each run.

Measure elapsed time to an acceptable result, billed usage, failed attempts and the review effort required. Keep output generation speed separate from the full workflow's duration. A faster stream of text does not tell you how long document retrieval, tool execution or human checking took.

This is a proposed evaluation method. We have not run a Mimir comparison of these models.

We are also withholding a benchmark ranking: the linked Sonnet 5.5 system card could not be retrieved during this review, so we could not fully verify its evaluation conditions. The accompanying chart therefore compares published prices only.

Make the change reversible

Start with one workflow whose outputs a person already reviews. Preserve the existing model configuration and a way to return to it. Compare representative successes and awkward cases before expanding access.

Set a budget for the trial, and include refused requests and fallbacks in the record. Our Claude refusal-billing briefing explains why a stopped request can still matter to the bill. For the higher-priced option, our Opus 5.5 briefing provides separate migration context.

Sonnet 5.5 is worth a measured trial where volume, response time and review effort matter. Adopt it when your own records show an acceptable result at an acceptable total cost, with the integration behaving as intended.