Skip to content

Claude Sonnet 4.5 retires on November 30. The migration is not one line

Claude Sonnet 4.5 stops answering on the Claude API on November 30, 2026. Swapping the model name may not be enough: since API version 2026-10-21, temperature, top_p and top_k return a 400. Export usage by key and model, fix the request, rerun your own cases before the switch.

On November 30, 2026, Anthropic retires claude-sonnet-4-5-20250929 from the Claude API. After that date, requests to it fail. They do not slow down or fall back to something close. They return an error. As of November 9, that is 21 days away. The same day, fast mode for Claude Opus 4.8 is removed, and that ends in an error too.

2026-09-30  claude-sonnet-4-5-20250929 marked Deprecated     (notice: 61 days)
2026-10-21  API version where temperature / top_p / top_k -> 400
2026-10-30  release notes: fast mode for Claude Opus 4.8 deprecated
2026-11-30  claude-sonnet-4-5-20250929 retired           -> requests fail
2026-11-30  claude-opus-4-8 with speed: "fast" removed    -> requests return an error

Anthropic's named replacement for Sonnet 4.5 is claude-sonnet-5-5. The obvious fix is to change one string. It may not be enough. The deprecations page notes that since API version 2026-10-21 the sampling parameters temperature, top_p and top_k return a 400. Code that was tuned with those parameters can fail even with the right model name.

So the work before November 30 has three steps: find every place the old identifier still runs, fix the request, and rerun your own cases before you switch traffic.

In our view, this hits one founder hardest: the one whose AI feature was built by a contractor who has since moved on. The model name can sit in code nobody on the team has opened in a year.

Step 1: find where the old model still runs

Start from usage, not from the code. Code tells you what could call the model. Usage tells you what actually does.

Anthropic's deprecations page points to Claude Console → Usage → Export. The CSV breaks usage down by API key and by model. It shows which keys still send traffic to the retiring identifier, and a key can map to a service, an environment or a person.

Claude Console -> Usage -> Export (CSV)

filter:   model = claude-sonnet-4-5-20250929
group by: API key
-> one row per key still calling the old model
-> for each key: which service, who owns it, who can deploy it

Then search the code and config behind those keys. Search beyond the main repository too: env files, a config table, a no-code automation, a function someone deployed by hand.

grep -rn "claude-sonnet-4-5" .
grep -rn "claude-opus-4-8" .
grep -rn "speed" .                      # speed: "fast" on Opus 4.8
grep -rnE "temperature|top_p|top_k" .

Our opinion: a key with traffic and no owner is the real finding of this step. It is the part of the product nobody is responsible for.

Step 2: fix the request, not just the name

A one-line migration looks like this:

- "model": "claude-sonnet-4-5-20250929",
+ "model": "claude-sonnet-5-5",

What the deprecations page warns about is the rest of the request body. If the integration sets sampling parameters, those lines return a 400 from API version 2026-10-21 on. An illustration:

  {
    "model": "claude-sonnet-5-5",
-   "temperature": 0.2,
-   "top_p": 0.9,
    "max_tokens": 1024,
    "messages": [...]
  }

Deleting the lines is the easy part. The harder part is that they were there for a reason. A low temperature may have been how someone kept a classifier stable or a JSON extractor from drifting. Take the setting away and the behavior it bought has to come from somewhere else: the prompt, a schema, a validation step after the call. That is a code change and a design decision, not a find-and-replace.

Fast mode is the same kind of change. Per the release notes of October 30, after November 30 requests to claude-opus-4-8 with speed: "fast" return an error. Any call that sends it needs an edit, and that edit goes through step 3 like the rest.

Step 3: rerun your own cases before the switch

A new model passing a demo proves little. What matters is whether it handles your inputs the way the old one did, including the ordinary ones nobody thinks to test.

A team described exactly this in an r/AI_Agents thread on October 2, 2026. They changed only a prompt. The change passed the cases they had tuned it on. On a set it had not seen, it wrongly blocked 17 of 30 ordinary requests. They now ship any model or prompt change as its own version. A commenter in the same thread named the buyer's fear: not wanting every model release to turn into a testing project for their team.

That fear is fair. Our answer is a small, boring harness that exists before the next release, not after it:

cases/
  tuned/     # inputs the prompt was written against
  holdout/   # real, ordinary inputs it never saw
  edge/      # cases that once broke production

for model in [current, candidate]:
    for case in tuned + holdout + edge:
        out = call(model, case.input)      # same prompt, same code path
        record(model, case.id, check(out, case.expected))

compare pass rate per folder, per model
ship only if holdout does not get worse

The holdout folder is the point. Tuned cases tell you the prompt still fits what it was aimed at. Holdout cases tell you whether it still behaves on Tuesday's traffic.

Run the current model through it now, while it still answers. After November 30 there is no baseline to compare against.

What the steps leave out

Our recommended order, not Anthropic's. Two things the steps above do not say:

migrate on a branch, not in place    -> the old path stays runnable until the switch
keep the harness after November 30   -> the next notice starts from a baseline, not from zero

We do not expect this to be the last retirement. In our view, a team that keeps the harness turns the next deprecation notice into routine work.

What would change our mind: if your integration sets no sampling parameters and does not use fast mode, step 2 shrinks to the one-line diff. Steps 1 and 3 stay.

FAQ

Is the 400 tied to the new model or to the API version? The deprecations page ties it to API version 2026-10-21, not to a model name. Our reading: test the full request body on the API version your client actually sends, not only the new model string.

Does this touch Claude Opus 4.8 without fast mode? The October 30 release notes describe the removal of fast mode: requests to claude-opus-4-8 with speed: "fast" return an error after November 30. That entry announces nothing beyond fast mode.

How many test cases do we need? There is no official number. Our view: start with the inputs the prompt was tuned on, a holdout set of real ordinary requests, and every case that has broken production before. The holdout set is the one that catches what the team in the thread above missed.

A related case

The same discipline runs through Holt, our language-learning product. No model output reaches a learner unvalidated, and generated material is judged against blind golden sets by a model with no hand in it: 96.7% pass and 0.0% substantive defects on the wave of August 19, 2026. That is the harness from step 3, kept running. The case is at iloblique.com/holt.

If you have something worth building, we'd like to hear about it.

Sources