Ask most AI governance teams how much warning they get before a provider deprecates a model, and they usually answer with some version of “ninety days.” That number shows up so often in vendor materials and internal planning docs that it has quietly become the assumed baseline. No provider guarantees it across the board, though, and many avoidable incidents start in the gap between that assumption and what providers actually publish.
What the Providers Actually Publish
The deprecation policies of the two largest model providers paint a more fractured picture than the ninety-day shorthand suggests.
Anthropic publishes a flat minimum: it gives at least 60 days’ notice before it retires a publicly released Claude model, and it emails customers with active deployments. That is a clear, single number, but it is 60 days, not 90, and it covers only publicly released models. Recent retirements follow that pattern closely. Anthropic sends deprecation notices roughly two months before the retirement date.
OpenAI tiers its policy instead of setting one flat number. It gives generally available models at least six months of notice. It gives specialized variants, including certain chat, coding, and research-focused models, at least three months. It can retire preview models with far shorter notice, in some cases as little as two weeks, and many teams adopt those preview models early precisely because they want newer capabilities.
Put those two policies side by side, and the range runs from two weeks to six months, depending on which provider, model, and tier you run in production. You have no single number to plan around. You have a range, and where each model in your stack falls in that range depends on details most teams do not track model by model.
What This Has Looked Like in Practice
The gap between the assumed number and the real one plays out in practice. Anthropic’s own published retirement history shows its deprecation notices consistently matching the stated 60-day minimum: it flags a model for deprecation and sets a retirement date roughly two months out. That is a provider following its own policy closely, which is the best case.
OpenAI’s tiered structure produces more variation. OpenAI has announced retirements of generally available models with the promised six months of runway. But the shorter-window categories exist because some models genuinely retire faster. Picture a team that remembers only the six-month figure from a generally available model’s retirement. The first time a preview or specialized variant it adopted early receives its own, much shorter notice, that notice will catch the team off guard. OpenAI publishes its policy and applies it consistently. What any given team experiences still depends entirely on which model tier it built on.
Why This Matters More Than It Looks Like It Should
A governance program that plans around a single assumed number, ninety days or otherwise, works fine until it meets a model that does not follow that number. Suppose a team treats “we get ninety days” as a planning assumption, and one of its production agents quietly runs on a preview model with a two-week retirement clock. The gap between assumption and reality is not a rounding error. It separates a manageable migration from an emergency one.
The way enterprise AI estates look today makes this risk worse. Very few organizations run a single model from a single provider. A typical production environment mixes generally available models for stable workloads, specialized variants for narrower tasks, and preview models for teams that chase the newest capability, often across more than one provider at once. Each one has its own notice window, and none of them tells a team which category it falls into when the team decides to build on it.
The risk also multiplies across teams within the same organization. The team that built an internal tool on a preview model six months ago, because it needed a specific new capability, may not be the team that now keeps a governance calendar that assumes ninety days. Nobody did anything wrong. The engineers made a reasonable call when they chose the preview model, and the governance team made a reasonable simplification when it assumed ninety days without auditing every model tier in production. The two reasonable decisions just do not fit together, and the mismatch surfaces only on the day a two-week notice arrives for a model nobody remembered was still running.
What Actually Reduces the Risk
Memorizing every provider’s published policy and hoping it stays current does not fix this. Providers change these policies, and they do not always apply them with perfect consistency. The real fix removes the need to know the policy at all: you track every deprecation notice automatically, the moment it arrives, for every model that runs in production.
That takes two things most teams do not pair today. First, a live, current inventory that shows exactly which model version powers every agent in production. Second, a monitoring layer that watches provider deprecation channels and attaches each notice to the affected agents the moment the provider issues it, so nobody stumbles on it later during a routine check. Without the inventory, a team cannot tell which agents a notice puts at risk. Without the monitoring, a two-week preview model notice can come and go before anyone reads the email that carried it.
The ninety-day assumption feels comfortable because it implies you always have enough time to react. The published policies say otherwise: some of your production models do not come with that kind of runway. The only reliable way to know which ones is to track the actual notice for the actual model, not the number everyone assumes applies to all of them.
Optimize your model change process around the notice you’ll actually get, not the one you’re assuming. Request a demo and see every deprecation deadline in your stack today.
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.