Claude Sonnet 5: Migration Notes for Coding Agents and Document Workflows

The first things I would check before moving a Sonnet 4.6 workload to Sonnet 5 are token counts, request parameters, and effort settings. Those affect whether an existing integration works—and what it costs—before benchmark gains become relevant.

Anthropic’s June 30, 2026 launch materials describe Claude Sonnet 5 as a stronger model for coding agents, tool use, document analysis, and longer autonomous workflows. The advertised limits are a 1M-token context window and 128k output tokens on the synchronous Messages API.

The migration has some consequential changes:

• Adaptive thinking is enabled by default.
• Manual extended-thinking budgets have been removed.
• Non-default temperature, top_p, and top_k values return a 400 error.
• The new tokenizer produces roughly 30% more tokens for the same text than Sonnet 4.6.

I would treat this as a model upgrade that needs an integration review, even if changing the model ID takes one line.

Start with the request contract

The API model ID is:

claude-sonnet-5

Sonnet 5 decides how much reasoning to use through adaptive thinking. The developer-facing control is effort, rather than a manually assigned thinking-token budget.

Anthropic’s recommendations map to these workloads:

Effort	Intended use
low	Tasks where latency matters most
medium	Balanced cost and performance
high	Complex reasoning, coding, and agentic tasks
xhigh	Harder coding tasks and longer agent runs
max	Runs where peak capability matters most

I would start a general evaluation at medium, then test high or xhigh on tasks where incomplete execution is expensive. Anthropic recommends high for complex work; that still deserves a comparison against the latency and cost requirements of the application.

Choose the endpoint around the controls you need

For a unified API spanning Claude, GPT, Gemini, and other models, CometAPI lists access to 500+ models with one key, failover, and centralized billing; its listed Sonnet 5 rates at the time of writing are $1.60 per million input tokens and $8 per million output tokens, 20% below the official launch rates.

There are two integration paths:

Endpoint	When I would use it
/v1/messages	Adaptive thinking, effort control, prompt caching, server tools, and Claude response blocks
/v1/chat/completions	OpenAI-compatible applications, provider routing, and cross-model A/B tests

For an agent that depends on Claude-specific behavior, I would use the native Messages interface. Portability is useful, but I want explicit access to the controls I am evaluating.

A minimal SDK call

This example uses the Anthropic Python SDK with the gateway base URL. It omits sampling overrides and selects medium effort.

import os
from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com",
)

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=[
        {
            "role": "user",
            "content": (
                "You are a senior backend engineer. Review this API design, "
                "identify reliability risks, and suggest production-ready fixes."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

For a harder migration-planning task, the same client can request xhigh effort and a larger output limit:

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=16000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": "Analyze this repository migration plan and produce a step-by-step implementation checklist.",
        }
    ],
)

The following older request pattern is incompatible with Sonnet 5:

# Not recommended for Claude Sonnet 5
response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    temperature=0.2,
    thinking={"type": "enabled", "budget_tokens": 8000},
    messages=[{"role": "user", "content": "Solve this problem."}],
)

Manual thinking budgets return an error, as do non-default sampling parameters. I would inspect shared client wrappers for these fields: an application can inherit them even when the call site looks clean.

Recalculate context capacity and cost together

A 1M-token window is useful for repository analysis, contract packets, technical manuals, financial documents, and long support histories. It does not guarantee the same text capacity as a previous model with the same nominal limit.

Anthropic says Sonnet 5’s tokenizer produces about 30% more tokens for identical text compared with Sonnet 4.6. Existing prompt-size measurements, truncation thresholds, and cost estimates therefore need another pass.

For a repository agent, I would measure representative source files and tool transcripts. For document processing, I would measure the actual extracted documents. The relevant number is the token count of the material the application sends.

Official pricing changes in September

The official launch rates run through August 31, 2026. Standard rates begin September 1, 2026.

All prices below are per million tokens:

Token category	Through August 31, 2026	From September 1, 2026
Input	$2	$3
Output	$10	$15
5-minute cache writes	$2.50	$3.75
1-hour cache writes	$4	$6
Cache hits and refreshes	$0.20	$0.30

For a workflow that repeatedly reads the same repository context or document collection, prompt caching belongs in the evaluation. I would also keep launch and standard pricing separate in any forecast; a temporary rate can distort the economics of a longer deployment.

Read the benchmarks by workload

The figures below are reported in Anthropic’s Sonnet 5 system card and launch materials. They provide useful evaluation targets, though I would still run the model against my own tasks before switching production traffic.

Benchmark	What it tests	Sonnet 5	Sonnet 4.6
SWE-bench Verified	Real GitHub issue resolution	85.2%	Not provided in the summary
SWE-bench Pro	Harder repository issues spanning multiple files	63.2%	58.1%
SWE-bench Multilingual	Coding across 9 languages	78.3%	Not provided in the summary
Terminal-Bench 2.1	Terminal tasks	80.4%	67.0%
BrowseComp	Agentic web search	84.7% single-agent / 86.6% multi-agent	76.2%
Humanity’s Last Exam, no tools	Knowledge and reasoning	43.2%	34.6%
Humanity’s Last Exam, with tools	Reasoning with tool access	57.4%	46.8%
OSWorld-Verified	Computer use	81.2%	78.5%
FrontierCode v1	Agentic software engineering	38.8%	15.1%
GDPval-AA v2	Professional work, ELO	1609	1381
AutomationBench	Business automation	13.5%	5.3%
HealthBench Professional	Clinical tasks	57.8%	44.2%

For coding agents, Terminal-Bench 2.1 and FrontierCode v1 are particularly relevant to my evaluation. The reported changes—from 67.0% to 80.4% and from 15.1% to 38.8%, respectively—suggest testing sustained execution alongside patch correctness.

An agent can produce plausible code while missing repository conventions, skipping tests, or abandoning a migration halfway through. My evaluation would include those failure modes.

The launch materials also report improvements on GPQA Diamond, MMMU, MathVista, OfficeQA, the Legal Agent Benchmark, and health-related tasks. They describe favorable cost-performance at medium effort for agentic search and computer use, with high effort approaching Opus performance.

Early testers reported completing some projects in hours that previously took multiple days. Other reports noted variability against Opus on creative or unusual tasks at maximum effort. I would treat those as reasons to reproduce a workload, rather than as throughput estimates for my own team.

Where I would evaluate it first

Repository work with several dependent steps

Debugging, refactoring, test generation, dependency updates, pull request review, and code migrations are natural candidates.

Anthropic positions Sonnet 5 around planning, tool use, unprompted output checking, and work in existing codebases. That combination matters most when the agent must inspect the repository, make a change, run tools, interpret failures, and continue.

I would include messy repositories in the test set. A clean isolated function does little to test whether an agent can navigate local conventions and incomplete documentation.

Document review with repeated context

The long context window makes policy collections, contracts, financial reports, technical documentation, and project archives plausible workloads.

My evaluation would check both answer quality and context consumption. If the application repeatedly sends the same material, I would test caching alongside extraction quality and token counts.

Research and operational workflows

BrowseComp and Humanity’s Last Exam with tools make research agents worth testing. GDPval-AA, OfficeQA, and the reported GDP.pdf results are relevant to workflows that combine document reading with professional deliverables.

Operational candidates include CRM updates, spreadsheet analysis, customer-response drafts, meeting summaries, and report generation. The 13.5% AutomationBench result is an improvement over 5.3%, but the absolute score still argues for task-specific evaluation.

For customer support, I would try low or medium effort for routine drafts and increase effort for cases involving long histories, policy interpretation, or uncertain escalation decisions.

Tool access makes safety results relevant

Sonnet 5 is designed to work with browsers, terminals, file systems, code execution, and structured APIs. Those capabilities expand what an agent can complete and what its mistakes can affect.

Anthropic reports a lower overall rate of undesirable behavior than Sonnet 4.6, better resistance to certain prompt-injection attacks, and real-time cybersecurity safeguards. Its reported Firefox 147 cybersecurity evaluation recorded 0% full exploit success.

I would keep that result scoped to the evaluation. For an application that reads external pages and then acts through internal tools, I would test the actual boundaries around credentials, customer data, and tool permissions. Clinical-task improvements also still require expert review in applicable workflows.

Access and routing choices

Sonnet 5 is available through Claude.ai, Claude Code, Claude Platform, and Google Vertex. Anthropic describes it as the default for Free and Pro users, with availability for Max, Team, and Enterprise users.

For API routing, I would use a small set of task-based choices:

Task	Starting strategy
Classification, tagging, short summaries	A cheaper fast model
Customer support drafts	Sonnet 5 at low or medium
Code review and bug investigation	Sonnet 5 at high or xhigh
Long document analysis	Sonnet 5 with prompt caching
Harder enterprise reasoning	Evaluate escalation to Opus 4.8 or Fable 5
Provider comparisons	OpenAI-compatible routing

Anthropic positions Sonnet 5 as narrowing the gap with Opus 4.8 while retaining the Sonnet family’s speed and pricing profile. I would keep Opus in the comparison set for peak reasoning and harder agentic tasks, then choose based on completed work, latency, and cost.

Before moving traffic, my migration checklist would be short: remove incompatible request fields, recount representative inputs, compare effort levels, test tool-driven completion, and calculate costs using the September rates.

---

Originally published at cometapi.com