On October 14, OpenAI told developers that GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini will be removed from its API on January 14, 2027 (OpenAI). That is three months' notice. The same page says generally available models get "at least 6 months", unless safety or compliance concerns require a faster timeline. OpenAI gave no reason for the shorter window.
If one of your AI features calls one of those models, and your organization freezes production changes at year end, the migration window is shorter than it looks.
This is not a one-off. Last week, on October 23, OpenAI shut down a dozen older model snapshots, including gpt-4, gpt-4-turbo, o1, o3-mini and o4-mini, plus a separate list of fine-tuned models. Fine-tuned models, the page notes, "follow the same shutdown schedule as their underlying base models." Anthropic is scheduled to retire Claude Sonnet 4.5 on November 30 (Anthropic). OpenAI's GPT-5 snapshots go on December 11.
Every AI feature you run depends on a model that someone else can retire. It is easy to choose that model once, at the start of a project, and never look at it again.
The notice periods, and why they are not the number to plan around
The published policies, from the vendors' own pages:
- OpenAI: at least six months for generally available models, three months for specialized variants, and as little as two weeks for previews.
- Anthropic: "at least 60 days' notice before model retirement for publicly released models." After that, "requests to retired models will fail."
- Azure OpenAI in Microsoft Foundry: at least 60 days for GA models. GA models stop accepting new customers at 12 months and return
410 Goneat 18 months from launch (Microsoft Learn). - Google Vertex AI: a retirement date is announced once the next stable version is released, and new access is blocked one month before that date (Google Cloud).
- Amazon Bedrock: for models launched since September 7, 2026, a Legacy period of six months or 45 days before end of life. Existing customers "may lose access after 15 days of inactivity" during it (AWS).
Three things make these numbers less reliable than they look.
The notice you get can be shorter than the policy. The GPT-4o announcement above is the current example.
The date depends on how you call the model. gpt-4o-2024-05-13 shut down on OpenAI's own API on October 23. Microsoft's schedule, updated September 21, shows the same version retiring on Azure on December 9 (Microsoft Learn). Anthropic's page says Bedrock and Google Cloud "set their own retirement schedules." One tracker found Claude 3 Haiku retiring on three platforms on dates up to 143 days apart (BenchLM).
The date moves. Articles published this summer gave earlier Azure retirement dates for GPT-4o versions than Microsoft's current schedule shows. A spreadsheet built from a blog post in June is already wrong. Only the vendor's page for the route you actually use counts, and it has to be checked again.
The quiet failure is worse than the loud one
When a model retires on OpenAI, Anthropic or Bedrock, requests fail. That is disruptive, but obvious. Someone gets paged and the cause is clear.
Some configurations don't fail. On Azure, "for Global Standard, Data Zone Standard, and Standard deployment types, Microsoft manages automatic upgrades when a model version is retired," rolling region by region. Provisioned deployments are not upgraded. On Vertex AI, an auto-updated alias "automatically points to the new version" when a new stable model is released. The Azure page does not warn that the replacement may behave differently, and Google gives no stated notice before an alias moves.
Replacements can behave very differently. The best-known measurement is old but still instructive: in 2023, researchers found that GPT-4's accuracy at identifying prime numbers fell from 84% to 51% between its March and June versions, and that its instruction-following got worse (Chen, Zaharia and Zou). Their conclusion was the need "for continuous monitoring of LLMs." More recently, an engineer at Thematic reported testing a much newer model on a task with complex, multiple instructions, and found the older model "outperformed it significantly" (Thematic).
The cost that gets missed in a swap is not the token price. It is re-testing. One practitioner described a model swap budgeted at two weeks that took seven more weeks to rebuild the evaluation baseline: reference scores, automated judges and test fixtures all tuned to the old model (Tian Pan). That is a single anecdote, not a benchmark. But the pattern is easy to recognize: teams that never wrote down what "good output" looked like have nothing to test the replacement against.
Consider a hypothetical mid-market insurer with a claims-summary feature on GPT-4o through OpenAI's API. It learned on October 14 that the model goes on January 14. Its change freeze starts in mid-December. Realistically it has about nine weeks to pick a replacement, re-test summaries against cases its adjusters trust, get sign-off and deploy. If there is no saved test set, most of that time goes into building one.
Treat the model like a database version
You would not pick a database version once and forget it. You track its end of support, assign an owner and plan upgrades. Models need the same treatment, on a shorter clock.
Keep a register. For every AI feature: which model and version it calls, through which route (direct API, Azure, Bedrock, Vertex), who owns it, its retirement date from the vendor's page, and when that was last checked. Review it monthly and before every freeze window.
Pin versions, and choose how they fail. Call explicit model versions in production, not floating aliases. On Azure, decide deliberately between automatic upgrades and NoAutoUpgrade, which stops the deployment working at retirement. A loud failure you planned for beats a silent change nobody tested.
Keep the model behind a thin layer. Model ID in configuration, prompts versioned alongside the model they were tuned for, and one place in the code that calls the vendor. Then a swap is a config change plus a test run, not a hunt through the codebase. This is the same reasoning as our post on vendor lock-in.
Save an evaluation baseline per feature. A few dozen to a few hundred real inputs, with the outputs your users accepted. When a retirement notice lands, run the candidate model against it and see exactly where it differs.
Make the swap a standard change, not a special event. Longer approval cycles are the wrong response. DORA's 2019 research found that heavyweight external change approval did not reduce change failure rates, and tended to push changes into larger, less frequent batches (DORA). A model swap backed by recorded test results and peer review can be pre-approved as a routine change type. With retirements now arriving several times a year, it will need to be.
Look 180 days ahead before every freeze. Anything retiring during or just after a freeze needs to move before it starts.
We build AI features with the model behind an abstraction and a test baseline from day one. If your next retirement notice would land on a team with neither, let's talk.