Providers retire models, and after the retirement date requests to that model fail. Pin specific model versions, keep a small test set, subscribe to deprecation notices and schedule migration as soon as one arrives. Treat a model name like a dependency with an end-of-life date.
What providers say about it
One provider's documentation describes a lifecycle with four states: active, legacy, deprecated and retired. A deprecated model still works but is not recommended, has a named replacement and a retirement date. A retired model's requests fail. The same page says customers with active deployments are notified, with at least 60 days' notice before retirement for publicly released models, and that dates apply to the provider's own platform while partner-operated platforms can set their own schedules.
That last point matters if you use a model through a cloud marketplace. The retirement date on one platform may not be the date on another. Check the page for each route you use.
Other providers have their own policies. Read yours and note the notice period. Do not assume 60 days anywhere else.
Step 1: pin versions
Use a dated or specific model identifier in production, not an alias that moves to the newest version. A moving alias changes behavior without a deploy, which makes bugs hard to explain. Put the model name in configuration, one place per feature, so a change is one edit.
Step 2: inventory
List every feature and the model it uses, including batch jobs, scripts and internal tools that people forget. The provider's usage export may help: the documentation above describes an export of usage by API key and model, which can reveal calls to deprecated models you did not know about.
Step 3: keep a regression set
Keep a small set of real-looking test cases per feature, with expected qualities and a few known failure cases. Include security cases: prompt injection attempts, requests that should be refused, inputs with personal data that must not appear in output. See smoke testing an LLM app for prompt injection.
When a replacement arrives, run the set on both models and compare. The documentation itself recommends testing applications with newer models well before the retirement date.
Step 4: check what else changes
A new model can change more than quality:
- Parameters that older models accepted may be rejected. The same documentation lists examples of parameters that return an error on newer models.
- Tokenization and price can differ, which changes cost. See model migration cost when a new tokenizer changes your bill.
- Safety behavior and refusals shift.
- Output format and tool calling behavior may differ.
Step 5: roll out gradually
Send a small share of traffic to the new model, compare errors and user feedback, then raise it. Keep the old model as a rollback until the retirement date forces the issue.
Put the dates on a calendar
When a notice arrives, create a ticket with the retirement date and an owner. Set a reminder well before it. Add the check to your quarterly dependency review, alongside library updates.
Quick check
Can I just use the alias that always points to the latest model?
You can for prototypes. For production, a moving alias means behavior and cost can change without a deploy, which is hard to test and hard to explain to customers.
Sources
Last reviewed: 19 October 2026.
