Claude's Model Deprecation Policy and Retirement Notice Window

A hosted model is a service, and services are withdrawn. Anthropic publishes both a policy for how that happens and a dated table of which models it has happened to. Only one of those two is safe to copy onto another web page.

The four lifecycle states

Anthropic’s deprecations documentation describes a model as moving through a defined sequence rather than simply disappearing:

• Active. Generally available, recommended, fully supported.
• Legacy. Still served and still working, but superseded. A newer model in the family is the recommended target and the legacy one is no longer where improvements land. Nothing breaks at this stage; it is a signal.
• Deprecated. Formally announced as going away, with a retirement date attached. The model continues to serve requests normally throughout. This is the window in which you are expected to migrate.
• Retired. No longer served. Requests naming that model id fail.

The distinction between legacy and deprecated is the one worth internalising, because they feel similar and only one of them has a clock. A legacy model can sit in production for a long time. A deprecated model has a date, and the date is real.

The states are also the thing to build your process around, because they are stable while the dates are not. The policy has held its shape across several model generations; which specific snapshot is in which state changes several times a year. A runbook that says “when a model we call enters Deprecated, open a migration ticket” keeps working indefinitely. A runbook containing a list of dates is a document that quietly stops being true.

One asymmetry to note: entering Legacy is a reason to plan and not a reason to act, and treating it as urgent is its own cost. Teams that migrate on every announcement spend a meaningful share of their engineering time chasing a model line that is moving faster than their product is. The state that requires action is Deprecated.

The notice window

The commitment Anthropic has published is a minimum notice period between the deprecation announcement and the retirement date, stated at the time of writing as at least 60 days. Deprecation is announced through the documentation and communicated to affected organisations rather than surfaced in the API response, which is the operationally awkward part: nothing in a successful request tells you the model you are calling has been deprecated.

Sixty days sounds generous and is not, once you count what has to happen inside it. A migration is: identify every call site and every stored prompt tuned against the old snapshot, run the evaluation set on the successor, fix the prompts that regressed, re-baseline any quality metric you report to somebody, and roll out. If your evaluation harness does not exist yet, the sixty days starts with building one. Teams that find this comfortable are the ones that already had the harness.

There is a second reason the window compresses. Announcements cluster: a new model generation often means several older snapshots are deprecated together, and if you use a small model for classification and a large one for generation, you may be migrating both at once.

What a retired model returns

After retirement, the model id simply does not resolve. The request fails at validation, before any generation, with a not-found error:

HTTP/1.1 404 Not Found

{
  "type": "error",
  "error": {
    "type": "not_found_error",
    "message": "model: claude-3-sonnet-20240229"
  }
}

Two properties of that failure matter for how you handle it. It is a 404 and not a 5xx, so a retry policy built around transient errors will not retry it — correctly, because retrying will never help. And it is total: every request to that id fails from the retirement moment onward, so there is no degraded period in which some requests succeed and you notice the problem gradually.

The same error shape appears for a typo in a model id, which is worth knowing when you are debugging: claude-sonnet-4.5 with a dot instead of a dash produces exactly this response, and it is not a deprecation at all.

Because the failure is total and instant, the recovery you want is not a code change. If the only place your model id appears is a configuration value, restoring service is an environment variable and a restart; if it appears in six services and a database of prompt templates, it is an afternoon. The difference between those two outcomes is decided long before the retirement date, which is the argument for treating model ids as configuration from the first commit rather than after the first incident.

Open weights do not have this problem

It is worth naming the structural difference rather than treating deprecation as a vendor failing. Anthropic serves the model; there is no copy of the weights you can keep. When the service stops, the capability stops, and no amount of contractual care changes that.

A model whose weights you can download has the opposite failure mode: nobody can retire it, and equally nobody is patching it, hosting it or improving it for you. The cost moves from “migrate on somebody’s schedule” to “operate it forever on yours”. Neither is free. The decision belongs at architecture time, not at deprecation time, which is the practical reason to know this policy before you need it.

There is one narrow case where the distinction becomes a compliance question rather than an engineering preference: a regulated process whose auditability depends on being able to re-run a decision years later. A hosted model cannot promise that, and no notice period changes it. If that constraint is real for you, it belongs in the design discussion at the start, alongside the far more common finding that what actually has to be reproducible is the recorded output and the inputs that produced it, not the model itself.

What to actually put in place

1. Know which ids you call. One place in configuration per model role, so the answer to “are we affected” is a file rather than a grep across services. See model version pinning.
2. Make sure the deprecation email reaches a human. Notices go to the organisation, which frequently means an address that was set up during signup and has been unread since.
3. Keep an evaluation set that runs on demand. Twenty to fifty real inputs with known-good outputs is enough to turn a migration from a guess into a diff. This is the single highest-value preparation and the one most often skipped.
4. Handle not_found_error distinctly from rate limits and overloads. It should page someone, not enter a retry loop.
5. Have a named successor before you need one. The model you would move to, written down, so the migration decision is already made when the notice arrives.