Model Deprecations: An API Sunset Survival Playbook

A model deprecation calendar stopped being optional this month. Inside one July, DeepSeek retired its legacy deepseek-chat and deepseek-reasoner API aliases, the Model Context Protocol spec formally deprecated three protocol capabilities, and OpenAI’s Sora API kept counting down to its September 24 shutdown — three unrelated providers, three unrelated clocks, zero coordination between them.

What’s at stake is not dramatic downtime; it’s the quiet 400 error on a Tuesday morning when an alias you forgot you were calling stops resolving. Every one of these sunsets was announced well in advance — three months, roughly six months, and a twelve-month floor respectively. The operational failure mode in 2026 is not “no warning.” It’s “warning ignored, because nobody on the team owned tracking it.”

This playbook lines up the three July clocks side by side, borrows the cleanest public deprecation policy (Anthropic’s four-stage lifecycle) as a template, normalizes four vendors’ notice periods into one comparison table you won’t find anywhere else, and then walks through the four moves — inventory, contract tests, a routing layer, and an owned calendar — that turn a surprise cutover into a scheduled, boring migration.

None of these three events had anything to do with each other. A model provider renamed its API surface, a protocol spec shed old capabilities, and an AI-video product line continued its wind-down. They didn’t share a cadence, a notice format, or an announcement channel — which is precisely the point. If your stack touches more than one AI provider, deprecation events now arrive on independent, overlapping schedules that no single vendor page will summarize for you.

The runway shapes are as different as the events themselves. Plotted against a twelve-month baseline, the four notice policies in this post — the three July actors plus Anthropic’s written floor — look like this:

Read one trend out of that chart before moving on: every provider here gave real, dated, public notice. Across all four policies studied for this post, not one silently broke existing calls on announcement day. The gap between “vendor announced it in April” and “our integration threw 400s in July” is entirely on the consuming team’s side of the fence — which is good news, because it means the fix is a process you control, not a vendor behavior you have to hope for.

DeepSeek’s April 24, 2026 changelog entry was unambiguous: “The two legacy API model names, deepseek-chat and deepseek-reasoner, will be discontinued in three months (2026-07-24).” The cutover landed on schedule — July 24, 2026 at 15:59 UTC — per the DeepSeek API changelog. Requests using the old names now route or fail per the documented cutover rather than quietly resolving to whatever DeepSeek’s current default happens to be.

The replacement naming is the V4-era scheme: deepseek-v4-flash and deepseek-v4-pro are the current model IDs on the DeepSeek models and pricing page, while the retired aliases pointed at the naming convention that predates V4. As of this writing, V4 itself is still in its Preview naming era — the alias retirement was a housekeeping move around that generation shift, not a capability change.

That makes DeepSeek’s the narrowest blast radius of the month: same underlying capability, new name only. It’s also the most instructive failure case, because a pure rename is exactly the kind of change that survives every functional test except the one that actually calls the API with the old string. We covered the migration mechanics in detail in DeepSeek’s Jul 24 alias retirement, in detail — the short version is that a one-line model-ID constant was the difference between a non-event and an outage.

Worth noting for calendar-builders: DeepSeek named the exact cutover date in the same changelog entry that announced the deprecation, 91 days ahead. A fixed date you can put on a calendar is materially more useful than a floating “at least N days” policy — it converts a monitoring problem into a scheduling problem.

The Sora wind-down is the opposite shape. OpenAI discontinued the Sora web and app experiences on April 26, 2026, and the underlying API follows on September 24, 2026. The OpenAI deprecations page states it plainly: “On March 24th, 2026, we notified developers using the Videos API and Sora 2 video generation model aliases and snapshots of their deprecation and removal from the API on September 24, 2026.”

Six named surfaces sunset together on that date: the Videos API itself, plus the model IDs and snapshots sora-2, sora-2-pro, sora-2-2025-10-06, sora-2-2025-12-08, and sora-2-pro-2025-10-06. Critically, the deprecations page lists no recommended replacement for any of them. This is an exit from a product line, not a migration to a successor model — teams building on Sora need a different vendor, not a new model string. For the competitive lay of the land those teams are now shopping in, see our AI video generation comparison, which was already tracking the September 24 sunset clock in May.

The Sora case adds one more column to your calendar schema: notice length varies with blast radius. OpenAI gave roughly six months — 184 days from the March 24 notification to the September 24 removal — for a full product exit, double DeepSeek’s runway for a rename. That’s a pattern worth internalizing rather than a rule you can rely on: bigger disruptions have tended to come with longer runways, but nothing obligates a vendor to keep that proportion.

The third clock is a spec, not a vendor. The Model Context Protocol’s 2026-07-28 specification release formally deprecated three capabilities — Roots, Sampling, and Logging — along with the legacy HTTP+SSE transport. Unlike a model retirement, nothing broke on announcement day, and the spec commits in writing to keeping it that way for at least a year.

The headline change in the same release explains why the old pieces had to go: MCP moved to a stateless protocol core. Each request now carries its own protocol version and client identity instead of relying on a session handshake with an Mcp-Session-Id header — which is what lets MCP servers run behind standard load balancers without shared session storage. The HTTP+SSE transport being shed here was already deprecated back on March 26, 2025, in favor of stdio and Streamable HTTP; any integration guide still recommending SSE for new builds is working from stale documentation.

One trap specific to MCP inventories: capability names live on both sides of the client/server boundary, and teams routinely file them on the wrong side. In MCP’s architecture, Sampling, Roots, and Elicitation are capabilities declared by clients, not servers — so when you audit “which of our MCP surfaces touch a deprecated capability,” check your client configurations and host applications, not just the server manifests. An inventory that only greps server code will report a false all-clear.

The twelve-month floor makes MCP the gentlest of the three July events — and also the easiest to procrastinate on. A deprecation with no near-term breakage date is exactly the item that needs a calendar entry with an owner, because nothing else will ever force it onto a sprint board until the floor runs out, no earlier than late July 2027.

If you’re going to model your internal deprecation calendar on one public policy, Anthropic’s model deprecations page is the cleanest template we found. The written commitment: “Anthropic notifies customers with active deployments for models with upcoming retirements, providing at least 60 days’ notice before model retirement for publicly released models.” Around that floor sits an explicit four-stage lifecycle:

The documented model table shows this is a working cadence, not a paper policy. Computing the gaps from Anthropic’s own published dates: claude-opus-4-1-20250805 was deprecated June 5, 2026 with retirement set for August 5, 2026 — a 61-day gap. claude-sonnet-4-20250514 and claude-opus-4-20250514 were deprecated April 14 and retired June 15, 2026 — 62 days. claude-3-haiku-20240307 went from a February 19 deprecation to an April 20, 2026 retirement — 60 days on the nose. Every observed window clears the written 60-day floor, by zero to two days of margin.

Three more details make the policy worth copying wholesale. First, deprecation isn’t deletion: Anthropic commits to preserving the weights of every publicly released model for “at minimum, the lifetime of Anthropic as a company,” per its deprecation commitments — retired from the API is not gone forever. Second, deprecation reaches below the model level: temperature, top_p, and top_k now return a 400 error if set to a non-default value on Claude Opus 4.7 and later — a parameter-level deprecation that a naive model-ID inventory would miss entirely. Third, there’s a self-serve audit: the Claude Console’s usage export (CSV, broken down by API key and model) exists specifically so teams can find lingering calls to deprecated models before the retirement date.

The cloud-platform side has its own runway shapes, though we could only confirm the specifics through secondary documentation summaries. Google Cloud’s Vertex AI lifecycle policy reportedly blocks new access to a retiring model about one month before its retirement date (for online inference, batch inference, and tuning), and its “short-term availability” model class reportedly retires 45 days after a replacement model ships — materially different shapes from Anthropic’s fixed 60-day floor or OpenAI’s six-month Sora notice. Verify both figures against the live Vertex AI model-lifecycle documentation before planning around them. Secondary tracking of Vertex AI release notes likewise reports that Gemini 2.5 Pro, Flash, and Flash-Lite retirement dates were pushed out to October 16, 2026 — a useful reminder that deprecation dates are not fixed in stone. They get extended, which is one more reason an owned calendar beats a one-time migration scramble.

No vendor publishes this view, because each states its policy in a different format — a fixed calendar date, an “at least N days” floor, or an “at least N months” compatibility guarantee. The table below normalizes the four policies covered in this post onto one comparable grid. Day counts are computed from each pair of announced and effective dates; policy floors are quoted as stated.

Sources: the DeepSeek API changelog, OpenAI’s API deprecations page, Anthropic’s model-deprecations page, and the MCP 2026-07-28 release notes — all primary. The lifecycle-stage vocabulary (Active → Legacy → Deprecated → Retired) is Anthropic’s; the other providers don’t name their stages, which is itself a finding. When you build the internal version of this table, add two columns the vendors can’t give you: which of your systems reference each surface, and who owns the migration.

Vendor deprecation pages tell you when something breaks. None of them tell you how to build the muscle that stops it from being a surprise. That gap is the playbook — four moves, in dependency order:

Move 03 is where most teams get the compounding return, because it converts every future sunset from an engineering project into a configuration decision. If you already run multi-vendor routing for cost reasons, you have this layer — our LLM model-routing engineering guide covers the architecture, and pairing a deprecation calendar with a cost-routing discipline means the same inventory serves two budgets: risk and spend.

Looking forward, we’d expect the deprecation tempo to accelerate rather than settle. Model generations are shipping closer together, protocol specs are versioning faster, and July 2026’s three overlapping clocks are more likely a preview of the ordinary operating environment than an outlier month. Machine-readable deprecation feeds may eventually emerge — the absence is conspicuous — but until they do, the owned calendar is the only reliable substitute. If you’d rather not build that operational muscle alone, our AI transformation engagements set up exactly this kind of vendor-lifecycle governance alongside the routing layer it depends on.