AI model deprecation tracker
Pinned model snapshots do not live forever. Providers retire older versions on a schedule, and a hardcoded model ID that worked for a year can start returning errors overnight. This tracker gathers announced and scheduled retirement dates across the major providers — OpenAI, Anthropic, Google, and Cohere — with a live days-remaining countdown, the recommended successor, and a short migration note for each. Filter it to the models you actually run so you only see what matters to your stack.
How it works
Each entry pairs a model with its publicly stated lifecycle status — active, deprecated, or retired — and, where one has been announced, a retirement date. The tool computes days remaining against today’s date and sorts the soonest deadlines to the top, colour-coded by urgency. You can filter by provider or paste your own model IDs to narrow the list. For every model the tracker shows a recommended replacement and a one-line migration note covering the gotchas that usually bite — changed defaults, different token limits, or output-format drift. Dates are a planning aid; always confirm against the provider’s own deprecation page before a production cutover.
Why pinned snapshots get retired
Providers pin specific snapshot versions (for example gpt-4-0613 rather than
just gpt-4) when you want reproducible outputs across API calls. That stability
is useful in the short term — you know exactly what model answered your users
yesterday. The problem is that running dozens of snapshot versions in parallel
is expensive for providers to maintain, so they retire them on a schedule, usually
giving six to twelve months’ notice. When a snapshot is retired, API calls to it
either fail with a 404-style error or get silently routed to a designated
successor. Silent routing is particularly dangerous because the successor model
can have different defaults, longer latency, or subtly different output formatting
that breaks downstream parsing without throwing an explicit error.
The migration pitfalls that catch teams out
The three most common problems when migrating to a successor model are:
Temperature and sampling defaults. Providers sometimes change the default
temperature between versions. A deterministic prompt that worked at temperature=1
on the old model may produce noticeably different output on the new one if you rely
on the provider default rather than setting it explicitly. Always pin temperature
and top-p in production calls.
Context length changes. Successor models often have larger context windows, but they can also have different tokeniser behaviour, which means the same string is a different token count. If you have logic that trims inputs to stay under a token limit based on the old model’s tokeniser, re-validate after migration.
Output format drift. Models fine-tuned on different data tend to vary in how they handle structured output — JSON formatting, list punctuation, and Markdown headers can all shift between versions. Run your output parsing and any downstream logic against a representative sample before cutting over production traffic.
How to stay ahead of retirements
- Don’t hardcode pinned snapshots. Where latency-aliases like
*-latestexist, they ride forward automatically; pinned IDs do not. - Keep a model inventory. You can only migrate calls you know about. Track every model ID your code references.
- Subscribe to deprecation notices. Every major provider publishes them; the surprise only happens to teams who do not read them.
- Migrate then re-test. Successor models change defaults and formatting. Swap the ID, then re-run your output parsing and evals before shipping.
- Give yourself a month’s runway. The last week before a deadline is the worst time to discover a formatting regression in a rarely-hit code path.