The Model-Deprecation Risk Read: Build Direct, Abstract, or Avoid

Before you commit a feature to an AI model provider's API, you are making a bet on how long that specific model will stay callable and what the provider will do to you when it stops. This guide is for engineering managers, technical founders, and anyone who has to sign off on building against a model endpoint. It gives you a repeatable way to score a provider's deprecation risk from its published policy and measured history, then decide whether to build directly on the model, hide it behind an abstraction layer, or avoid that provider for the use case.

Most public writing on this topic is either a one-off migration checklist for after you are already broken, or a dated retirement calendar that tells you what shuts off and when. Neither helps you grade a provider before you commit. The method here reads a deprecation track record the way you would read a vendor's incident history: as a repeatable judgement you make once, up front, instead of a scramble you run under pressure.

What "deprecation risk" actually measures

Deprecation risk is the exposure you take on when a provider retires a model you depend on: how much warning you get, whether the warning is binding, and what breaks at the cutoff. It is not one number. It is the product of three things a provider controls and one thing you control.

The three provider-side variables are the committed notice floor, the measured history against that floor, and the behavior at cutoff. The reader-side variable is your own hardcoding exposure. A provider can look safe on paper and still hurt you if your code pins a slug in ninety places, and a provider with a short floor can be survivable if you fail loudly and have a named successor ready.

The reason this is worth scoring before you build, not after, is that the floor is predictive. In the empirical record, committed minimums and actual notice periods converge tightly, so the policy number on the page is a reliable forecast of the runway you will actually get.

That number is the whole reason this is a pre-commitment judgement. If 82% of teams migrate after the deadline regardless of experience or tooling, the lever that works is not reacting faster. It is choosing and configuring better before you write the first call.

Read the committed floor, then measure the history

Start with the committed floor: the minimum notice a provider promises before it retires a model. Each provider publishes this on a different page and defines the terms differently, so you read three documents, not one.

OpenAI commits, on its Deprecations page, to at least six months for generally available models, at least three months for specialized variants such as Codex and chat-latest, and as little as two weeks for previews, with an explicit warning against using previews for business-critical production. Anthropic commits to at least 60 days for publicly released models and notifies customers with active deployments. Google's Gemini docs promise at least two weeks for preview models and leave the stable tier unspecified, describing shutdown dates as "the earliest possible dates on which a model might be retired." xAI publishes per-event migration pages but no standing floor at all.

The floor is only half the read. The other half is whether the provider clears it comfortably or sits right on top of it. You reconstruct this yourself: for every past entry in the deprecation table, subtract the announcement date from the shutdown date, then take the median and the minimum.

Read that ratio column carefully, because it is the single most useful derived figure in the whole exercise. OpenAI's last five GA retirements ran 182, 183, 184, 184, and 184 days. Anthropic's last four ran 60, 61, 62, and 62. The mechanism is not generosity. Providers reclaim capacity for new releases as soon as the minimum allows, which makes the floor the operating target.

The counterintuitive finding is that a longer floor does not buy proportionally more on-time migration. In the study, 89% of migrations under Anthropic's roughly 60 to 114-day notices happened after the shutdown date, versus only 13% under OpenAI's one-year Assistants API notice. Each e-fold increase in notice length cut the odds of a post-shutdown migration by about three quarters. Long warnings work because they let disciplined teams front-load the work before attention decays on a distant deadline. They do not work by themselves.

Judge the date hardness and the cutoff behavior

A shutdown date is only as good as the words attached to it, and the words differ by provider. This is where two providers that look similar on notice length split hard on risk.

The first distinction is date hardness. Anthropic's commitments read as binding floors. Google's Gemini page describes its dates as "the earliest possible dates on which a model might be retired," which means the date can move in either direction and is not a promise you can plan against. Score a soft "earliest possible" date below a binding "not sooner than" floor, even when the headline number looks the same.

The second distinction is what happens when you call a retired model. This matters more than most teams expect.

A loud failure is a gift. It shows up in your logs, pages someone, and forces the migration. A silent redirect is the opposite. xAI's retired slugs continue to resolve, so nothing 404s, but the request is served by a successor and billed at that successor's pricing. Your monitoring stays green while output quality and cost drift underneath you. The same shape appears with auto-forwarding gateways: the request succeeds, so you never find out until a user or an invoice tells you.

A short notice at least 404s your expectations; a silent redirect ships zero signal and rebills you at new pricing.

This is why I rank a silent cutoff as more dangerous than a short notice. xAI's nine-day window was alarming, but at least an expired call would fail. The redirect converts a detectable outage into an invisible regression, which is far harder to catch and far harder to attribute once someone finally notices.

Audit your own exposure: hardcoding is the dominant variable

The provider's policy sets the ceiling on your risk, but your own code sets the floor. The empirical record is blunt about where the real exposure lives: model identifiers are hardcoded in 94% of migrating applications, and only 8% of migrations ever switch provider. Provider choice is not the dominant risk variable. Configuration discipline is.

Migration effort is not uniform either. It scales from a median of six added lines for prompt-only applications to nearly 700 lines for fine-tuned ones. A prompt-only swap is a config change. A fine-tune means you retrain against a new base model, revalidate, and re-ship. So your audit has two outputs: a count of hardcoded slugs, and a separate inventory of fine-tuned base-model dependencies, because those two numbers imply completely different migration budgets.

To find your exposure concretely, use the provider's own usage data. In the Claude Console, open the Usage page, click Export, and review the CSV, which breaks usage down by API key and model. The equivalent exists for other providers. The goal is a definitive answer to "which of my keys call which model, and where is that model ID written down."

The funnel is the argument against reflexive multi-provider builds. If only 8% of migrations ever cross a provider boundary, then building a full portability layer to hedge deprecation is solving a problem most teams never actually have, while the hardcoding problem that 94% do have goes unaddressed.

That staffing question is not hypothetical. In Refolk's index of professional profiles, US profiles listing LangChain number 21,706 against just 124 listing LiteLLM, a dedicated model gateway. The gateway skill is 0.6% as common. If your plan is "we will abstract it," you are making a hiring claim about a thin pool, and you should check whether you can actually staff it before you commit the architecture to it.

The scoring procedure

Here is the repeatable procedure. It reads policy first and audits code second, which is the opposite of a reactive migration playbook, because the whole point is to decide before you commit. Expect the full pass to take an afternoon per provider the first time and under an hour on repeat.

Reading the score into a verdict

Combine the three provider variables with your own exposure, and the verdict falls out along two axes: how much runway the provider gives you, and how much the model is woven into your build. Build Direct when runway is long and coupling is shallow. Avoid when runway is short, soft, or silent and the coupling would be deep.

The three verdicts map to concrete actions. Build Direct means pin a dated snapshot, externalize the slug into config, and set the watch. Abstract means route through a gateway that holds the model ID in one place, and accept the staffing cost of that choice. Avoid means the provider's runway is too short, too soft, or too silent for a dependency this deep, so you pick a different provider or redesign the feature to not need it.

One provider earns a special mitigation note. On its deprecation commitments page, Anthropic committed to preserving the weights of all publicly released models for at minimum the lifetime of the company. No competitor matches this. Score it as mitigation, not availability: preserved weights are a durability signal, but they are not a promise of continued inference access on the same API, so it lowers your risk without eliminating the need to migrate.

Provider / channel: __________________
Committed floor (GA / specialized / preview): ____ / ____ / ____ days
Median actual notice (reconstructed): ____ days
Minimum actual notice (reconstructed): ____ days
Actual-over-floor ratio: ____
Date hardness: binding "not sooner than" / soft "earliest possible"
Cutoff behavior: hard error / silent redirect / auto-forward
Named successor mapped per entry: yes / no
My hardcoded slug count: ____
Fine-tuned base-model dependencies: ____
Weight-preservation commitment: yes / no
VERDICT: Build Direct / Abstract / Avoid

How this read goes wrong

The scoring is only as good as your resistance to the predictable mistakes. These are the failure modes and false positives that turn a confident score into a missed cutoff.

The first is reading the floor as a plan. The floor is not a minimum the provider comfortably clears; it is the actual schedule. Check it by comparing median actual to floor. When the ratio sits near 1.0, as it does for both OpenAI and Anthropic, the floor is your runway, full stop.

The second is trusting "earliest possible" as a hard date. Google's dates can move, and scoring Google as if its dates were as binding as Anthropic's is a false positive that will burn you. Check the exact wording on the page before you treat any date as a commitment.

The third is reading a silent redirect as "no action needed." xAI's own guidance that you do not need to change your code masks a quality and billing change that ships with no error. Check by diffing output and cost per million tokens after the cutoff, not just the HTTP status.

The fourth is alias pinning read as safe. An alias upgrades silently and your evals drift. Pin dated snapshots for eval baselines and monitor alias releases separately, so your quality bar does not shift under you.

The fifth is assuming an abstraction layer protects you. The study found that post-shutdown failure held regardless of the presence of a provider-abstraction layer. "We use a gateway, so we are fine" is a false positive, because an abstraction layer still has a hardcoded default model somewhere. Find that default and govern it.

The sixth is underestimating fine-tune exposure. Prompt-only swaps are around six lines; fine-tuned migrations are nearly 700. Inventory your fine-tuned base-model dependencies separately, because they carry a migration cost two orders of magnitude larger than a config change.

The seventh is ignoring the platform channel. The same model retires on different dates across the model-maker's own API, a cloud reseller, and a managed platform. Score the channel you actually call, not the headline from the model-maker's page. For context, Microsoft Foundry assigns each GA model a retirement date at launch eighteen months out with a deprecation stage at twelve, and partner models including Anthropic and Mistral live twelve months, which is a different clock than the native API.

Keeping the read current

A deprecation score is a snapshot of a moving target, so the last step is not a decision but a standing process. Set a watch on each provider's deprecation page and alert on new entries matching the models you call. A vendor that has given twelve months deserves less urgency than one with a track record of ninety-day windows, and you only keep that distinction sharp if the watch runs continuously.

Before you call any provider scored and any feature committed, run the final verification.

Re-run the score when a provider changes its policy wording, when you add a fine-tune, or when you adopt a new channel. The mechanism to re-check is always the same: open the page, reconstruct the windows, read the exact wording, and compare the median to the floor. The numbers will change. The method does not.

If you are staffing the migration or the abstraction layer rather than scoring it yourself, the same reasoning applies to people. A gateway skill like LiteLLM is far rarer than general orchestration experience, so the "abstract it" verdict carries a hiring cost you should price in before you write it down. Refolk lets you find the engineers who have already done a production migration off a deprecated model in plain English, which is the difference between a plan that assumes the skill exists and one that confirms it does.