What provider deprecation emails tell you, and what they don't

October 9, 2026 · Updated November 9, 2026

When a model or API is retiring, the provider tells you. OpenAI's deprecations page says impacted customers are always notified by email and in its documentation. Anthropic emails customers with active deployments, gives at least 60 days' notice under its policy, and offers a usage export so you can see which deprecated models you've been calling.

That's a responsible setup, and the information in those notices is the source of truth. If a date on any third-party site, ours included, disagrees with the provider's own page, trust the provider.

But a notice is designed to answer one question: which model or API is going away, and when? Teams need answers to several more. This post walks through what the notices cover, where the gaps are, and a short process to close them.

What the notices do well

They're authoritative. The provider decides the date, so its notice is the only definitive source.

They name the replacement. Most notices recommend a specific model or API to move to.

They reach someone. An email goes to the account's contacts, so the information enters your organization.

Usage data adds evidence. Anthropic's usage export, for example, shows which models your account actually called, which is a direct way to confirm you're affected.

Gap 1: the email reaches the account, not the code owner

Notices go to the contacts on the provider account. Depending on how the account was set up, that might be a founder, an operations lead, a finance team or a shared admin mailbox. The engineers who know where the model is used may not see it for days.

Close it: check who receives notices for each AI provider account. Add a shared engineering address where the provider allows it, or set up a forwarding rule. Make "who gets provider notices" part of onboarding for any new API account.

Gap 2: it names the model, not the file

A notice says "model X retires on date Y". It can't say that model X appears in three services, a Terraform variable, two notebooks and a fallback list. Only your code can tell you that.

Close it: run a code search across every repository that calls the provider. Our guide to finding deprecated model IDs has a ripgrep recipe, including the file types people forget.

Gap 3: usage data shows what ran, not what's written

A usage export is evidence of calls that happened in a period. Code that runs rarely can be absent from it:

• fallback and retry paths (more on those);
• monthly or quarterly jobs;
• evaluation and benchmark scripts;
• staging or regional configs that see little traffic.

Close it: compare usage data with the code search. Anything in the search but not in the usage data is a rarely run path to check by hand. Anything in the usage data but not in the search is probably an ID assembled at runtime.

Gap 4: the platform you use may have its own date

If you call a model through a cloud platform, such as Claude on Amazon Bedrock or Google Vertex AI, the platform sets its own retirement date, which can differ from the model maker's. The model maker's email covers its own API. The platform's notices come from the platform, possibly to a different account owner.

Close it: for each call site, note which platform it uses and read that platform's date. See why your Bedrock Claude may retire on a different date.

Gap 5: the break may not be the model ID

Some changes affect request parameters rather than identifiers. Claude 4.7 and later models reject temperature, top_p and top_k with HTTP 400, and version 1.0 of Anthropic's Python SDK removed them. A notice about a model retirement won't necessarily point out that your replacement rejects a parameter you send. See our note on sampling parameters.

Close it: when choosing a replacement, read its documentation for parameter differences, and run a small evaluation set. Every request-level incompatibility shows up on the first run.

Gap 6: notices are point-in-time

Each notice is a single event. Between notices, nobody is checking whether a retired ID has crept back in, for example through a code snippet copied from an old service or a tutorial.

Close it: add a CI check that fails when a retired identifier appears. A grep against a pattern file works. Keep the patterns up to date when notices arrive.

Gap 7: the clock starts when the email is sent, not when you read it

Anthropic's 2026 retirement announcements gave about 60 to 62 days' notice. If the email takes a week to reach engineering and another week to be scoped, a quarter of the window is gone before work starts. See how notice periods changed between 2025 and 2026.

Close it: treat each notice as a project with an owner on day one. Our 60-day runbook is a template.

A process that closes the gaps

Put together, a lightweight process looks like this:

1. Routing: provider notices reach a shared engineering address.
2. Inventory: a list of repositories and services that call AI APIs, with the platform each uses.
3. Search: on each notice, run a code search across that list and compare with usage data.
4. Ownership: one owner per retirement, with a dated plan.
5. Prevention: model IDs kept in one place per service (guide), plus a CI check for retired identifiers.

None of this replaces the provider's notice. It's what you build around it so the notice turns into finished work before the date.

Where SunsetLint fits

SunsetLint, a GitHub App in early access, is being built to automate steps 3 and 5: it is designed to match retiring identifiers in your repositories against rules taken from providers' notices, and post the results as a GitHub issue with file, line, date and a link to the source. It doesn't replace the notice. Each rule points back to it.

If your setup is small, the manual process above works well on its own, and a free feed such as deprecations.info can cover the "when" side. Either way, read the provider's page first.