How to — keep your AI feature alive when a model is retired

Every model you call has a shut-down date, and most teams only learn it from a failed request in production. The dates are published months ahead. The breakage happens anyway.

Treat retirement as a scheduled maintenance window rather than an emergency: know what you depend on, know your provider's clock, and have the replacement tested before the deadline arrives.

1. Inventory every model identifier you depend on — not just the one in your config.

The model name is usually in more places than anyone remembers: a second service with its own settings, a background job, an eval harness, a notebook someone runs quarterly, a partner's integration that quotes your model in its docs. Search the codebase for the identifiers, then reconcile that list against the provider's own usage export, which breaks consumption down by key and by model — that is how you find the deployment nobody owns. Pay attention to two easy misses: dated snapshots you pinned for stability, and any preview-tagged variant, because preview models sit on the shortest notice of anything you can call.

2. Learn your provider's actual clock, and who sets it.

The vocabulary matters more than the marketing. A model marked legacy still answers but gets no updates; deprecated means a replacement is named and a retirement date is assigned; retired means requests fail. The notice you are owed depends on what you are running. OpenAI commits to at least six months for generally available models, three months for specialized variants, and as little as two weeks for preview models. Anthropic gives at least 60 days and tells customers with active deployments by email.

The trap is platform-versus-provider. A model's lifecycle status and dates differ depending on whether you call the lab directly or through a cloud reseller, and the reseller's page is the one that governs your traffic. Bedrock keeps a model on the platform for at least 12 months before end-of-life and holds it in a legacy state for at least six months — but new customers cannot use legacy models at all, and existing ones can lose access after 15 days of inactivity. Azure OpenAI guarantees generally available versions for a minimum of 12 months, then gives existing customers another six; retirements roll out region by region with no fixed schedule for any single region. Read the page for the platform that actually serves your requests.

3. Pre-register the replacement and test it on your own cases.

When a deprecation notice lands, the provider names a recommended successor. Do not wait for the deadline to find out what it does to your product. Point your eval set at the replacement while the old model is still live, run both, and record the scores — that is the whole point of owning a small set of real cases, and if you don't have one yet, How to — build a small eval set for your own AI feature is a few hours of work that pays for itself exactly here. The changes that hurt are never the loud ones. A newer model may follow your formatting rules more loosely, refuse a class of request it used to answer, or reason longer and cost more per call.

4. Build a tripwire that fires before a user notices.

Three cheap alarms, in order of value. First, alert on the usage dashboard when the share of traffic hitting a deprecated model crosses a threshold — that catches the forgotten deployment, not the one you migrated. Second, keep the model identifier in exactly one place per service, so switching it is a one-line change instead of an archaeology project. Third, log the model name your provider reports back on every response, not the one you sent. Providers sometimes serve a different snapshot than you asked for, and a log that records your own request cannot tell you that.

5. Decide the escape hatch in advance — and price the work honestly.

A second provider is the standard hedge: one abstraction at the call site, two routes behind it, and a tested fallback so a retirement is a config change. The deeper hedge is running the workload on your own hardware, which trades a date you don't control for capacity you do — the real trade-offs are laid out in AI 101 — Local LLMs vs cloud APIs: what's the difference?. Be honest about the cost either way: a fallback that has never carried production traffic is not a fallback, and an open-weights model you have never run under load is a project, not a plan.

The move not to make.

Don't migrate on the last day by swapping the identifier and watching the error rate. A retirement date is not the deadline — it is the end of your safety margin. Two things go wrong when you compress the work: the replacement's behavior differences surface in front of users, and every other team that depended on the same model arrives in the same week, which is when the successor's capacity and rate limits get tight. Also, don't plan around "they'll keep serving it for us." Extended access exists on some platforms, it usually costs more, and it can end with the same short notice as everything else.

How you'll know it worked.

Four checks. Your model inventory matches the provider's usage export with nothing unaccounted for. Every identifier you own lives in one place per service. The replacement has recorded scores on your own cases, taken while the old model was still answering. And you have deliberately fired your own alert — pointed a test call at the deprecated model and watched the alarm arrive. If that last one never fires, you don't have a tripwire; you have a dashboard nobody reads.

Have you ever been caught by a model retirement mid-quarter, or did you see the date coming? Tell us in the comments.