Every AI model has a retirement date. Is anyone tracking yours?
By Lindsey J
A model deprecation notice reads like routine email traffic until its retirement date arrives and a production call starts failing. At that point it stops being a vendor's schedule and becomes a support queue.
Every foundation model a vendor ships carries a retirement date, whether or not anyone on a product team has gone looking for it. The gap this creates is not a research problem. It is a calendar problem, and most teams do not have the calendar.
What a model deprecation notice actually promises you
Anthropic gives at least 60 days' notice before retiring a publicly released model, per its own model deprecation documentation. Once that date passes, the company says requests to the retired model will fail entirely.
OpenAI's notice period depends on the kind of model involved, according to its own deprecations page. A generally available model gets at least six months' notice, and a specialized variant, such as a chat, Codex, or deep research model, gets at least three months, except when OpenAI says safety or compliance concerns require a faster timeline. A model whose name contains "preview" carries no stated floor. OpenAI cites two weeks only as an example of how much shorter that notice can run, not as a guaranteed minimum.
Three different clocks, from two vendors, sit inside whatever a team calls "the model" in its own code. The clock that matters for a given integration is whichever one it actually runs on, not the one its team assumes.
The deadline that matters is the shortest one you are exposed to
A product calling three models across two vendors is governed by whichever notice period is shortest, no matter how long the others run. A six-month notice on the primary chat endpoint does nothing for a two-week preview endpoint quietly running a background feature.
Decision rule: list every model string the product calls in production, including anything used only in a background job, an eval harness, or a fallback path. Find each one's retirement date, or confirm it is still Active and carries none yet. The nearest date on that list is the real deadline, regardless of how far out the rest sit.
Picture a team that pinned a real-time, preview-tier model to a voice support line because it tested best in a sprint. Six months later the team migrates its main chat model ahead of that model's generally-available retirement date and calls the project finished. Two weeks after that, the preview model it forgot about stops accepting requests mid-shift, because nobody was tracking the shorter clock running underneath the one everyone remembered.
Meeting the deadline is not the same as testing the replacement
A retirement date does not test anything by itself. It only forces a substitution on a fixed day. Whether that substitution is safe is the same question a team already answers when it changes its own prompt: does the replacement still clear the checks the current model clears today, or does it only produce an answer that looks plausible.
A team that already runs an eval suite before shipping its own prompt changes has most of what a vendor-driven swap needs. A deprecation date just adds a second trigger for the same gate, on a schedule the team did not choose.
Before your next retirement date arrives
- Do you know the exact retirement date, not just the model family's reputation, for every model your product calls in production?
- Is that date on a calendar with a named owner, or only sitting in a vendor email that will scroll past?
- Do you have a passing eval suite you could run against the replacement model today, before the deadline forces it?
- Does any integration call a model by a floating alias such as "latest," and do you know which models that alias is allowed to silently become?
FAQ
Does this apply if a product never pins a specific model version
Calling a floating alias instead of a pinned snapshot does not remove the clock. It moves the decision to the vendor, so the product gets a new model on the vendor's own timetable instead of its own, with no retirement notice to plan around. That trades a scheduled risk for an unscheduled one. It does not remove the risk.
Does self-hosting a model remove this risk
Self-hosting removes a vendor's retirement date. It does not remove the need to test a model upgrade before adopting it, since an open-weight model's own maintainers still ship new versions and eventually stop patching old ones.
How often should a team re-run this audit
Set a reminder the day a model is adopted, tied to whatever retirement date is published at that point. Re-check the audit whenever a vendor updates its own deprecation documentation, since a model's status can move from Active to Deprecated without an email reaching every team that calls it.
A deprecation calendar and an eval gate are work most product teams can build themselves in a day. Making that governance part of how an agentic product gets designed, rather than bolted on after the first outage, is where Aero works. Get in touch.
