9 min read - Claude Sonnet 5.5 migration: measure cost per accepted task
AI Operations
Published September 29, 2026 · Author Exceev Consulting
Anthropic released Claude Sonnet 5.5 on 28 September 2026 and described it as more than 30% faster than Sonnet 5, with up to 30% lower cost for most work. The model reached Anthropic's API, Amazon Web Services, Google Cloud, Microsoft Foundry and GitHub Copilot on release day or through a gradual rollout. A team can therefore encounter it as an API choice, a cloud model or an option inside a coding assistant within the same week.
That quick distribution creates a procurement trap. Anthropic's headline concerns cost per task, while the published API price remains the same as Sonnet 5. The new model also changes thinking settings, tool selection and response blocks. A lower bill for a successful benchmark run does not guarantee a safe drop-in replacement for a production agent.
The useful question is narrower: does Sonnet 5.5 complete your accepted work at lower total cost without breaking the application around it? Answer it with a paired evaluation and a staged migration, rather than a model-wide switch.
Cost per token stayed still while cost per task moved
The Anthropic launch announcement reports the speed and cost-per-task gains. Its benchmark charts compare quality and spend across effort levels, and its notes say the results come from vendor runs and named evaluation partners. They are useful evidence about the release, but they are not a forecast for a company's own prompts, documents, tools or acceptance rules.
Anthropic's migration guide says Sonnet 5.5 has the same input and output prices as Sonnet 5. The possible saving comes from execution: fewer tokens, fewer tool calls, less elapsed time or fewer retries may reduce the cost of finishing a task. The opposite can happen when an application uses a poorly matched effort level, repeats failed calls or sends more work to human review.
This distinction changes the metric. Cost per million tokens belongs in the calculation, yet the business denominator should be an accepted task. For a coding agent, acceptance might mean tests pass and a reviewer approves the diff. For document extraction, it might mean every required field passes a deterministic check and sampled records meet a specialist's threshold. For support, it could mean the answer resolves the case without a reopen inside the chosen observation window.
Calculate the whole path:
| Measure | Include |
|---|---|
| Model spend | Input, output, caching and failed-call charges |
| Execution | Tool calls, sandbox or compute time, search and storage |
| Human work | Review, correction, escalation and incident handling |
| Outcome | Accepted tasks, rejected tasks, retries and unresolved cases |
| Service behaviour | Median and tail latency, timeouts, refusals and unavailable capacity |
A model that costs 20% less per attempt and doubles the correction queue is more expensive in practice. A higher-priced attempt can be the cheaper choice when it passes the acceptance gate more often.
The API migration belongs in the business case
Sonnet 5.5 is not a model-ID-only change for many agent applications. The official guide lists settings that can return HTTP 400 errors and response changes that can make an interface appear silent even when the request succeeds.
Forced tool choice with tool_choice: "tool" or "any" is rejected. Anthropic recommends automatic
tool selection with strict schemas where the platform supports them, plus application-side validation.
Code that reads content[0].text can also fail because a response may start with a thinking block. The
consumer should select blocks by type and preserve signed thinking blocks in tool loops.
There are further differences. thinking: {"type": "disabled"} is no longer accepted; between_tools
is the lowest setting. Computer-use integrations on the Claude API and Google Cloud need a newer toolset,
and text between tool calls can move into thinking blocks. Safety refusals also have categories that an
application should handle explicitly. These are testable interface contracts, not prompt-tuning details.
The same model can expose different surrounding features by platform. The
AWS release guide
documents Global CRIS access through Amazon Bedrock and shows that callers must read content by block
type. The
Google Cloud model page
lists general availability, European multi-region processing and the between_tools setting. Those
pages establish platform availability and interface details. They do not establish that a particular
workload meets its privacy, residency, security or contractual requirements; that review remains specific
to the chosen account, region, configuration and agreement.
Build a paired evaluation from live work
Start with a frozen sample of recent, authorised tasks. Remove secrets and personal data unless the test environment and legal basis permit them. Keep the current production model as the control, then replay the same inputs against Sonnet 5.5 at two effort levels that match the workload.
Use enough cases to expose the awkward tail: an ambiguous ticket, a long document, a tool error, a task that should be refused, and an input near the context or output limit. Routine examples alone tend to measure formatting rather than operational fitness.
Score each run against an external acceptance rule. Deterministic tests can check schemas, calculations, citations, repository tests and policy constraints. Human reviewers can judge the portions that need domain knowledge, but they should work blind to the model name where practical. Record disagreements instead of forcing a tidy score.
The NIST AI Risk Management Framework Core asks organisations to define the context and intended use, compare benefits and costs with suitable benchmarks, document human oversight and monitor third-party AI risks over the lifecycle. A model upgrade fits that pattern: the model name changes one component, while the application's users, controls and consequences stay in scope.
For each case, retain the model ID, effort, prompt version, tool trace, token counts, latency, stop reason, acceptance result and reviewer time. Then compare distributions rather than averages alone. A lower median can hide a slower 95th percentile, and a high overall pass rate can hide regressions in the few tasks that carry most of the risk.
Sweep effort instead of accepting the default
Anthropic sets different defaults across surfaces: High effort on the Claude Platform and Medium in Claude apps. Its migration guide says effort levels were recalibrated for Sonnet 5.5 and recommends re-running the sweep. That warning matters because effort changes reasoning time, output use, latency and quality together.
Pick two starting points based on the task. Low or Medium may fit short classification and latency-sensitive chat. Medium and High are better candidates for multi-step tool use or coding. Do not assume Max is the best setting. Anthropic reports a benchmark where Max scored below Xhigh because extra review work caused timeouts or out-of-scope edits.
A small matrix is often enough for the first decision:
| Candidate | Quality gate | Cost per accepted task | P95 latency | Review minutes |
|---|---|---|---|---|
| Current model/config | Baseline | Baseline | Baseline | Baseline |
| Sonnet 5.5, Medium | Measured | Measured | Measured | Measured |
| Sonnet 5.5, High | Measured | Measured | Measured | Measured |
| Sonnet 5.5, fallback | Measured | Measured | Measured | Measured |
The fallback row tests the system, not the happy path. Trigger a refusal, tool timeout or capacity failure and confirm that the application stops safely, retries only when safe and preserves the audit trail.
Separate assistant rollout from API rollout
GitHub made Sonnet 5.5 generally available in Copilot on 28 September, with a gradual rollout across IDEs, the coding agent, CLI and other clients. Its announcement says Business and Enterprise administrators can control access through model policy, while default model enablement may turn new models on automatically unless the administrator changes that setting.
An interactive coding assistant and a production API integration need different gates. For the assistant, select a volunteer group, define which repositories and data classes are allowed, and review accepted changes through the normal engineering controls. For an API, use shadow traffic or a small percentage of eligible tasks, keep the old path available, and automate rollback on quality, error-rate or latency limits.
Do not combine both rollouts into one success claim. Developers may like the model in an IDE while the agent API still fails on a forced tool choice. Conversely, a stable extraction service says little about how well the model handles an unfamiliar repository. One release can support several products without producing one universal adoption decision.
Our evaluation-driven development guide shows how to turn production examples into versioned tests. The multi-model resilience review covers the cost of keeping fallback paths real rather than decorative. Exceev's services approach connects the business decision, engineering change and team handover when an evaluation moves into production.
Write the decision before raising traffic
The owner should sign a short record containing the workload, excluded cases, control model, candidate configuration, acceptance rule, sample period, results, unresolved failures, rollback threshold and next review date. Link the exact evaluation dataset version and application commit.
Approve migration by workload, not by company-wide model preference. A lower cost per accepted task on well-scoped code fixes may justify one route. High-impact reviews, open-ended research or sensitive actions may keep a different model, more human review or no automation at all.
Sonnet 5.5 arrived quickly across major developer and cloud channels, so teams will see pressure to enable it quickly too. The release may deliver material savings. The credible proof is a smaller invoice for work that still passes the same acceptance standard, with the new API behaviour tested and a rollback that has already worked.
Sources and limitations
We opened and reviewed every source below on 29 September 2026.
- Anthropic's 28 September launch announcement provides the release date, vendor speed and cost-per-task claims, benchmark results, effort discussion and broad platform availability. The benchmarks are vendor-selected and do not predict a specific workload.
- Anthropic's Sonnet 5.5 migration guide provides the unchanged Sonnet 5 pricing statement, incompatible settings, response-block changes, refusal handling and effort guidance.
- AWS's release guide and the Google Cloud model page confirm provider-specific availability and interface details.
- GitHub's Copilot announcement provides availability, rollout and administrator-policy details for Copilot.
- The NIST AI RMF Core supplies independent guidance on context, benchmarks, lifecycle monitoring, human oversight and third-party AI risk.
We did not run Sonnet 5.5, reproduce the published benchmarks, inspect provider infrastructure or compare private commercial terms. Availability, pricing, features and documentation can change after the review date. No customer outcome, compliance result or Exceev deployment is claimed. The evaluation design is operational guidance, not legal, privacy, security or procurement advice.
Thinking about AI for your team?
We help companies move from prototype to production — with architecture that lasts and costs that make sense.