Migrating an application to Claude Sonnet 5 begins with a one-line model change and continues with everything that line affects. The new model uses a different tokenizer, enables adaptive thinking by default, rejects several older parameters, introduces effort controls, and launches under temporary pricing that ends on August 31, 2026.

Anthropic’s migration path from Sonnet 4.6 starts by changing the model ID to claude-sonnet-5. The Messages API request and response shapes remain broadly familiar, but this is not a zero-test drop-in upgrade. Two deprecated configuration patterns return HTTP 400, and the new token behavior can change context use and cost even when the text is identical.

Recount every production prompt

Anthropic says Sonnet 5 uses a new tokenizer. Its announcement describes the same text as requiring roughly 1.0 to 1.35 times the tokens, depending on content, while migration guidance summarizes the typical change as approximately 30 percent more.

Neither number should become a fixed multiplier in billing code. Natural language, code, structured data, and multilingual content can tokenize differently. A prompt that grows by only a few percent in one workload may grow much more in another.

Use Anthropic’s token-counting endpoint with the intended model on representative requests. Recalculate:

Sonnet 5 still provides a one-million-token context window and up to 128,000 output tokens. More tokens for the same text means the window may hold fewer words or lines than before. It also means a per-token rate comparison may understate the cost of an equivalent document.

Replace manual thinking budgets

Older Claude integrations may use explicit extended thinking with thinking: {type: "enabled", budget_tokens: N}. Sonnet 5 does not accept that pattern. Anthropic documents that manual thinking budgets return HTTP 400.

Adaptive thinking is enabled by default. The model decides how much reasoning to use, guided by output_config.effort. Supported levels are low, medium, high, xhigh, and max, with high as the default.

Effort is not a hard token budget. It can influence internal reasoning, visible answer detail, tool choice, number of calls, and function arguments. A low-effort response may use fewer tools; a max-effort response may spend more time exploring alternatives.

The max_tokens field remains a hard ceiling across thinking and final text. If the ceiling is too small for a high-effort task, the model may leave little room for the answer or stop with stop_reason: "max_tokens". Migration tests need to inspect stop reasons and response completeness rather than assuming a successful HTTP status means a complete answer.

Developers can explicitly disable adaptive thinking with thinking: {type: "disabled"} where appropriate. Do that only after evaluating task quality; disabling thinking to preserve an old latency target may change behavior substantially.

Remove unsupported sampling parameters

Sonnet 5 rejects non-default values for temperature, top_p, and top_k with HTTP 400. Applications that expose those controls generically across providers need a model-specific capability layer rather than passing every available setting.

Remove the parameters, not merely the UI labels. Check background workers, retry paths, and stored prompt configurations for values added months earlier. A canary may succeed while an infrequent route still sends an unsupported parameter.

If migrating from Sonnet 4.5 or an earlier model, consult Anthropic’s full migration guide for accumulated changes such as removal of assistant-message prefill. A direct jump inherits every breaking change between versions, not only the Sonnet 5 section.

Understand temporary and standard pricing

Through August 31, 2026, Sonnet 5 promotional pricing is $2 per million input tokens and $10 per million output tokens. On September 1, standard pricing becomes $3 input and $15 output, matching Sonnet 4.6’s per-token rates.

Anthropic describes the promotion as helping keep migration roughly cost-neutral during the transition. That is not a permanent guarantee. After the promotion, the new tokenizer can make an equivalent text request cost more even at the same per-token rate. Default adaptive thinking can also alter output usage.

Build two forecasts: one for evaluation and August traffic, and one for September onward. Separate input, cache writes, cache reads, output, Batch work, and tool expenses. Measure total cost per successful task, including retries and human correction.

Prompt caching may offset repeated long prefixes, but only if the cached material is stable and reused. Do not pad prompts simply because a larger context window exists.

Treat refusals as a normal response state

Some network-security requests may return HTTP 200 with stop_reason: "refusal". Code that checks only the status code can mistakenly treat the request as completed and pass an empty or partial result downstream.

Update response handling to distinguish:

A refusal is not the same as a timeout and should not enter a blind retry loop. The application may ask the user to reframe a legitimate defensive request, route according to an approved policy, or stop. Preserve the refusal category and explanation in logs where permitted.

Re-evaluate tools and structured outputs

Sonnet 5 improves tool use, but a new model can choose a different sequence, format arguments differently, or decide a tool is unnecessary. Replay real workflows that include multiple tools, large results, partial failures, and approval boundaries.

For each case, record:

Structured outputs should be parsed and compared field by field. Free-form answers should be graded against a rubric. Preserve the old model as a controlled fallback during the canary, but do not retry a consequential action solely because the new model’s prose response was lost.

Roll out by workflow class

A safe migration has several stages. First, run offline evaluation with stored inputs and mocked or read-only tools. Then shadow production requests without allowing side effects. Next, canary a small group of low-risk workflows and compare them with Sonnet 4.6. Expand only after latency, cost, refusals, and tool success remain within thresholds.

Different workloads may settle on different effort levels. Extraction might use low, routine agent work high, and difficult exceptions xhigh. Max should be justified by evidence rather than enabled globally.

Maintain dashboards for token growth, stop reasons, tool failures, p95 latency, and review effort. The tokenizer shift makes trend baselines especially important: an apparent usage spike may come from recounting rather than more source text.

Keep an asynchronous media task outside the model

Consider a Claude workflow that uses the Medux video merge tutorial. Claude identifies approved MP4 inputs, obtains upload URLs, uploads files, creates one asynchronous task, polls status, downloads the result, and verifies the combined clip. Medux performs the merge as an external MCP service; it is not part of Sonnet 5.

Migration should change the planner without changing the operation’s identity. Store task parameters in application state before calling Claude:

  1. ordered input file hashes and user approval;
  2. target format and output naming rules;
  3. one idempotency key for the merge;
  4. upload references and expiry times;
  5. returned task ID and current status;
  6. bounded polling interval and timeout policy;
  7. downloaded result hash and validation outcome.

If Sonnet 5 reaches max_tokens, refuses, or times out after submission, the fallback should resume from the stored task ID. It must not infer that the merge failed and create another billable job. Effort can influence how Claude plans and explains the workflow, but polling frequency and duplicate prevention belong in deterministic code.

This separation makes migration reversible. The team can compare Sonnet 4.6 and Sonnet 5 on orchestration quality while the external media task remains observable and idempotent. It also exposes the real value of the new model: fewer planning errors and better exception handling, not a hidden change to the media transformation itself.