Lifecycle Guidelines
What you need to know to navigate our model deprecations process
Deprecation process
1. Announcement
- Email notification to all accounts with recent inference traffic on the affected models.
- A dated entry is added to Deprecation History page listing the affected model IDs, the shutdown date, and recommended replacements.
2. Transition period — 7 days
- The affected models continue to serve requests normally for 7 days from announcement.
- Replacement models are available in the Model Studio and via API for side-by-side testing.
- Support is available throughout to help with replacement selection and integration changes.
3. End of life
- At the shutdown time, the affected models stop serving traffic and are no longer accessible.
- Requests to a retired model ID return an error. There is no fallback routing to another model, and no redirect from the old ID to its replacement (applications without their own fallback path will fail). Complete your migration before this date.
Notice periods
| Model type | Notice before shutdown |
|---|---|
| Serverless models from Model Studio | 7 days |
Notice may be shorter where a model is withdrawn by its upstream provider, where a licence change removes our right to host it, or where a security or compliance issue requires immediate action.
Suggested migration steps
- Find your current model in Deprecation History page and note its recommended replacement and shutdown date.
- Audit your own usage, identify every service, agent, batch job, and saved configuration that references the affected model ID.
- Review the recommended replacement against your workload. Recommendations are based on capability tier and model lineage, not on your specific traffic. If cost or latency is your binding constraint, another model in the current catalogue may suit you better.
- A/B test against representative production traffic. Replacements rarely behave identically, so validate output quality, token consumption, and latency before committing.
- Update your API calls and roll out gradually. Switch a small slice of traffic first, then more, then everything. Keep your old fallback path working until the switch is done.
- Watch errors, latency, and cost during the switch and for a while after.
Best practices
- Keep model IDs in configuration, not in code, so future changes are a config update rather than a release.
- Build a fallback model path into production request handling.
- Check Deprecation History page and your email notifications ahead of each shutdown date.
- Retain your own copies of prompts, evaluation sets, and required configurations rather than relying on platform-side storage.
- Where possible, design around a model interface rather than a specific model, so replacements can be swapped in with minimal change.
When a replacement is not a drop-in
Some replacements require more than a model-ID change, and some capabilities lapse without an equivalent. Embedding models are the most common example of the first: because embeddings are not interchangeable between models, any change requires re-embedding your corpus before query-time traffic can be switched over, which generally needs more lead time than the transition window allows. If your workload falls into either case, contact us as early as possible so we can discuss options.
Getting help
If you need help choosing a replacement model or testing your integration, contact our support team.