# Tracking model updates and deprecations without surprises [Skip to content](#lm-inhoud)Network/[NL](/en/modelupdates-bijhouden)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodelupdates-bijhouden&text=Tracking%20model%20updates%20and%20deprecations%20without%20surprises)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodelupdates-bijhouden)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodelupdates-bijhouden&title=Tracking%20model%20updates%20and%20deprecations%20without%20surprises)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodelupdates-bijhouden&text=Tracking%20model%20updates%20and%20deprecations%20without%20surprises)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodelupdates-bijhouden)[](https://www.reddit.com/submit?url=https%3A%2F%2Fhub.llmnet.nl%2Fen%2Fmodelupdates-bijhouden&title=Tracking%20model%20updates%20and%20deprecations%20without%20surprises)[](#) # 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](https://developers.openai.com/api/reference/overview)) API providers announce model phase-outs (deprecations) and final shutdowns (retirements) months in advance. OpenAI publishes exact timelines on their [deprecations page](https://developers.openai.com/api/docs/deprecations), 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](https://hub.llmnet.nl/en/modelversies-en-deprecatie) . 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: - Deprecations page: On the [OpenAI Deprecations page](https://developers.openai.com/api/docs/deprecations) contains the complete overview of upcoming and historical deprecations, including the official shutdown dates and the replacement models recommended by OpenAI. - Changelog: The [OpenAI Changelog](https://developers.openai.com/api/docs/changelog) provides a chronological overview of new features, model releases, and technical changes. 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: - Model deprecations page: The [Anthropic Model Deprecations page](https://platform.claude.com/docs/en/about-claude/model-deprecations) shows the exact status and retirement dates. The platform defines 'Deprecated' as still functional but not recommended for new use, and 'Retired' as the point at which API requests permanently return an error. - Release notes: The [Anthropic Release Notes Overview](https://platform.claude.com/docs/en/release-notes/overview) documents the release dates and any updates to default system prompts per model. - Migration guide: The [Anthropic Migration Guide](https://platform.claude.com/docs/en/about-claude/models/migration-guide) details which parameters change or are removed for each model. 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: - Gemini API Changelog: The [Gemini API Changelog](https://ai.google.dev/gemini-api/docs/changelog) lists general updates and features. - Gemini API Deprecations: On the [Gemini API Deprecations page,](https://ai.google.dev/gemini-api/docs/deprecations) the specific shutdown schedules per Gemini model are published. Decommissioned models are grayed out on this page. - Vertex AI Release Notes: The [Vertex AI Release Notes](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/release-notes) contain updates on enterprise models. Note: the legacy Vertex AI page is no longer updated, as Google's generative AI services have been consolidated into the Gemini Enterprise Agent Platform. Development teams using Google Cloud should consult the documentation for the [Vertex AI Model Lifecycle](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions) consult. Smaller model infrastructure providers also publish formal life-cycle policies. Together AI, for example, provides on their [Together AI Deprecations page](https://docs.together.ai/docs/deprecations) 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](https://developers.openai.com/api/docs/deprecations): - GA models: Receive a minimum of 6 months' notice prior to shutdown. - Specialized variants: Receive a minimum of 3 months' notice. - Preview models: Models with 'preview' in their name can be withdrawn with approximately 2 weeks' notice. OpenAI explicitly advises against using preview models for mission-critical production workloads. Anthropic guarantees on the [Anthropic Model Deprecations page](https://platform.claude.com/docs/en/about-claude/model-deprecations) 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](https://www.anthropic.com/research/deprecation-commitments). Google provides clearly defined guarantees for the Gemini Enterprise Agent Platform and Vertex AI through the [Vertex AI Model Versions policy](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions): - GA models: Remain available for at least 12 months following their official release date. - Fixed dates: Scheduled retirement dates are never moved forward by Google; however, they may be extended by the provider. - Short-term models: Models designated with 'short-term availability' are retired 45 days after the release of a direct successor. For infrastructure providers like Together AI, according to the [Together AI Deprecations documentation](https://docs.together.ai/docs/deprecations) 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](https://developers.openai.com/api/docs/deprecations) shows the following verifiable milestones: - gpt-3.5-turbo-0613 and gpt-3.5-turbo-16k-0613: Announced on 2023-11-06, final shutdown on 2024-09-13. Users were directed to the standard gpt-3.5-turbo. - o1-preview: Announced on 2025-04-28, final shutdown on 2025-07-28; replaced by the o3generation. - Assistants API: Deprecation announced on 2025-08-26, with complete removal scheduled for 2026-08-26 in favor of the Responses API and Conversations API. According to the [Anthropic Model Deprecations page](https://platform.claude.com/docs/en/about-claude/model-deprecations) , Anthropic has also retired multiple generations: - Claude 1.x and Claude Instant: Announced on 2024-09-04, permanently retired on 2024-11-06. - Claude Opus 4.1 (claude-opus-4-1-20250805): Announced on 2026-06-05, retired on 2026-08-05. - Parameter deprecation: As of Claude Opus 4.7+, the parameters temperature, top_p and top_k are deprecated; sending non-default values returns an HTTP 400 error. Google implemented the following shutdowns via the [Gemini API Deprecations](https://ai.google.dev/gemini-api/docs/deprecations) and the [Vertex AI Lifecycle overview](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions) : - Gemini 2.0 Flash (-001) and Flash-Lite: Permanently shut down on 2026-06-01. - Gemini 2.5 (Pro, Flash, Flash-Lite): The planned shutdown is set for October 2026 according to the official documentation. ## 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](https://platform.claude.com/docs/en/about-claude/models/model-ids-and-versions) , 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](https://developers.openai.com/api/reference/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](https://api.llmnet.nl/en/versiebeheer-voor-prompts-in-code). ## 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](https://platform.claude.com/docs/en/about-claude/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](https://ezaiapi.com/blog/ai-model-version-pinning-production)) and does not constitute official vendor advice from the model providers themselves. A reliable upgrade routine consists of the following steps: - 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](https://developers.openai.com/api/docs/guides/evals) and references the [Promptfoo Cookbook](https://developers.openai.com/cookbook/examples/evaluation/moving-from-openai-evals-to-promptfoo) on its deprecations page for running comparative benchmarks. For further depth, consult the guide on [prompt regression testing on llmnet benchmark](https://benchmark.llmnet.nl/en/regressietesten-prompts). - Use official migration tools: Vendors provide specific guides for changes across model generations. Anthropic provides a [Migration Guide](https://platform.claude.com/docs/en/about-claude/models/migration-guide) including an automated /claude-api migrate skill within Claude Code that scans codebases for deprecated model IDs and parameters. - 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](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/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: - Official RSS feeds: Google provides a direct RSS feed for Vertex AI updates via the [Vertex AI Release Notes RSS Feed](https://docs.cloud.google.com/feeds/generative-ai-on-vertex-ai-release-notes.xml). - BigQuery Public Datasets: Google Cloud publishes release notes in the public dataset bigquery-public-data.google_cloud_release_notes. As indicated on the [Vertex AI Release Notes page](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/release-notes) developers can set up a weekly SQL query searching for terms such as 'deprecat' or 'retired'. - GitHub Atom feeds: Developers using development tools can follow the release feeds of specific repositories. For example, the repository [anthropics/claude-code](https://github.com/anthropics/claude-code/releases) offers a releases.atom feed to track updates to the CLI tool. 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): - endoflife.date: The page [endoflife.date/claude](https://endoflife.date/claude) provides an overview of release and retirement dates for Claude models. - Third-party aggregators: Services such as the [reconn-ai LLM Changelog](https://reconn-ai.com/llm-changelog.php) and [[llm-stats.com/llm-updates](https://llm-stats.com/llm-updates)](https://llm-stats.com/llm-updates) crawl documentation changes and API updates daily from OpenAI, Google, Anthropic, and Together AI. - Developer Discords: Both OpenAI and Anthropic maintain official Discord servers (accessible via their documentation sites) where announcements are shared. 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: - Pin: Explicitly lock model versions to specific snapshot IDs and avoid using latestaliases or preview models in production. - Monitor: Set up automated alerts via RSS, BigQuery, or account emails to immediately catch deprecation announcements. - Eval: Establish a fixed evaluation baseline to quantitatively compare the output quality of a new model against the current snapshot in advance. - 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](https://hub.llmnet.nl/en/model-kiezen) to select suitable successors.