Claude Sonnet 5.5: a lower-cost worker with API migration pitfalls

AI workflow costs often grow through hundreds of routine requests, repeated reads and unnecessary retries. I would test Sonnet 5.5 as the main worker for bounded tasks: support, document processing and small code changes.

Anthropic released the model on September 28, 2026, reporting over 30% faster generation and up to 30% lower task costs than Sonnet 5. Those are vendor results, not a savings commitment for your pipeline. Token rates have not changed. Announcement.

Half the token rate does not mean half the bill

The model specification lists $2 per million input tokens, $10 for output and $0.20 for cache reads. Five-minute cache writes cost $2.50. The context window is 1M tokens, with a maximum output of 128k tokens.

Input and output rates are half those of Opus 5.5, but cache reads cost the same. That distinction matters when interpreting the headline of Marek Bartoš’s video. An agent carrying a long cached history will not necessarily halve its bill.

For illustration, 100,000 uncached input tokens and 10,000 output tokens cost $0.30 on Sonnet and $0.60 on Opus. Add one million cache-read tokens and the totals become $0.50 and $0.80: a 37.5% saving. This is arithmetic, not a benchmark. Token consumption, tools, retries and human corrections can change the outcome.

Where I would start

In n8n or Make, I would pilot a customer email queue. Basic rules remove spam and duplicates. Sonnet receives the relevant conversation and a verified excerpt from company documentation. It drafts a reply, identifies supporting material and flags missing information.

A separate step writes to the CRM after checking the schema and customer identity. Compensation, service cancellation and payment-detail changes still require approval. Ambiguous cases go to a specialist or a person; the expensive model need not handle every ticket.

For development, I would choose a small bug with a reproduction and a test. The agent proposes a patch, the test checks behavior and a reviewer checks scope. A claim of completion is not the acceptance criterion.

Migration can fail before useful work begins

The migration guide flags Messages API changes:

• Replace disabled thinking with between_tools, at effort high or below.
• Forced tool_choice values any and tool fail. Switching to auto does not guarantee a tool call.
• Parse responses by block type and return thinking blocks unchanged.

Your workflow therefore needs a branch for a valid response that contains no expected action. HTTP 200 does not prove that a CRM record was created. Check the operation’s result and route missing actions for review.

The change documentation also covers history and account binding for thinking blocks, the new computer-use toolset on Claude API and Google Cloud, and changes to progress messages between tools. Long-running agents should be tested for saved-session continuation, model switches and progress rendering.

Let a small evaluation decide

I would compare the current model and Sonnet 5.5 on the same cases at two effort settings. Track cost per correctly completed case, p95 latency, retries, incorrect writes and review time. Include missing information, conflicting documents and tool failures.

This is a proposed pilot, not a benchmark I have run. Sonnet 5.5 should take over routine work only if the savings survive validation, escalation and corrections. I would keep a stronger specialist available for open-ended architecture and difficult judgment calls.