2026-2027 Model Retirement Calendar: What to Migrate When

2026 and 2027 carry a quiet risk for the AI models you run in production: Anthropic, OpenAI, and the Model Context Protocol (MCP) all published successive model retirement schedule entries during the same period, and a model ID embedded in your code can turn a missed announcement into a failing request on retirement day. This post merges the dates gathered from official deprecation pages into a single migration map and shows you how to make your code resilient to this cycle.

💡 Pro Tip: Don't just bookmark the provider's deprecation page — write a small script that pulls it from the API itself and raises an alert in CI, so the pipeline notices before you do.

Table of Contents

• Why You Should Keep a Model Retirement Calendar
• The Difference Between Silent and Hard Cuts
• The Anthropic Side: Retired Models and Their Dates
• "Not Sooner Than" Dates for Still-Active Models
• How to Use the 60-Day Window
• The OpenAI Side: Closing APIs and the February 2027 Horizon
• October 23, 2026: Old GPT Snapshots Shut Down
• December 11, 2026: GPT-5 and o3 Snapshots
• The 12-Month Deprecation Window in MCP
• The Practical Takeaway for Teams Running an MCP Server
• Why MCP Runs on a Different Rhythm
• The Cost of Hardcoding a Model ID Into Your Code
• Fallback Chain and Version-Pinning Pattern
• It's Worth Monitoring Fallback Triggers
• Quarterly Audit Checklist
• Partner Platforms: Vertex AI and Bedrock Run a Separate Schedule
• FAQ
• Which AI models are retiring in 2026-2027?
• Has Claude Opus 4.1 retired, and what should I use instead?
• Did the OpenAI Assistants API shut down?
• How do I write code that's resilient to model retirement?
• Why do my parameters break when I switch to a new model?
• I run an MCP server — do I need to do anything right now?
• Conclusion
• Sources

Why You Should Keep a Model Retirement Calendar

AI providers design model retirement as a hard cut, not a silent quality drop. Anthropic's official deprecation page states that requests to a retired model ID will fail ("Requests to retired models will fail") — the model doesn't quietly downgrade to a weaker version, the request errors out directly. The only mitigation is Anthropic's committed minimum notice period: a model is announced at least 60 days before it retires.

The prerequisite for using this 60-day window is knowing which models you actually use. Anthropic officially recommends pulling a CSV export from the "Usage" section in the Console for this; if you use a dated ID (claude-3-7-sonnet-20250219) in your code instead of an alias like claude-3-7-sonnet, this export shows you exactly which API key is calling which model.

The Difference Between Silent and Hard Cuts

• Hard-fail: the model used by both Anthropic and OpenAI — after the retirement date, the request errors instantly, and without a fallback, production goes down.
• Transition window: some deprecations (like MCP) guarantee a minimum 12-month period; the old behavior keeps working throughout that time.
• Notice commitment: a single minimum threshold on Anthropic's side (60 days), tiered thresholds on OpenAI's side depending on model type (at least 6 months for GA, much shorter periods like 2 weeks for preview).

The Anthropic Side: Retired Models and Their Dates

According to Anthropic's official model-deprecations page, seven model IDs across six separate announcements have retirement dates falling within 2026. The table below summarizes each announcement's date, retirement date, and recommended replacement model.

Two rows point to claude-haiku-4-5-20251001; since this ID's own "not sooner than" floor is October 15, 2026, verify the page's current row before you migrate.

Opus 4.1's retirement stands out: 61 days between announcement and retirement, just above the committed minimum of 60. A similar 62-day window ran for the Sonnet 4 and Opus 4 pair too (April 14 → June 15). The table's first row sits well above that minimum: Claude Opus 3's announcement (June 30, 2025) came 189 days before retirement (January 5, 2026); Sonnet 3.7 had 114 days. Haiku 3 lands exactly on the 60-day edge (February 19 → April 20, 2026). So 60 days is a floor — sometimes you get more, but you can't plan around it.

"Not Sooner Than" Dates for Still-Active Models

Anthropic also gives a "will not be retired before this date" commitment for models it still recommends. As an example, here are the floors given for three current models; these models are active and will not retire before the following dates at the earliest:

• claude-fable-5-1: not before September 1, 2027.
• claude-opus-5: not before July 24, 2027.
• claude-sonnet-5: not before June 30, 2027.

These dates aren't a guarantee, they're a floor — they answer the "when could this break at the earliest" question when you're planning.

How to Use the 60-Day Window

Once a deprecation announcement lands, you have at least 60 days; splitting that time into three steps beats spending it randomly. First, pull the Usage export from the Console and find which endpoints call the retiring model ID. Next, try the recommended replacement (the table gives this directly) in staging with the same prompt set and compare output quality. Finally, update MODEL_MAP and roll it out gradually (canary-style); spend the last week of the 60 on verification, not emergency firefighting.

If you don't follow this order, the typical mistake is leaving the migration code change to the last day, then discovering on the retirement date that an untested model ID behaves unexpectedly in production. 60 days isn't short, but it feels short when you don't plan backward from the deadline.

The OpenAI Side: Closing APIs and the February 2027 Horizon

Unlike Anthropic's single 60-day commitment, OpenAI's official deprecations page tiers its notice period by model type. The page's "Model deprecation notice periods" section defines three thresholds: at least 6 months for generally available (GA) models, at least 3 months for special variants of GA models (chat variants, Codex variants like gpt-5.3-codex, deep research variants like o3-deep-research), and a much shorter "something like 2 weeks" for models with preview in the name. The page also notes an exception: these periods can shrink for security or compliance reasons, and OpenAI says it will give "as much notice as reasonably possible." The practical takeaway: if you put a model labeled preview into a business-critical flow, your contract is a two-week window.

The Assistants API is the most visible long-window example of this policy — the shutdown happened on August 26, 2026, and the announcement came exactly one year earlier, on August 26, 2025. Instead of an automatic converter, an official migration guide was provided: the page points directly to the "Assistants to Conversations" guide, with the recommended path being to move to the Responses API and the Conversations API.

On the audio side, the whisper-1 and gpt-4o-transcribe family were deprecated on August 26, 2026; the shutdown is scheduled for February 26, 2027 — a planned cut to track. The migration splits by use case: OpenAI's transcription guide names gpt-transcribe for completed recordings (file transcription) and gpt-live-transcribe for live streaming audio (realtime transcription).

October 23, 2026: Old GPT Snapshots Shut Down

OpenAI's official deprecations page lists a shutdown scheduled for October 23, 2026 for the GPT-3.5-turbo, GPT-4, and o1/o3-mini family. This is a batch cut announced on April 22, 2026 — one day above the minimum 6-month threshold given for GA models (184 days). The same table also closes the gpt-4-turbo, gpt-4o-2024-05-13, o1-pro, o4-mini, and gpt-image-1 (→ gpt-image-2) rows on the same date. If you still have an endpoint calling these models, you need to finish the migration by October 23, 2026; the page's given replacements are gpt-5.6-terra (gpt-3.5-turbo, o4-mini), gpt-5.6-sol (gpt-4, o1, o3-mini), and gpt-5.6-luna (gpt-4.1-nano).

December 11, 2026: GPT-5 and o3 Snapshots

The second batch cut, announced on June 11, 2026, covers the most widely used snapshots in 2026 production: gpt-5-2025-08-07 and o3-2025-04-16 → gpt-5.6-sol, gpt-5-mini-2025-08-07 → gpt-5.6-terra, gpt-5-nano-2025-08-07 → gpt-5.6-luna, gpt-5-pro-2025-10-06 and o3-pro-2025-06-10 → gpt-5.6-sol (reasoning.mode: pro). The shutdown is scheduled for December 11, 2026. The legacy audio/realtime family announced on July 20, 2026 (gpt-realtime → gpt-realtime-2.1, gpt-audio → gpt-audio-1.5) is scheduled for January 20, 2027.

1{
2  "provider": "openai",
3  "deprecations": [
4    {
5      "model": "assistants-api",
6      "shutdown": "2026-08-26",
7      "status": "closed"
8    },
9    { "model": "whisper-1", "shutdown": "2027-02-26", "status": "planned" },
10    {
11      "model": "gpt-5-2025-08-07",
12      "shutdown": "2026-12-11",
13      "status": "planned"
14    },
15    {
16      "model": "gpt-3.5-turbo",
17      "shutdown": "2026-10-23",
18      "status": "planned"
19    },
20    { "model": "gpt-4", "shutdown": "2026-10-23", "status": "planned" }
21  ]
22}

This post focuses on the text, reasoning, and audio model families; for image and video models and platform products, scan the official deprecations page in full.

The 12-Month Deprecation Window in MCP

The Model Context Protocol side follows a different policy than the provider APIs: a guaranteed minimum 12-month deprecation window. The official spec announcement dated July 28, 2026 (SEP-2577) deprecated the protocol's Roots, Sampling, and Logging features — but these features are designed to keep working for at least 12 months from the announcement, meaning the earliest actual removal won't happen before July 2027.

The same announcement also deprecated the legacy HTTP+SSE transport with a one-year "offramp." The move from DCR (Dynamic Client Registration) to CIMD (Client ID Metadata Documents) follows similar logic: the old method stays backward compatible but is slated for removal.

The Practical Takeaway for Teams Running an MCP Server

• Roots/Sampling/Logging: avoid using these in new integrations, migrate existing usage within the 12-month window.
• HTTP+SSE transport: prefer the current transport in new servers, schedule old servers according to the offramp timeline.
• DCR → CIMD: review your client registration flow against the new standard, but no urgent action is required.

Why MCP Runs on a Different Rhythm

Anthropic's and OpenAI's model deprecations affect a single endpoint — one model ID closes, its alternative takes over. MCP is different: the protocol itself is used by dozens of different servers and clients implementing it, so removing a feature requires the entire ecosystem to move in sync, not just one company. The 12-month minimum window is the direct result of that synchronization need — much longer than the 60-day notice on provider APIs, because there are far more independent implementations on the other side that need to update.

The practical consequence: don't rush on the MCP side, but don't read the 12-month window as "lasts forever" either — when July 2027 actually approaches, an integration still using Roots/Sampling/Logging genuinely breaks at that point.

The Cost of Hardcoding a Model ID Into Your Code

There are two breakage scenarios, both rooted in code written on fixed assumptions. The first is embedding a dated Anthropic model ID (like -20250514) directly in code — when the retirement date arrives, the request fails hard, because you're calling a version locked to that date, not an alias.

The second is subtler: assuming a previous model's parameter assumptions still hold after you switch models. The GPT-6 Astra example shows this — per the model page, reasoning.effort only supports low, medium, high, xhigh, and max, and the guide's Limitations section states: "GPT-6 Astra does not support the none reasoning effort; GPT-6 Sol and Luna do." So a call sending reasoning.effort: "none" breaks when moved from Sol or Luna to Astra. The same trap exists on Anthropic's side: the official page deprecated temperature, top_p, and top_k for Claude Opus 4.7 and later, returning a 400 error for non-default values.

1// Fragile: dated ID + default parameter baked in
2const response = await client.messages.create({
3  model: "claude-3-7-sonnet-20250219", // retired on February 19, 2026
4  temperature: 0.7,
5  max_tokens: 1024,
6});

Both errors share a common root: the code was written on the assumption of "it works right now," rather than accounting for the provider's deprecation calendar and the model family's parameter surface.

Fallback Chain and Version-Pinning Pattern

Anthropic's "Recommended replacement" column and "not sooner than" dates exist exactly for this: to let you pin to a dated ID while building a fallback chain that automatically drops to the recommended model on retirement. The pattern below manages the model call from a single place and separates the deprecation list from the code.

1type ModelAlias = "primary" | "fallback";
2 
3type MessagePayload = Record<string, unknown>;
4 
5interface MessagesClient {
6  messages: {
7    create(params: MessagePayload & { model: string }): Promise<unknown>;
8  };
9}
10 
11declare const client: MessagesClient;
12 
13const MODEL_MAP: Record<ModelAlias, string> = {
14  primary: "claude-opus-4-8",
15  fallback: "claude-sonnet-4-6",
16};
17 
18// Confirm from your own SDK which error code means "model not found";
19// the 404 below is just an example, not a provider contract.
20function isModelUnavailableError(err: unknown): boolean {
21  return (
22    typeof err === "object" &&
23    err !== null &&
24    (err as { status?: number }).status === 404
25  );
26}
27 
28export async function callWithFallback(
29  alias: ModelAlias,
30  payload: MessagePayload,
31): Promise<unknown> {
32  // if the called alias is retired, the other alias in the chain kicks in
33  const next: ModelAlias = alias === "primary" ? "fallback" : "primary";
34  try {
35    return await client.messages.create({
36      model: MODEL_MAP[alias],
37      ...payload,
38    });
39  } catch (err) {
40    if (!isModelUnavailableError(err)) throw err;
41    return await client.messages.create({ model: MODEL_MAP[next], ...payload });
42  }
43}

• Alias layer: the model name is written to a single MODEL_MAP constant, not directly into business logic.
• Fallback trigger: a second call kicks in automatically when a model-not-found error is caught.
• Single point of update: when a new retirement is announced, only MODEL_MAP changes, not the calling code.

It's Worth Monitoring Fallback Triggers

Once you've built the fallback chain, the truly valuable information is how often it fires. A fallback that keeps kicking in during production points to one of two things: either the primary model has genuinely retired and MODEL_MAP wasn't updated, or the primary model has a temporary capacity/error issue that you're not noticing because the fallback is masking it. Logging every trigger inside the fallback block with a fixed log line and counting it is the cheapest way to tell these two scenarios apart.

Quarterly Audit Checklist

You need to tie information from three sources into a single routine. The bash script below is a simple skeleton that reminds you of the four checks in one command:

1#!/usr/bin/env bash
2# quarterly-model-audit.sh
3echo "1) Anthropic Console -> Usage -> download CSV export, look for dated IDs"
4echo "2) Check https://developers.openai.com/api/docs/deprecations"
5echo "3) Scan the changelog at https://blog.modelcontextprotocol.io"
6echo "4) Compare the MODEL_MAP constant against the deprecation dates"

The checklist can be reduced to four items:

• 60-day notice window: mark every new deprecation Anthropic announces on your calendar.
• CSV usage audit: use the Console export to verify which dated IDs are still called in production.
• 12-month MCP window: schedule Roots/Sampling/Logging and legacy transport usage against the offramp timeline.
• Monthly OpenAI changelog scan: as with the Assistants API example, cuts announced far in advance can slip past you.

Partner Platforms: Vertex AI and Bedrock Run a Separate Schedule

The scope of the Anthropic table above is bounded by the source itself. The official deprecation page states: "Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ." So if you call the same Claude model through Google Cloud (Agent Platform / formerly Vertex AI) or Amazon Bedrock, the retirement dates in this post aren't binding for you; Anthropic's page points you to its own Google Cloud and Bedrock model tables in that case.

The practical consequence: keep your model inventory organized by platform, not by provider. Assume the same claude-opus-4-8 call can have different retirement dates through the Claude API versus Vertex AI; open a separate row in your audit list for each platform and treat that platform's own lifecycle page as the source of truth.

FAQ

Which AI models are retiring in 2026-2027?

On the Anthropic side, Claude Sonnet 3.7 and Haiku 3.5 (February 19, 2026), Claude Haiku 3 (April 20, 2026), Claude Sonnet 4 and Opus 4 (June 15, 2026), and Claude Opus 4.1 (August 5, 2026) have retired. On the OpenAI side, the Assistants API closed on August 26, 2026; there are scheduled cuts for old GPT snapshots (gpt-3.5-turbo, gpt-4, o1, o4-mini) on October 23, 2026, for the gpt-5 and o3 snapshots on December 11, 2026, for the legacy audio/realtime family on January 20, 2027, and for whisper-1 on February 26, 2027. On the MCP protocol layer, a 12-month deprecation window is running for Roots/Sampling/Logging and the legacy HTTP+SSE transport, starting July 28, 2026.

Has Claude Opus 4.1 retired, and what should I use instead?

Yes, Claude Opus 4.1 was fully removed from the API on August 5, 2026; the announcement was made on June 5, 2026, so Anthropic's committed minimum 60-day notice period was honored. The recommended replacement on Anthropic's official page is claude-opus-4-8.

Did the OpenAI Assistants API shut down?

Yes, the Assistants API was fully shut down on August 26, 2026. The announcement was made exactly one year earlier, on August 26, 2025 — giving a transition window twice as long as the minimum 6-month notice OpenAI commits to for GA models. There's no automatic converter, but there is an official "Assistants to Conversations" migration guide; the recommended path is to move to the Responses API and the Conversations API.

How do I write code that's resilient to model retirement?

Three practices: call models through an alias layer (MODEL_MAP) instead of hardcoding a dated model ID, and build a fallback chain that automatically drops to the recommended model on a deprecation error; periodically scan the provider's deprecation page (Anthropic gives at least 60 days' notice); regularly audit which model IDs are still called in production using tools like Usage → Export CSV in the Anthropic Console.

Why do my parameters break when I switch to a new model?

A new model family may not support every parameter value the previous model supported. GPT-6 Astra accepts low, medium, high, xhigh, and max for reasoning.effort but doesn't accept none — OpenAI's guide states this as "GPT-6 Astra does not support the none reasoning effort; GPT-6 Sol and Luna do." On the Anthropic side, temperature, top_p, and top_k were deprecated for Claude Opus 4.7 and later, and a non-default value returns a 400 error. When you switch models, you need to recheck the parameter surface against the provider's current documentation.

I run an MCP server — do I need to do anything right now?

No, not right now. The window that started with the July 28, 2026 announcement is guaranteed at a minimum of 12 months, so the earliest actual removal won't happen before July 2027. If you use the Roots, Sampling, or Logging features, or the legacy HTTP+SSE transport, it's enough to add this to your quarterly audit list and plan to migrate before the window closes.

Conclusion

A model retirement calendar isn't a one-time read, it's a continuously updated operational discipline. You can start by adding the changes brought by Claude Fable 5.1 and GPT-6 Astra's parameter differences to this calendar. If you run an MCP server, the 12-month stateless migration guide and the MCP security changes connect directly to this post. You can find more depth on how to orchestrate a fallback chain in production in the subagent model assignment and cost guide. Finally, the strategy post on when to use Claude Opus 4.7 can serve as a reference when you review your current model choices.

Sources

• Anthropic Model Deprecations — Anthropic's official retirement and recommended-replacement table for the Claude model families.
• OpenAI API Deprecations — the official shutdown list for the Assistants API, whisper-1, GPT-3.5/GPT-4, and the gpt-5/o3 snapshots.
• MCP Blog: 2026-07-28 Announcement — the official announcement of the Roots/Sampling/Logging deprecation, the transport deprecation, and the 12-month minimum window policy.
• MCP SEP-2577 — the official technical specification of the Roots/Sampling/Logging deprecation (including the one-year support window).
• Anthropic: Claude on Vertex AI — API model IDs — the separate lifecycle table for Claude models called through Google Cloud.
• OpenAI: Using GPT-6 — the official GPT-6 family guide; the none reasoning effort limitation is in the Limitations section.
• OpenAI: Transcription — the official source for the recommended gpt-transcribe / gpt-live-transcribe split after whisper-1.