Skip to content
NLEN
Illustration: Tracking model updates and deprecations without surprises

Tracking model updates and deprecations without surprises

By Ivo Donker — compiled with AI assistance (Claude & Gemini) · Last updated: August 6, 2026

Your model can disappear — and that is nothing new

In software development, an unwritten rule has applied for decades: as long as a REST API endpoint accepts and returns the same JSON structure, the integration keeps working. With Large Language Models (LLMs), that assumption is only partly true. While providers do guarantee the technical backward compatibility of their REST layer and client libraries, the underlying behavior of the model can change with every update.

OpenAI explicitly states this distinction in their official API documentation:

"Model prompting behavior between snapshots is subject to change… The best way to ensure consistent prompting behavior and model output is to use pinned model versions, and to run evals for your applications." (OpenAI API Overview)

API providers announce model phase-outs (deprecations) and final shutdowns (retirements) months in advance. OpenAI publishes exact timelines on their deprecations page, Anthropic uses fixed notice periods for active accounts, and Google provides guarantees for General Availability (GA) models. When an application in production breaks because a model endpoint no longer exists or behaves differently, it is almost never due to a lack of information from the provider. It is the result of a lack of operational routine.

The reflex to use a generic alias in production code, such as latest or relying on unchanged model names, carries significant risks. Anyone using an alias automatically drifts with every snapshot update a provider releases. Deploying a preview model in a critical production environment means dealing with notice periods that can range from a few weeks to just a few days. Managing LLM integrations requires treating a model API as a pinned dependency with its own lifecycle. For an overview of the various lifecycles, you can consult the article on model versions and deprecation on llmnet hub . Setting up this process systematically takes an average of thirty minutes per month and prevents developers from having to carry out ad-hoc migrations under time pressure.

Where vendors announce deprecations: one central page per provider

The most important step in preventing surprises is knowing the official information channels. Every major AI provider maintains dedicated documentation pages tracking model updates, notice periods, and scheduled shutdowns.

OpenAI consolidates all changes across two central locations:

Anthropic uses a clear four-phase classification for their models: Active, Legacy, Deprecated, and Retired. The status of each model can be tracked through the following sources:

It is important to note here that Anthropic's dates apply to the Claude API, AWS, and Foundry. Cloud platforms such as Amazon Bedrock and Google Cloud maintain their own deprecation schedules for hosted instances.

Google publishes information regarding Gemini and Vertex AI across multiple documentation sources:

Smaller model infrastructure providers also publish formal life-cycle policies. Together AI, for example, provides on their Together AI Deprecations page insight into their policy regarding automatic redirects and notice periods for hosted open-source models.

How much time do you get? Notice periods by provider

The time between a deprecation announcement and the final shutdown of an endpoint varies by provider and model type. Models with General Availability (GA) status offer the longest guarantees. In contrast, preview versions and experimental variants have shorter notice periods.

OpenAI applies the following official policies on the OpenAI Deprecations page:

Anthropic guarantees on the Anthropic Model Deprecations page that customers with active API deployments will be notified at least 60 days before a model is permanently retired. Additionally, Anthropic has formally committed to the long-term preservation of model weights for academic research, as detailed in their Deprecation Commitments.

Google provides clearly defined guarantees for the Gemini Enterprise Agent Platform and Vertex AI through the Vertex AI Model Versions policy:

For infrastructure providers like Together AI, according to the Together AI Deprecations documentation shorter timeframes apply: 'upgrade' models are automatically redirected to a newer version after 3 days, new models offer a 2-week overlap, and preview models can be shut down after 30 days of availability with less than 24 hours' notice.

Not just theory: what actually disappeared in recent years

The reality that model deprecation is an ongoing process is evident from the list of models and endpoints that were permanently shut down during the 2024–2026 period or are scheduled to be phased out in the coming period.

For OpenAI, official data on the deprecations page shows the following verifiable milestones:

According to the Anthropic Model Deprecations page , Anthropic has also retired multiple generations:

Google implemented the following shutdowns via the Gemini API Deprecations and the Vertex AI Lifecycle overview :

Pin your versions — the only real defense

To prevent an application from unexpectedly exhibiting different behavior, version pinning is the primary line of defense. There is an essential difference between a specific model ID (a pinned snapshot) and an alias such as latest.

In its documentation on Model IDs and Versioning , Anthropic explains that each model ID points to a fixed snapshot. The underlying weights of such a specific ID do not change over the entire lifecycle of that ID. Since the 4.6 generation, dateless IDs (such as claude-sonnet-4-6) are also canonical pinned snapshots rather than aliases. Each model ID has its own unique deprecation window and retirement date.

OpenAI underscores this principle in the API Overview: anyone looking to guarantee consistent results should explicitly use dated snapshots instead of generic aliases. Anyone using an alias such as gpt-4o or latest, lets the provider determine when the underlying snapshot changes. Such a background upgrade can impact output structure, response length, or adherence to system prompts without a single line of application code having changed.

Using aliases is only sensible in staging environments or for non-critical tasks. In production environments, every LLM call should reference a specific, pinned model ID. Practical implementation guidelines for software development can be found in the guide on prompt versioning in code on llmnet api.

An upgrade routine that actually works

Managing model transitions requires a structured process. This process does not begin with modifying code, but with mapping out actual usage across the organization.

An audit serves as the starting point. Anthropic provides the option in its dashboard to export usage data via Console → Usage → Export CSV per API key and model (Anthropic Model Deprecations). This provides insight into which microservices or teams are still using older snapshots.

For gradual transitions between model versions, many software teams follow an established pattern. Please note: this specific workflow (production pinned, staging on an alias, nightly evaluations, and an upgrade only after N consecutive green days) is a well-known community pattern (as described on sources like the EzAI blog) and does not constitute official vendor advice from the model providers themselves.

A reliable upgrade routine consists of the following steps:

  1. Establish an eval baseline: Before migrating to a new model ID, the performance of the current model must be measured against a fixed evaluation dataset. OpenAI documents best practices for this in the OpenAI Evals Guide and references the Promptfoo Cookbook on its deprecations page for running comparative benchmarks. For further depth, consult the guide on prompt regression testing on llmnet benchmark.
  2. Use official migration tools: Vendors provide specific guides for changes across model generations. Anthropic provides a Migration Guide including an automated /claude-api migrate skill within Claude Code that scans codebases for deprecated model IDs and parameters.
  3. Run cross-vendor evaluations: When a migration also involves switching providers, evaluation services can provide a solution. Since 2026-03-12, the Google Vertex AI Evaluation Service has also supported partner models such as Claude and Llama, allowing comparative benchmarks to be executed within a single test harness (Vertex AI Release Notes).

Let the changelogs come to you

Manually checking dozens of documentation pages is time-consuming. It is far more effective to aggregate model update notifications automatically.

Several official and automated channels are available:

In addition to official vendor channels, secondary sources and community trackers aggregate changes (expected to be useful for quick overviews, though with medium reliability compared to official documentation):

A key insight for developers and system administrators is that there is no universal, overarching push notification service that aggregates all model deprecations across all providers. The only guaranteed notification channels are direct emails sent by providers to administrators of active API accounts, combined with official deprecation pages. Building your own internal alert system (such as an automated RSS parser or BigQuery job) is the most reliable way to stay informed in a timely manner.

Conclusion: Make it a routine, not a project

Managing LLM models in a production environment requires a shift in mindset. A model API is not a static utility, but a dynamic component with a predictable lifecycle. Applying a consistent four-step routine prevents surprises:

  1. Pin: Explicitly lock model versions to specific snapshot IDs and avoid using latestaliases or preview models in production.
  2. Monitor: Set up automated alerts via RSS, BigQuery, or account emails to immediately catch deprecation announcements.
  3. Eval: Establish a fixed evaluation baseline to quantitatively compare the output quality of a new model against the current snapshot in advance.
  4. Migrate: Execute the migration in a controlled manner within the notice period provided by the vendor, and make use of available migration guides.

A monthly thirty-minute check of the official deprecation pages ensures you maintain control over your model infrastructure. Start today by auditing active API keys across the organization, pinning the primary model to a specific snapshot ID, and consulting the guide to choosing the right AI model on the llmnet hub to select suitable successors.