Hardcoded calls to claude-sonnet-4-5-20250929 fail outright after November 30

A dated snapshot id points at one exact model forever, according to the dev.to post. A rolling alias follows whichever version is current ^[10]. The retiring string, claude-sonnet-4-5-20250929, is a snapshot. Its replacement, claude-sonnet-5-5, is a rolling name ^[10][3]. The snapshot is frozen to one model, so requests to it fail once that model reaches Retired status ^[10][5]. Forever, in this case, ends on November 30 ^[2].

The post summarises Anthropic's lifecycle in three stages. Active is fully supported, Deprecated still works but is no longer recommended and has a retirement date, and Retired means requests fail ^[5]. Sonnet 4.5 moved from Active to Deprecated on September 30 ^[1]. According to the post, a pinned call keeps succeeding through the deprecated period and then fails with no warning ^[11].

The post's author located the risk in the model id "sitting somewhere in a config file, an environment variable, or a line of code that nobody's looked at since the day it was written" ^[12]. An environment variable such as ANTHROPIC_DEFAULT_OPUS_MODEL, set once to a dated snapshot, breaks the same way ^[11].

The post recommends the Usage export ^[4], but an export can only list calls made during the period it covers. A monthly job that has not run inside that window will be missing from it. I'd pair the export with a plain text search for the literal id across repos, deploy configs and environment files.

September 30 to November 30 is 61 days ^[13]. That is one day over the 60-day minimum Anthropic's documentation commits to for publicly released models ^[7]. The post calls 61 days "on the longer side" of the notices it has tracked ^[16]. Its own dates put it at the short end. Sonnet 3.7 had 114 days between notice and retirement, and Sonnet 4 had 62 ^[9][14][15]. Of the three Sonnet windows the post lists, this one is the shortest ^[17].

On cost, the post compares two properties. Per the post, claude-sonnet-5-5 is priced the same and shares the 1M token context window ^[3]. It does not report how the two models' outputs differ. The swap is free only if prompts tuned against 4.5 behave the same on the new model, and a team's own evals are the check on that.

The alias also changes what the string promises. A rolling name follows whichever version is current ^[10], so the next model change arrives with no edit and no failed request. For one-off scripts that nobody revisits, I think that is the right choice. A silent upgrade is easier to live with than a hard failure. For anything with an eval suite or an output contract, I'd pin a dated snapshot again and put its retirement date in the calendar.