Claude Sonnet 4.5's Dated ID Dies Nov 30: Pin or Alias?

Claude Sonnet 4.5's dated snapshot shuts down on November 30, 2026. If claude-sonnet-4-5-20250929 is anywhere in your code, you have just over two weeks to decide how you name models — a choice most teams make by accident.

Two ways to name a model

Every major model API offers the same pair, as a recent developer write-up lays out: a dated snapshot like claude-sonnet-4-5-20250929, or an alias like claude-sonnet-4-5, "which points at whatever the vendor currently serves under that name."

They fail in opposite directions, and that is the whole decision.

Snapshots: stable until they are gone

A snapshot is the same model on every call. The write-up names three cases where that is worth paying for: you have tuned prompts against its exact behaviour, you run evaluations and want results you can compare, or you are in a regulated setting and need to say which model produced an output.

The bill comes due on the shutdown date. As the piece puts it: "On that date every call fails, usually with a 'model not found' style error." There is no degraded mode and no grace period you can rely on — the failure is total and it is scheduled.

Aliases: nothing breaks, everything drifts

An alias follows the vendor's current version, so it tends not to disappear the same way. The cost is subtler and harder to debug: the model behind it "can change without a deploy on your side, and a prompt you tuned last month is now talking to something else."

The symptoms listed are the ones that waste a whole afternoon — output format drift, longer or shorter answers, different refusals — "all without a code change to point at." If your incident process starts by diffing recent commits, an alias swap is invisible to it.

Find yours in one command

Before picking a policy, find out what you actually have. The write-up offers a single grep that catches most dated IDs across code and config:

grep -rnE "(gpt|claude|gemini|o[0-9])[-.a-z0-9]*-20[0-9]{2}" --include=*.{py,ts,js,json,yaml,yml} .

Run it against your whole repo, not just the service you think owns the model calls. Model IDs leak into test fixtures, eval configs and deployment YAML more often than into application code.

The policy that holds up

The recommendation for production code is to pin dated IDs and treat shutdowns as scheduled work, not incidents. Three habits make that workable:

• One config file for every model ID, with the shutdown date in a comment next to each one, so a future reader can find them all at once.
• Shutdown dates on a calendar, rather than in a vendor blog post somebody read once.
• Swap before the date, not after: "swap to the vendor's replacement, rerun your evaluations, deploy. A week before, not the morning after."

Aliases still have a place. The write-up is explicit that they are fine for prototypes, internal tools and anything where "the latest model" is the point — the mistake is letting the prototype's choice ride into production unexamined.

One caveat on sourcing: the piece is published by Versyka, a developer-tools vendor that sells a model-retirement calendar and claims to run that same search daily across customer repositories and open the swap as a tested pull request. Treat the product claims as the company's own. The grep, the config-file habit and the November 30 date stand on their own.

Run the grep today. If it returns nothing, you have an alias problem instead, and that one has no deadline to force your hand.