How Long a Model Stays Current: Measuring Deprecation Properly

Model lifespan is measurable, because retirement dates are published contractual commitments rather than opinions. What makes published averages wrong is that people measure two different intervals and call both of them the same thing.

Two different quantities

Both of these are real and useful, they differ by a large factor, and almost every article about model lifespans conflates them.

A model can have a long service life and a short notice period, or the reverse, and the two failure modes they cause are completely different. A short notice period is an operational emergency. A short service life is a procurement and pricing problem.

Deprecated, legacy, retired, shut down

Vendors use these words inconsistently, and measuring without pinning them produces nonsense. The definitions below are the common industry usage; check each vendor’s own page for its exact meaning, because only the shutdown date is contractual.

That last row is the one that causes the most production incidents, because nothing is deprecated and nothing fails — the outputs just change. It is covered in silent model updates and in model degradation.

Where the dates actually live

Five primary sources carry dated lifecycle information. These are the only things worth measuring; anything else is a summary of them.

• OpenAI’s deprecations page. A running, reverse-chronological log of deprecation announcements with shutdown dates and recommended replacements. Historically the announcements for older Completions-era models gave roughly six months of notice.
• Azure OpenAI’s model retirements page. The most machine-readable of the five: a dated table of models with their retirement dates, updated in place. Because Microsoft has enterprise support commitments, this page is unusually precise and is worth diffing on a schedule.
• Anthropic’s model deprecations documentation. States its deprecation policy and lists deprecated model identifiers with dates.
• Google’s Gemini and Vertex AI model versioning pages. Document the versioning scheme, the difference between a stable and a preview alias, and the retirement dates for each version.
• AWS Bedrock’s model lifecycle documentation. Defines its lifecycle stages explicitly and lists which models are in which stage.

The measurement procedure

1. Fix your population before you start. “All models” is not a population — preview models, fine-tuning base models and embedding models have very different lifecycles, and mixing them produces an average that describes nothing.
2. For each model record five fields: vendor, model identifier, GA date, deprecation announcement date, shutdown date. Record the date you collected each row.
3. Get GA dates from the vendor’s release blog rather than the deprecation page, which usually does not carry them.
4. Compute both intervals in days: notice = shutdown - announcement and service_life = shutdown - ga.
5. Report the median and the range, never the mean. The distribution has a long tail — a handful of models are kept alive for years for one large customer — and a mean is dragged past every model anyone actually experienced.
6. Exclude models that are still live from any service-life statistic, or state clearly that you are reporting a censored distribution. Including still-running models as though their life had ended understates it; excluding them overstates how quickly models die, because the survivors are exactly the long-lived ones. This is the standard survival-analysis trap and it is where most informal estimates of model lifespan go wrong.
7. Re-run monthly by diffing the vendor pages. A diff of Azure’s retirement table month over month is the single highest-value line in the whole procedure: it catches both new deprecations and quietly extended dates.

The snapshot trade-off

Every provider offers two ways to name a model, and choosing between them is choosing which failure mode you prefer.

Alias:     "model-name"
           Always maps to whatever the vendor currently considers current.
           Never 404s. Behaviour changes without notice.

Snapshot:  "model-name-2026-05-14"
           Fixed weights. Reproducible. Has a shutdown date, after which
           requests fail with a model-not-found error.

You cannot have both. Pin and accept a hard deadline, or float and
accept silent drift.

For anything with an evaluation suite, pinning is nearly always right: a hard error on a known date is a scheduling problem, while a silent behaviour change is a debugging problem that can run for weeks before anyone notices. The counter-case is a low-stakes internal tool where nobody will do the migration work, in which case an alias that keeps working is the honest choice.

If you pin, add the shutdown date to the same calendar that holds certificate expiries. It is the same class of failure: known in advance, catastrophic if missed, invisible until the day.

Planning around it

• Keep an evaluation set that does not depend on the model. The cost of a forced migration is almost entirely the cost of establishing that the replacement is acceptable. With an eval suite that runs in an afternoon it is routine; without one it is an open-ended project. See building an eval harness.
• Do not put model identifiers in your source. One configuration value, one place to change it, and the migration is a deploy rather than a search-and-replace. See model feature flags.
• Test the failure. Point staging at a retired model identifier and confirm your application degrades the way you intended rather than returning an unhandled exception to a user.
• Expect prompts to need work. A replacement model rarely responds identically to the same prompt, and the differences concentrate in output format and instruction adherence rather than in capability. Budget for it — prompt portability covers what usually breaks.
• Watch open-weights models as a floor. A model whose weights you have downloaded cannot be retired by anyone. That is a genuine operational property rather than an ideological one, and it is the strongest argument in an open-model strategy.