Replacing Claude Sonnet 4.5 before Nov 30: a test method

What actually ends on November 30

Anthropic lists claude-sonnet-4-5-20250929 as deprecated since September 30, 2026, with a retirement date of November 30, 2026 and claude-sonnet-5-5 as the recommended replacement.¹ After the retirement date, requests to the model fail.¹ Today is October 27, so you have 34 days, and the real deadline is earlier: the last stage of a safe rollout is a week of watching.

The date is not the same everywhere. Anthropic's dates apply to its own platforms: the Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) and Microsoft Foundry. Amazon Bedrock and Claude Models on Google Cloud (Google managed) set their own schedules, so status and dates can differ.¹ Microsoft's Foundry schedule shows claude-sonnet-4-5 retiring 2026-11-30 with claude-sonnet-5-5 as the replacement.² For Bedrock, Anthropic points to Amazon's model lifecycle page rather than stating a date.³ Write down the date your own platform gives. If it is earlier than November 30, every date below moves earlier with it.

The replacement column is a default, not a verdict. Microsoft says the replacement is its recommended one and, where supported, the target for automatic upgrades at retirement, and that you do not need to wait for a replacement to be listed before evaluating another compatible model.² An automatic upgrade you never tested is exactly the failure this method is meant to prevent.

Choose model-and-configuration candidates

Do not test "Sonnet 5.5". Test pairs of model and request configuration, because the configuration changes cost and behavior. On Sonnet 5.5 a request with no thinking field runs adaptive thinking; on Sonnet 4.5 the same request ran without thinking, and thinking tokens are billed as output tokens.⁴ The lowest setting, thinking: {"type": "between_tools"}, works at low, medium and high effort.⁴ So Sonnet 5.5 is at least two candidates.

Anthropic's list rates for the realistic options, with the earliest retirement date it gives for each:⁵¹

Sonnet 4.6 costs the same per token as 4.5 and buys you about eleven weeks, so it is a stopgap, not a destination. Sonnet 5.5 has the same prices as Sonnet 5 except for cache reads, at half the Sonnet 5 rate.⁴ Haiku 5.5 is worth a slot only if some of your Sonnet 4.5 traffic is classification, extraction or routing; Anthropic positions it for those.⁵ Its rates change above 100,000-token prompts, so price it per request, not per model. Keep the field to three or four pairs. More than that and you will not finish scoring.

One trap for the cost column: Claude 4.7 and later models use a newer tokenizer that produces roughly 30% more tokens for the same text, while Sonnet 4.6 and earlier use the previous one.⁵ A lower rate per token does not mean a lower bill until you have counted tokens on your own text.

Make the requests runnable before you compare anything

The first failures you will see are not quality differences; they are 400 errors. Sonnet 5.5 rejects temperature, top_p and top_k, assistant prefill, forced tool choice (tool_choice of type any or tool), thinking budgets and thinking: {"type": "disabled"}.⁴ Coming from Sonnet 4.5 you also move output_format to output_config.format, set output_config.effort explicitly and parse tool call input with a standard JSON parser.⁴ Responses can begin with thinking blocks, so code that reads content[0].text breaks; read blocks by type, and raise max_tokens because it covers thinking plus text.⁴

Do this in a branch, with the candidate configuration as data, not as scattered if statements:

CANDIDATES = {
    "baseline-45": {"model": "claude-sonnet-4-5-20250929"},
    "s55-default": {
        "model": "claude-sonnet-5-5",
        "output_config": {"effort": "medium"},
        "max_tokens": 8192,            # covers thinking + text
    },
    "s55-lowthink": {
        "model": "claude-sonnet-5-5",
        "thinking": {"type": "between_tools"},
        "output_config": {"effort": "medium"},
        "max_tokens": 4096,
    },
}

If you call through the SDK on Bedrock, pin the SDK version of the baseline run. Anthropic notes that the latest SDK sends API version 2026-10-21 by default, including through Bedrock, and that the ARN-versioned models on Bedrock, which include Sonnet 4.5, do not support it and can return a 400.³ An unpinned upgrade in your test harness can break the baseline you are measuring against. See the API version notes for what else changes.

Build the test set from your own traffic

Pull the sample from real requests, not from a benchmark. Anthropic suggests exporting usage from the Console as CSV, broken down by API key and model, to find where Sonnet 4.5 is still used.¹ Use that to list every key and feature that touches the model; then sample requests per feature.

• Stratify by feature, not by volume. A feature with 2% of traffic and strict JSON output deserves 40 cases even if the high-volume chat feature gets 40 too.
• Include the ugly tail: the longest prompts, requests that ended with max_tokens, tool-calling turns, retries, and anything that a human later corrected.
• Freeze inputs, including tool results, so each candidate sees the same thing. For multi-turn flows, replay recorded conversations and let only the last turn vary.
• Write the pass check before you run. Schema validity, required fields, a tool called with valid arguments, a regex or a reference answer, and, only where those fail to capture it, a rubric scored by a separate judge model. Judge cost counts in your harness budget, not in the per-task cost.

Prompt and payload logging is off by default in many setups. If you do not already retain prompts, record the sample under your logging policy, with redaction, and delete it after the migration.

Score cost per successful task, not per request

For each candidate, run every sampled task end to end, including retries and repair calls, and sum the billed usage. Cost per successful task is the total cost of all attempts divided by the number of tasks that passed. A model that is cheaper per token but fails more often, or that needs a second call to repair its output, can cost more per success.

# USD per million tokens, list rates. Replace with your contract rates.
RATES = {
    "claude-sonnet-4-5-20250929": dict(inp=3.00, out=15.00, write5=3.75, read=0.30),
    "claude-sonnet-5-5":          dict(inp=2.00, out=10.00, write5=2.50, read=0.10),
}

def call_cost(model, u):
    r = RATES[model]
    return (u["input_tokens"] * r["inp"]
            + u["output_tokens"] * r["out"]   # thinking tokens are billed as output
            + u.get("cache_creation_input_tokens", 0) * r["write5"]
            + u.get("cache_read_input_tokens", 0) * r["read"]) / 1e6

def cost_per_success(tasks):
    # tasks: [{"model": ..., "usages": [every attempt's usage], "passed": bool}]
    total = sum(call_cost(t["model"], u) for t in tasks for u in t["usages"])
    passed = sum(t["passed"] for t in tasks)
    return total / passed if passed else float("inf")

Use the usage the provider returned, not a token counter, so thinking tokens and cache fields are included. For a deeper treatment of the metric see cost per successful task.

Test cache behavior as its own experiment

A cache is per model and per exact prefix, so switching models starts every prefix cold. Anthropic's cache covers the whole prompt in order: tools, then system, then messages, up to the block marked with cache_control.⁶ The default lifetime is five minutes, measured from the start of the request that writes or reads the entry, so a slow response eats into it.⁶

The economics differ by model. A five-minute write costs 1.25 times the base input price, a one-hour write 2 times, and a read 0.1 times, except Sonnet 5.5 and Opus 5.5 at 0.05 times.⁵ Caching pays after one read for the five-minute duration and after two reads for the one-hour duration.⁵ Because the Sonnet 5.5 read rate is lower while the prefix may be larger under the new tokenizer, your break-even number of reads per entry changes. Compare against prompt caching break-even if you are weighing the one-hour option.

Run the cache test separately from the quality run, with production spacing:

1. Replay the same prefixes with the real gaps between requests (use the logged timestamps, not a tight loop; a tight loop reports a hit rate production never sees).
2. For each candidate record cached share = cache reads ÷ (cache reads + cache writes + uncached input).
3. Count writes per hundred requests. A model with a high write count and few reads is paying the write premium for nothing.
4. Look at tools, system prompt and examples order. Anything volatile near the top, such as a timestamp or a user name, breaks the prefix.

If a gateway or router sits in front, remember failover: caches live with the upstream that served the request, and a failover to another connection resets the cache for that prefix.⁷ Include that case in the test if your traffic fails over.

What changes on Bedrock, Vertex and Azure

Bedrock. Sonnet 4.5 is anthropic.claude-sonnet-4-5-20250929-v1:0, and newer models must be called through an inference profile with a prefix such as us.; passing the base ID returns a 400.³ Sonnet 5.5 appears as anthropic.claude-sonnet-5-5 on the Messages-API endpoint, and access is set per model, so check Bedrock model access in your account before you plan on it.⁸ Sonnet 5 is listed as open to all Bedrock customers.⁸ Compare like with like: regional and multi-region endpoints on Bedrock and Google-managed Vertex carry a 10 percent premium over global endpoints, so a test on global routing does not predict a regional bill.⁵

Vertex. The Google-managed schedule is its own; read it before you commit dates. The same endpoint-type premium applies.⁵

Azure Foundry. The schedule lists Claude in two versions, one hosted on Anthropic infrastructure and one hosted on Azure.² It has a claude-sonnet-4-5 row for version 1 with a 2026-11-30 retirement, and lists claude-sonnet-5 in both versions, but it has no row of its own for claude-sonnet-5-5, which it names only as the replacement.² Confirm in your subscription and region that the target you are testing is deployable. Also note that the same table shows Haiku 4.5 on Foundry retiring 2026-11-15, so it is a poor place to park traffic.²

Cutover schedule, October 27 to November 30

Aim to be on 100% of the new configuration by November 20, with the old one still reachable until the retirement date.

If your organization has a holiday change freeze, treat its start as the new November 30. Split by feature, not by random request share, when a feature's behavior is tied to one model's formatting; for random splits see A/B testing LLM models.

Where a gateway helps, briefly

For traffic that goes through INFRO, the model-lifecycle feature records vendor retirement dates, warns organizations still sending a retiring model and, from the shutdown date, refuses it before any provider call, naming the replacement. Routing rules can send a metadata-matched share of requests to the candidate target, and model allowlists can stop a project from calling the old ID after cutover. Traffic changes watch request metadata for the regressions this migration produces: cached share of prompt tokens down at least 10 points, output tokens per request up at least 15%, and a rise in answers cut off by the length limit.⁹ They cannot judge answer quality, because they read no prompts or answers, so the scoring above stays yours.⁹ Per-request usage records and custom rates give you the cost data the script above needs on your own contract rates.