# Replacing Claude Sonnet 4.5 before Nov 30: a test method

URL: https://infro.io/blog/replacing-claude-sonnet-4-5-before-nov-30-a-test-method
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-27
Last modified: 2026-10-27
Last reviewed: 2026-10-27 (next review due 2026-11-26)
Topic: Evaluation and models
Format: Methodology

> Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) retires November 30, 2026, with claude-sonnet-5-5 as the recommended replacement [^anthropic-deprecations]. Test two or three candidate configurations on a sample of your own requests, compare cost per successful task and cache read share rather than list rates, and finish the cutover about ten days before the date.

Key takeaways:
- Sonnet 4.5 retires on Anthropic-operated platforms on November 30, 2026; Bedrock and Google-managed Vertex set their own dates, so read your cloud's page too.
- Test model-plus-configuration pairs, not model names: Sonnet 5.5 with default adaptive thinking and Sonnet 5.5 with the lowest thinking setting can differ a lot in output tokens.
- Rate the candidates by cost per successful task from recorded usage, because a newer tokenizer, thinking tokens and a different cache-read rate all move the real number.
- Measure cache behavior on its own with production request spacing; a model switch starts every prefix cold.
- Finish the cutover by about November 20 and keep the old configuration as a rollback only until the retirement date.

## 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.[1] After the retirement date, requests to the model fail.[1] 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.[1] Microsoft's Foundry schedule shows `claude-sonnet-4-5` retiring 2026-11-30 with `claude-sonnet-5-5` as the replacement.[2] For Bedrock, Anthropic points to Amazon's model lifecycle page rather than stating a date.[3] 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.[2] 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.[4] The lowest setting, `thinking: {"type": "between_tools"}`, works at low, medium and high effort.[4] 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:[5][1]

| Candidate | Input / output per MTok | Cache read per MTok | Earliest retirement (Anthropic) |
| --- | --- | --- | --- |
| Sonnet 4.5 (baseline) | $3 / $15 | $0.30 | November 30, 2026 |
| Sonnet 4.6 | $3 / $15 | $0.30 | not sooner than February 17, 2027 |
| Sonnet 5 | $2 / $10 | $0.20 | not sooner than June 30, 2027 |
| Sonnet 5.5 | $2 / $10 | $0.10 | not sooner than September 28, 2027 |
| Haiku 5.5 (prompts up to 100K tokens) | $0.10 / $0.50 | $0.01 | not sooner than October 7, 2027 |

Table: List rates as published by Anthropic on the day of reading. Your contract rates replace them.

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.[4] 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.[5] 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.[5] 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"}`.[4] 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.[4] 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.[4]

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

```python
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.[3] An unpinned upgrade in your test harness can break the baseline you are measuring against. See the [API version notes](https://infro.io/blog/anthropic-api-version-2026-10-21) 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.[1] 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.

```python
# 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](https://infro.io/blog/cost-per-successful-task).

> **Example: Illustrative figures, not measurements**
> One task with a 6,000-token stable prefix read from cache, 800 fresh input tokens and 500 output tokens on Sonnet 4.5 at list rates: 6,000 × $0.30 + 800 × $3 + 500 × $15 per million = **$0.0117**. Assume the same text becomes about 30% more tokens on Sonnet 5.5 (7,800 cached, 1,040 fresh, 650 output): 7,800 × $0.10 + 1,040 × $2 + 650 × $10 per million = **$0.00936**.
> 
> If default adaptive thinking adds 700 output tokens, the same task costs **$0.01636**. With pass rates of 90% on 4.5 and 94% on 5.5, cost per successful task is $0.0130, $0.00996 (low thinking) and $0.0174 (default thinking). The pass rates and the thinking volume are made up; the point is that the ranking can flip on a setting you control.

## 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`.[6] 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.[6]

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.[5] Caching pays after one read for the five-minute duration and after two reads for the one-hour duration.[5] 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](https://infro.io/blog/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.[7] 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.[3] 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.[8] Sonnet 5 is listed as open to all Bedrock customers.[8] 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.[5]

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

**Azure Foundry.** The schedule lists Claude in two versions, one hosted on Anthropic infrastructure and one hosted on Azure.[2] 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.[2] 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.[2]

## 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.

| Dates (2026) | Step | Exit condition |
| --- | --- | --- |
| Oct 27–30 | Inventory keys, features and platforms; record your platform's retirement date; freeze the test set | Every Sonnet 4.5 caller has an owner |
| Oct 31–Nov 6 | Fix 400s, run all candidates offline, score success and cost per success | Two finalists, one fallback |
| Nov 9–13 | Cache-spacing replay; shadow run on live inputs with answers discarded | Cache read share and cost per success hold on live inputs |
| Nov 16 | 5% canary on the lowest-risk feature | No rise in errors, `length` stops or retries |
| Nov 17–19 | 25%, then 50%, one feature group per step | Each step holds a full day |
| Nov 20 | 100% on the chosen configuration | Cache warm, spend within forecast |
| Nov 23–27 | Hold; Sonnet 4.5 remains the rollback until the end | Remove the Sonnet 4.5 path in code |
| Nov 30 | Retirement | Nothing should call the old ID |

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](https://infro.io/blog/ab-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.[9] They cannot judge answer quality, because they read no prompts or answers, so the scoring above stays yours.[9] Per-request usage records and custom rates give you the cost data the script above needs on your own contract rates.

## Questions

### Will Sonnet 4.5 keep answering after November 30 if I do nothing?

On Anthropic-operated platforms, no. Anthropic states that requests to models past the retirement date fail [1]. On Bedrock and Google-managed Vertex the date is set by the cloud, so read its lifecycle page; do not assume it is later.

### Is Haiku 4.5 a safe place to park traffic for a month?

Not on every platform. Microsoft's schedule lists claude-haiku-4-5 on Foundry with a retirement date of 2026-11-15, earlier than Sonnet 4.5's [2]. Check your platform's date before treating it as a stopgap.

## Sources

1. Model deprecations — Anthropic (Claude Platform Docs). https://platform.claude.com/docs/en/about-claude/model-deprecations (accessed 2026-10-27)
2. Model retirement schedule - Microsoft Foundry — Microsoft Learn. https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirement-schedule (accessed 2026-10-27)
3. Claude on Amazon Bedrock (Opus 4.6 and earlier) — Anthropic (Claude Platform Docs). https://platform.claude.com/docs/en/build-with-claude/claude-on-amazon-bedrock-legacy (accessed 2026-10-27)
4. Claude Sonnet 5.5 migration guide — Anthropic (Claude Platform Docs). https://platform.claude.com/docs/en/models/sonnet-5-5/migration-guide (accessed 2026-10-27)
5. Pricing — Anthropic (Claude Platform Docs). https://platform.claude.com/docs/en/about-claude/pricing (accessed 2026-10-27)
6. Prompt caching — Anthropic (Claude Platform Docs). https://platform.claude.com/docs/en/build-with-claude/prompt-caching (accessed 2026-10-27)
7. Prompt caching — INFRO Docs. https://infro.io/docs/features/prompt-caching (accessed 2026-10-27)
8. Claude in Amazon Bedrock (Opus 4.7 and later) — Anthropic (Claude Platform Docs). https://platform.claude.com/docs/en/build-with-claude/claude-in-amazon-bedrock (accessed 2026-10-27)
9. Traffic changes — INFRO Docs. https://infro.io/docs/observability/traffic-changes (accessed 2026-10-27)