Every AI model you run has a retirement date.
Model retirement has become a routine, documented stage of the AI supply chain: both major providers publish shutdown calendars months in advance, and any process built on one specific model version inherits a date set by someone else. The practical response is not slower adoption — it is designing for substitution.
Anthropic and OpenAI both publish formal deprecation policies for their models, and both are executing them. Anthropic commits to at least 60 days’ notice before retiring a publicly released model. OpenAI commits to at least six months for generally available models and at least three months for specialised variants — its chat, coding and deep-research versions — while preview models may go with much shorter notice, two weeks in the documentation’s own example. OpenAI adds that it does not recommend preview models for business-critical production workloads unless the user can migrate at short notice.
Between now and January 2027, the two firms’ published calendars assign retirement dates to dozens of models and, in OpenAI’s case, to several entire products. For a company whose quotation, customer-service or document workflow calls one of these models, the practical meaning is direct: part of the process carries an expiry date, and the date was set by someone else.
Retirement is now a documented product stage, not an incident
Anthropic’s documentation defines a four-stage lifecycle. A model is active while fully supported; legacy once it stops receiving updates; deprecated when it remains functional but has a named replacement and an assigned retirement date; and retired when it stops existing as a service — in the documentation’s words, “requests to retired models will fail”. OpenAI’s terminology runs in parallel: a model becomes deprecated on the day its shutdown is announced and inaccessible on the shutdown date itself. Both firms publish complete tables of past and scheduled retirements, and OpenAI reserves the right to move faster where safety or compliance requires it.
Anthropic goes one step further and states the reason plainly: models are retired to free serving capacity for new releases. Its table also assigns every currently active model a tentative earliest retirement date — the nearest of them falling in the autumn of 2026. In November 2025 the company committed to preserving the weights of all publicly released models for at least its own lifetime, and wrote that it hopes to make past models available again at some point. That commitment matters for research continuity, but a preserved weight file is an archive, not a service a workflow can call.
The calendar through January 2027 is already written
The retirements are not hypothetical. Anthropic has retired models on five separate dates in the first eight months of 2026, most recently Claude Opus 4.1 on 5 August, announced on 5 June — two months’ notice, just above the 60-day floor the policy promises. Claude Sonnet 4 and Claude Opus 4 were retired together on 15 June, announced on 14 April. Each announcement names a recommended replacement.
OpenAI’s forward schedule is longer and broader, because it covers products as well as models. The Assistants API closes on 26 August 2026, replaced by the newer Responses and Conversations APIs. The Sora 2 video models and the Videos API follow on 24 September. A set of legacy models including GPT-3.5 Turbo and GPT-4 shuts down on 23 October. Agent Builder and the Evals platform close on 30 November. On 11 December, the original GPT-5 and o3 snapshots go — the first GPT-5 snapshot is dated 7 August 2025, giving that version a service life of just over sixteen months. Legacy audio, realtime and transcription models end on 20 January 2027.
A hosted model is a supplied service, and each channel adds its own dates
The mechanism worth understanding is the difference between this dependency and the software dependencies companies already manage. A licensed ERP version can be run, unsupported, for years after its vendor moves on. A hosted model cannot: on the retirement date the service stops answering, whatever depends on it.
Distribution then multiplies the calendars. Microsoft’s Foundry platform — a common route to these models for European firms on Azure — assigns each generally available model a retirement date at launch, eighteen months out, with a deprecation stage at twelve; models supplied through it by partners, including Anthropic and Mistral AI, live twelve months. Microsoft’s documentation is unambiguous that retirement dates are not extendable, and notes that standard deployments are switched automatically to a successor while reserved-capacity deployments are not upgraded automatically — migrating them is the customer’s task. Anthropic’s own page states that Amazon Bedrock and Google Cloud set their own retirement schedules, so the same model can carry different dates on different platforms.
Substitution, finally, is not a formality. Successor models behave differently: prompts tuned for one version produce different outputs on the next, which is why the providers’ migration guidance says the same thing — test the replacement against your own cases, well before the deadline.
Swiss and European firms are adopting this layer faster than they are mapping it
The dependency is growing quickly. Eurostat’s ICT survey, published on 11 December 2025, found that 20.0% of EU enterprises with ten or more employees used AI technologies in 2025, up from 13.5% a year earlier. Most of that use runs through off-the-shelf tools and embedded software features rather than systems firms built themselves, which means the model dependency is usually inherited through a vendor rather than chosen directly.
Switzerland’s clearest institutional reading of that dependency comes from its financial supervisor. A FINMA survey of around 400 institutions, published on 24 April 2025, found that about half already use AI or have first applications in development, with a further quarter planning adoption within three years — and that smaller institutions in particular often rely exclusively on externally developed applications. FINMA’s Guidance 08/2024, issued on 18 December 2024, sets out what it expects in response: an inventory of AI applications, assessment of the third-party dependencies they create, systematic testing and ongoing monitoring. The guidance binds supervised financial institutions only. But as a description of what it takes to depend safely on someone else’s model, it reads as a sensible baseline for any firm — and model retirement is precisely the moment at which an inventory, a dependency map and a test routine stop being paperwork.
Substitution is a capability, and it can be built before it is needed
None of this is an argument for slower adoption. It is an argument for building, deliberately, the ability to change models without rebuilding processes. Four decisions are available to any firm now:
- Keep an inventory of model dependencies. Record which workflow calls which model version, directly or through a supplier. Anthropic’s console can export usage by API key and model; Microsoft exposes lifecycle status programmatically. For embedded AI features, the question belongs in the next vendor review: which models sit behind the product, and what is the migration commitment when one retires.
- Route calls through one point of substitution. A single abstraction layer — a gateway or one configuration entry — instead of model names hard-coded across applications turns a retirement from a rewrite into a configuration change.
- Maintain an evaluation set. Fifty to a hundred real cases from the firm’s own work, with accepted outputs, allow a candidate replacement to be qualified in days rather than months. Providers recommend exactly this; Microsoft’s migration guidance is explicit that candidates should be judged on the firm’s own data rather than on public benchmarks alone.
- Match the model tier to the criticality of the process. Preview models do not belong in business-critical workflows — the supplier’s own advice — and on cloud platforms it is worth verifying whether a deployment upgrades automatically at retirement or simply stops.
The dates that will carry information
The published calendar gives the next six months a clear rhythm: 26 August, 24 September, 23 October, 30 November and 11 December 2026, then 20 January 2027 — each a date on which running integrations somewhere will stop working unless they have been moved. Anthropic’s table of tentative retirement dates for currently active models deserves the same attention, because it states today the earliest date on which each model now in production may go.
The deeper point outlasts any single date. What persists across model generations is not the model but what the firm builds around it: its data, its documented processes, its evaluation cases and its practised ability to requalify a replacement. Companies that treat the model as an interchangeable part will experience retirements as maintenance. Companies that treat it as a fixture will experience them as a schedule of small emergencies, timed by their suppliers.