AI model deprecation & migration calendar

Updated October 22, 2026 · verified from official provider docs

As of October 22, 2026, the next AI model retirement is gpt-3.5-turbo-0125 (OpenAI) on 2026-10-23, migrate to gpt-5.6-terra.

When each AI model is retired, what to migrate to, and how much notice each provider gives. 264 records tracked across 5 providers. Every date comes from the provider’s official deprecation page, linked per row — nothing here is estimated, and where a provider named no successor we say so instead of guessing.

Which AI models are being retired next?

How much notice does each AI provider give before retiring a model?

Every provider publishes its own dates; none of them publishes the gap between the two. This table is that gap — announcement to shutdown, computed from 213 records that carry both dates. It answers the question you actually have before committing to a provider: when the next retirement notice lands, how long will you have to act?

Median rather than mean: with a spread this wide the average describes the outliers, not the typical case. The shortest column is the one worth planning around.

Which AI provider gives the least warning?

Cohere — median 0 days across 14 tracked models, against OpenAI at 184 days. The tightest single notice on record is 0 days: open-codestral-mamba (Mistral) was announced 2025-06-06 and shut down 2025-06-06. A median near zero does not mean the provider is careless — it means retirements there are announced at the moment they take effect, so a pinned model version can stop working the day you read the notice. That is a planning constraint, not a judgement.

How many AI models are retiring in the next 90 days?

58 of 86 scheduled retirements fall within 90 days of October 22, 2026 — the nearest is gpt-3.5-turbo-0125 on 2026-10-23. Of all 264 tracked records, 229 name a replacement model; the rest were announced without a successor. Those are published as “not named” rather than filled in with a plausible guess — a wrong migration target costs more than an empty cell.

How does each provider handle model retirement?

OpenAI — 135 models with both dates published, median notice 184 days, range 3–724. A typical notice leaves roughly 6 month(s) to migrate, but the 3-day worst case is the one to plan capacity around. Full OpenAI schedule

Mistral — 44 models with both dates published, median notice 70 days, range 0–198. A typical notice leaves roughly 2 month(s) to migrate, but the 0-day worst case is the one to plan capacity around. Full Mistral schedule

Anthropic — 20 models with both dates published, median notice 63 days, range 60–189. A typical notice leaves roughly 2 month(s) to migrate, but the 60-day worst case is the one to plan capacity around. Full Anthropic schedule

Cohere — 14 models with both dates published, median notice 0 days, range 0–149. Retirements here are announced as they take effect, so a pinned version can stop working the day the notice appears. Full Cohere schedule

Which models is a specific provider retiring?

• OpenAI deprecations — 63 upcoming, 164 tracked
• Mistral deprecations — 1 upcoming, 44 tracked
• Anthropic deprecations — 16 upcoming, 36 tracked
• Cohere deprecations — 0 upcoming, 14 tracked
• Azure OpenAI deprecations — 6 upcoming, 6 tracked

Why retirement dates are tied to snapshots, not model families

Providers retire versions, not names. gpt-4o as a family stays in the documentation while gpt-4o-2024-05-13 gets a shutdown date, and a pinned snapshot is exactly what production code tends to contain. That is why every row here carries the full model string as the provider wrote it, and why the per-model pages are named the same way — a calendar that lists only family names cannot tell you whether your deployment is affected.

The same string can also mean different things on different platforms: a model retired by OpenAI on one date can carry another date on Azure, because the platforms schedule independently. Provider is part of every row and every URL here for that reason.

Which AI models were recently retired?

What to do when a model you depend on is retired

1. Find every reference in code. Hard-coded model strings are the usual failure point — pinned snapshot names outlive the model they point at.
2. Check the replacement is actually named. 229 of 264 records here carry one; if yours does not, the migration target is your decision, not the provider’s.
3. Check latency of the replacement before switching. A newer model on the same provider can answer from a different backend — per-model figures are on the migration pages, one per retiring model, with the measured time-to-first-byte of the host serving it.
4. Re-run your evals. The replacement will phrase things differently; that is what breaks silently.
5. Fine-tuned models need the most lead time. Retraining on a new base is not a config change — 6 fine-tuned entries are in the calendar right now.