Do AI models get retired?

Yes, on published schedules. Anthropic documents a lifecycle (active, legacy, deprecated, retired) with recommended replacements and retirement dates; OpenAI maintains an equivalent deprecations page. Any system pinned to a model version inherits that calendar, whether or not anyone diaried it.

What happens to an application when its model is retired?

Every call to the retired version fails. If nobody planned for it, the failure arrives as a production outage on the provider’s schedule: in our own case, a booking agent whose chat silently returned nothing because the model underneath it had passed end of life.

Is migrating to a newer model just changing the model name?

No, and this is the expensive surprise. Newer models can reject parameters the old one accepted, and their behavior shifts: tone, thoroughness, boundary-keeping. A safe migration audits every parameter, re-runs golden conversations, and reads the diffs before production traffic arrives.

What should a business demand from vendors about model lifecycles?

Four things in the runbooks: model versions pinned and inventoried, provider deprecation dates tracked with alerts, a rehearsed migration procedure with eval re-runs, and monitoring that catches silent degradation. A vendor without a deprecation answer is shipping systems with expiry dates they have not read.

Models retire. Plan for it.

The short answer

Every LLM-powered system inherits its provider's deprecation calendar: models move from active to deprecated to retired on published schedules, and applications pinned to a retired version stop working on someone else's date. The defense is operational, not clever: inventory your model versions, diary the provider's dates, rehearse the migration, and gate it with eval re-runs, because a model swap is a behavior change wearing a one-line diff.

A model ID in your codebase looks like a configuration value. It is a dependency with an expiry date, published by the provider, unread by almost everyone. We know exactly how that story goes because it happened to us, in production, in our own funnel.

The calendar you inherited

The providers are not coy about this. Anthropic's deprecation documentation defines a full lifecycle (active, legacy, deprecated with a retirement date and a recommended replacement, retired and unavailable) and commits to notifying customers as models move through it. OpenAI maintains the equivalent page. The dates exist, the emails go out, and the outages happen anyway, because in most organizations nobody owns the mapping between "model IDs in our code" and "dates on those pages." That mapping is the entire discipline.

What retirement looks like from inside

Ours arrived in June: the booking agent's chat opened, streamed nothing, and closed. Every dashboard stayed green while the funnel sat mute for anyone who tried it. The model our code requested had passed its end of life while the system was quietly running. The full field note has the two subtler failures behind the outage: the successor model rejected sampling parameters the old one accepted, and its behavior shifted enough to leak an internal summary into the client-facing chat. One retirement, three lessons, all of them now procedure.

A model ID is a dependency with an expiry date. Almost nobody diaries it, and the outage arrives on the provider's schedule.

The migration playbook

01Inventory the model IDs. One constants file, never scattered across call sites. You cannot diary dates for versions you cannot list.
02Diary the provider dates. The deprecation pages above go into the team calendar the day a model ships to production, with alerts months ahead of retirement.
03Rehearse before you are forced. Migrate on your schedule, in staging, while the old model still answers. Forced migrations happen during outages; rehearsed ones happen during coffee.
04Audit every parameter. Temperature, sampling settings, token limits: treat the successor’s API contract as stricter until every call site proves otherwise. Ours returned 400s on three call sites tuned years earlier.
05Re-run the golden set and read it. Errors are the easy failures. Behavior drift (tone, verbosity, boundary-keeping) only shows up when evals re-run and a human reads the diffs.
06Watch for silence after the switch. Alarm on empty responses, not just error codes. The most expensive failures in this category return HTTP 200.

What to demand from vendors

If someone builds your system, their answer to "what happens when the model retires" tells you whether they operate software or deliver it and wave. The playbook above should exist in the runbooks they hand over, the eval suite should be the migration's safety net, and a blank look at the question is one of the cleaner red flags this market offers. Model retirement is not an edge case. It is production AI doing what production always does: continuing after launch day, on a calendar someone else controls.