> ## Content Index
> Fetch the complete content index at: https://blog.avis.xyz/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI Model Deprecation: What to Do When Your Model Is Retired
- URL: https://blog.avis.xyz/ai-model-deprecation-what-to-do-when-your-model-is-retired/
- Published: 2026-09-15T10:04:16.000Z
- Updated: 2026-09-15T10:04:16.000Z
- Description: The same AI model can retire on three different dates. How to find the deprecation date that applies to you and replace the model in time.
- Author: AVIS
- Tags: Blog, English

# AI Model Deprecation: What to Do When Your Model Is Retired

Somewhere in your inbox there's probably an email with the word "deprecation" in the subject line, and a date buried somewhere in the message. AI model deprecation is now routine: every major provider retires models on a schedule, and the notice can range from as little as two weeks to six months or more, depending on the provider and the type of model. Worse, the same model can retire on different days depending on how you access it. The important thing is not just knowing that a model is going away, but knowing which date actually applies to you and having a replacement running before you reach it.

## What AI model deprecation actually means

A deprecated model still works. Deprecation is essentially the provider saying that a model is on its way out, usually with a replacement recommended and a retirement date set. Requests continue to work until that date, after which they fail. The confusing part is that providers use slightly different language for the stages leading up to shutdown.

### The four lifecycle stages

| Stage                   | Does it work? | What it signals                                                                          |
| ----------------------- | ------------- | ---------------------------------------------------------------------------------------- |
| **Active**              | Yes           | Fully supported and recommended                                                          |
| **Legacy**              | Yes           | No more updates; deprecation likely later. Some platforms skip this stage                |
| **Deprecated**          | Yes           | Replacement named, retirement date set. Some platforms block new customers at this point |
| **Retired / shut down** | No            | Requests fail. One platform returns410 Gone                                              |

There are a few details worth paying attention to when you read a deprecation notice. First, "still works" doesn't necessarily mean "safe to keep using." At least one provider explicitly warns that deprecated models are likely to be less reliable than active ones. Second, some published dates are floors rather than hard deadlines. Providers may describe a date as "not sooner than" or as the earliest possible shutdown, which means the model could continue running but you shouldn't build a migration plan around that extra time. Preview and experimental models can have even shorter timelines: one provider gives as little as two weeks' notice, while another may automatically upgrade a retiring preview deployment or shut it down entirely.

### Parameters get deprecated too

A model doesn't have to disappear for an integration to break. Providers also change or remove request parameters as newer models are introduced. For example, one provider's newer models return a `400` when sampling parameters such as `temperature` or `top_p` are set to non-default values, even though older models in the same family accepted them.

That's why a migration isn't always as simple as changing the model ID and deploying. The replacement may have different capabilities, parameter restrictions, or defaults, and you can discover those differences only when the first request reaches production unless you check them beforehand.

## Whose shutdown date applies to you?

The shutdown date that matters is the one published by the platform your requests actually reach, not necessarily the date in the model maker's announcement. If you access a model through a cloud marketplace, aggregator, or gateway, you may be operating on a completely different timeline.

### Notice isn't standard

Every provider sets its own deprecation policy, and the differences can be significant:

| Provider route            | Published commitment (as of September 2026)                                                                                     |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| OpenAI API                | At least 6 months for generally available models; at least 3 months for specialized variants; as little as 2 weeks for previews |
| Anthropic first-party API | At least 60 days before retirement for publicly released models                                                                 |
| Gemini API                | Listed shutdown dates are the earliest possible; exact date communicated in advance                                             |
| Microsoft Foundry         | Retirement set 18 months after general availability; at least 60 days' email notice; 30 days for previews                       |

These are normal-case timelines, not guarantees. Safety and compliance issues are explicitly listed as exceptions by more than one provider, so a model can still be removed faster when there's a serious reason.

### One model, three retirement dates

The difference between routes can be surprisingly large. In 2026, one small, widely used model retired from its maker's own API on 20 April, from one cloud marketplace on 23 August, and from another on 10 September. That's a 143-day gap between the first and last shutdown for the same model. A team using the maker's API had to migrate by April, while a team on the slowest route had until September.

More time doesn't necessarily mean free time, either. Some routes offer extended access under separate conditions or at a price set by the provider. If you're relying on a later date, check what that extended period actually means.

### Published dates can move

Don't assume a date you saw once will remain there. On 28 July 2026, one provider's deprecation page listed three models for shutdown on 16 October 2026\. By 3 August, all three showed "no shutdown date announced," with no changelog entry explaining the change. A separate lifecycle page from the same company still showed a date four days later.

This creates a practical problem: two teams checking the same provider at different times could make different migration plans. Keep your own dated record of every notice you receive, and when dates conflict or move, plan against the earliest credible date you've seen.

## Find your exposure before the deadline finds you

Most deprecation incidents aren't caused by someone missing the announcement. They're caused by nobody knowing which parts of the system still depend on the model. The solution is to build an inventory from actual usage, add an automated availability check, and keep enough logging to see which model served every request.

### Build the inventory from traffic, not memory

Searching the codebase for a model ID is a useful first step, but it won't necessarily find everything. The model might be referenced through a config file, environment variable, database-stored prompt template, or a batch job that nobody has touched in months. Usage data is more reliable because it shows what's actually being called.

Group your usage by API key and model. Most provider dashboards can export this information. On AVIS, the [usage endpoint](https://docs.avis.xyz/api-reference/introduction/use.md?ref=blog.avis.xyz) returns each generation with its `apiKeyId`, `model`, `modality`, `status`, and `createdAt`. Filtering for the deprecated model gives you a concrete list of which keys, and therefore which services, still depend on it.

Once you've found them, assign an owner. Deprecation emails often go to account or subscription owners, who aren't necessarily the engineers responsible for the affected service.

### Add an early-warning check that doesn't depend on email

You can also catch a retired model through your own monitoring. A scheduled job can check whether every model your application is configured to use is still available. Through the [AVIS Gateway](https://www.avis.xyz/gateway?ref=blog.avis.xyz), the [model list endpoint](https://docs.avis.xyz/api-reference/endpoints/model-list.md?ref=blog.avis.xyz) returns active models, while looking up a specific model by ID returns `404` when the model doesn't exist or isn't active. Run that check daily for every configured model ID and alert on the first failure. That way, your own monitoring can tell you a model has disappeared before a user discovers it.

For advance warning, subscribe to each provider's deprecation pages and changelogs as well. Open-source trackers also collect deprecation notices from major providers into calendar feeds with reminders 30 and 7 days before shutdown.

### Aliases trade a deadline for a silent change

Floating aliases such as `-latest` can look like protection against deprecation because the name continues to work. The trade-off is that the provider can point that alias at a different model, and your application's behaviour changes without anything in your code marking the transition.

For production systems, we recommend pinning a dated snapshot and keeping the model ID in configuration, so changing it requires a normal deployment. Log both the model you requested and the model the API reports it actually served. If you're using an alias, those logs may be the only way to tell when the underlying model changed.

### What fails on the day

The actual failure can look different depending on where the rejection happens. One platform returns `410 Gone` for a retired model, while others simply document that requests will fail. Through a gateway, a model that's no longer in the catalogue may be rejected before the request reaches the upstream provider. If the upstream provider rejects it instead, the gateway may return the provider's own [error format](https://docs.avis.xyz/api-reference/introduction/errors.md?ref=blog.avis.xyz).

For that reason, handle "model unavailable" as an error category rather than building your fallback logic around a single HTTP status code.

## Replace a deprecated AI model on a timeline you control

The safest way to migrate is to test replacements against your own workload and finish before the earliest retirement date you've recorded. The provider's recommended replacement is a good starting point, but it shouldn't automatically become your answer.

### Recommended doesn't mean required

One platform deliberately names its official replacement only 90 to 120 days before a model retires, so the recommendation reflects the best model available at that point. That's a useful reminder that the model named in a deprecation notice isn't necessarily the best replacement for your workload. A newer model may have appeared since the notice was published, or the right choice may come from a completely different model family or provider.

Start with two or three candidates and check their compatibility before running any tests:

- **Parameters:** Does the model accept every field you currently send, within the ranges you use? The model list endpoint's `capabilities` object lists supported parameters and per-parameter bounds, so you can check this programmatically rather than discovering it through a `400` response.
- **Inputs and outputs:** Does it support the same modalities, context limits, tool calling, and output formats?
- **Cost per request:** Measure this using real prompts. Output length can vary between models, so comparing price per token alone can be misleading.

If the best candidate comes from a provider where you don't already have an account, an OpenAI-compatible endpoint can keep your SDK integration largely unchanged. You may only need to change the base URL and API key at the transport layer, although the model's actual behaviour still needs to be tested.

### Evaluate on a small set of real requests

You don't need a huge benchmark to make a migration decision. A few dozen representative requests from your production logs, paired with the outputs you'd consider acceptable, can reveal most important differences.

Include easy cases, ambiguous requests, requests that should be refused, and anything involving tools. Send the same saved requests to your current pinned model and each replacement candidate, then compare the outputs side by side. Once you've picked a replacement, move traffic over gradually rather than switching everything at once, and keep the old model wired up as a fallback until its retirement date passes.

### Work backwards from the date

| When                      | What to have done                                                                |
| ------------------------- | -------------------------------------------------------------------------------- |
| Notice arrives            | Record the date for your route; assign an owner; pull the key-by-model inventory |
| Within 2 weeks            | Shortlist candidates; run pre-flight parameter checks                            |
| By the halfway point      | Evaluation on real requests complete; replacement chosen                         |
| 3–4 weeks before the date | Staged rollout finished; old model kept only as fallback                         |
| The date                  | Nothing left to do but remove the fallback                                       |

Your internal deadline should always be earlier than the provider's. With a 60-day notice period, that still gives you some room for testing and unexpected issues. With a two-week preview notice, the practical answer is to start the migration as soon as the notice arrives.

## FAQ

**Does a deprecated AI model stop working immediately?**

No. A deprecated model normally continues serving requests until its retirement or shutdown date, after which requests fail. Some platforms also stop accepting new customers once a model is deprecated while allowing existing users to continue using it. Keep in mind that deprecated models may become less reliable before they're retired, so waiting until the final day isn't necessarily the safest option.

**How much notice do AI providers give before retiring a model?**

It depends on the provider and model type. As of September 2026, published commitments range from at least six months for one provider's generally available models to at least 60 days for another's, with preview models sometimes getting as little as two weeks. The same model can also have a different retirement date on a cloud marketplace than on its maker's own API.

**What happens when I call a retired model?**

The request fails, but the exact error depends on where the request is rejected. One platform documents a `410 Gone` response, while others simply describe the request as failing. A gateway may reject an unavailable model before it reaches the provider, while an upstream error may be passed through in the provider's own format. Treat "model unavailable" as the important error category rather than relying on one status code.

**Should I pin a model version or use a "latest" alias?**

For production, pin a dated model version. An alias can keep working through a retirement, but the provider is free to point it at a new model, potentially changing your application's behaviour without a code change. Keep the pinned model ID in configuration and log the model actually served for every request.

**Why does the same model retire on different dates on different platforms?**

Each platform that serves a model has its own lifecycle policy. In 2026, one model retired from its maker's API on 20 April and from two cloud marketplaces on 23 August and 10 September. The date that matters is the one published by the platform your application actually calls.

**What's the fastest safe way to replace a deprecated model?**

Start by pulling usage by API key and model so you know exactly which services are affected. Then check two or three replacement candidates for parameter and capability compatibility before running a test. Evaluate them on a few dozen real requests, choose the best fit, and roll it out gradually while keeping the old model as a fallback until its retirement date passes.

## Wrapping up

AI model deprecation doesn't have to become an emergency. Treat the notice as the beginning of a planned migration: record the date for the route you're actually using, find every caller through your usage data, check replacement compatibility before testing, and finish the rollout weeks ahead of the deadline.

The goal isn't simply to replace a model before it disappears. It's to make the replacement predictable enough that nobody notices the change. If you want to switch between providers without opening a new integration for each one, [AVIS](https://www.avis.xyz/gateway?ref=blog.avis.xyz) puts 300+ models behind one API key and lets you check whether a model is still active before you depend on it.

*Last updated: September 2026*