Beyond the ModelAI · systems · incentives · consequences

Editions / The Disappearing Model

Edition 4 · 03 / 06

Models Have Expiry Dates

The published lifecycle evidence shows why AI infrastructure can have a shorter and more provider-controlled life than it appears.

By Dr Gary Marrs PhD · · 5 min read

Model lifecycleSupplier riskEvidenceResilience
A sequence of engineered modules along glowing rails progresses towards empty spaces where later components have been removed
Article summary

The premise of this edition is not that every model will disappear without warning. It is that a named model is a managed product with a lifecycle controlled by someone other than the organisation that has built a service around it.

That is not a speculative risk. Major providers publish retirement, deprecation and lifecycle material because change is part of operating the platform.

A dependency has two clocks

The provider’s clock begins when a model is introduced, moves through active use and, eventually, legacy, deprecation or retirement. The customer’s clock begins later, when an application becomes optimised around that model and real people start depending on the resulting workflow.

The lifecycle behind a production dependency
  1. 01Model introducedA new capability becomes available.
  2. 02Application optimisedPrompts, tools and controls learn its behaviour.
  3. 03Dependencies accumulateCustomers and teams depend on the resulting workflow.
  4. 04Provider changes modelA retirement, restriction or change requires a decision.
  5. 05Customer migrationThe replacement must restore the business outcome.

Provider lifecycle notices describe a model. Organisations still need to assess the service that has formed around it.

The two clocks need not align. A provider may offer notice, documentation and a successor. The customer still has to determine whether the successor can perform the established work, meet the same controls and preserve the service it has promised.

What the providers publish

OpenAI’s API deprecations documentation says that models and endpoints are regularly retired, sets out notice-period expectations and explains that a shut-down model or endpoint is no longer accessible. Its policy distinguishes the treatment of generally available, specialised and preview models.

Anthropic’s model deprecations documentation describes active, legacy, deprecated and retired stages. It states that requests to retired models fail, and records replacement guidance and schedules for named models.

Google’s Gemini API deprecations documentation publishes model shutdown dates, including separate treatment for stable and preview availability. AWS Bedrock’s model lifecycle documentation uses Active, Legacy and End-of-Life states, recommends reviewing each model’s lifecycle policy, and states that requests fail once a model reaches end of life.

Microsoft Foundry also publishes model retirements, including notification and migration information for models made available on the service.

These documents are not evidence that any provider is unreliable. They are evidence that infrastructure based on frontier models is dynamic. A customer should treat the notice period as time to assess and execute a migration, not proof that a migration will be effortless.

Availability can change before retirement

Lifecycle notices are not the only path to interruption. A model can become effectively unavailable through an outage, a regional restriction, a rate-limit change, a feature withdrawal, a commercial change or a safety decision that makes it unsuitable for its current role.

For example, OpenAI’s 24 June 2025 incident write-up records an API-routing misconfiguration that caused most /v1/chat/completions requests to fail for about 13 minutes. That is a short incident. For a service with no safe reduced mode, it can still be a customer-facing failure.

The important distinction is between a model being available to call and being available for the business purpose. A live endpoint that now exceeds a latency limit, loses a required capability or produces results that no longer meet the control standard has disappeared from the service’s point of view.

Does a cloud marketplace remove the dependency?

Platforms such as Azure AI, AWS Bedrock and Google Vertex can offer a broader route to model access, centralised procurement and useful operational controls. They may reduce some forms of integration or contracting friction.

They do not make a model’s behaviour universal, nor do they automatically supply a validated fallback. The model offering, regional availability, lifecycle terms and migration path remain part of the service a customer has chosen. This is an inference from the published lifecycle documentation, not an argument against marketplaces: the intermediary adds another operational layer that must be understood.

Open-weight alternatives can broaden options in other circumstances, but do not automatically make a workload portable either. Hosting, operational capacity, licensing, safety controls and evaluation work still determine whether an alternative can restore the service.

Treat lifecycle information as an operational input

A sensible review asks which models support critical services, whether they have a published lifecycle policy, who receives notices, what a successor would need to prove, and what business commitments depend on the answer. The same questions should be asked of AI-enabled suppliers: a supplier’s model retirement can become the customer’s service change.

Model change is therefore not an exceptional event to predict perfectly. It is a normal condition to design and budget for proportionately.

If change is inevitable, how much should an organisation spend on the ability to respond?

References