Two model retirement notices in two days. November 16 and January 14 are now dates on your change calendar

On October 14, OpenAI notified developers that five API snapshots will be removed on January 14, 2027: gpt-4o-2024-08-06, gpt-4o-2024-11-20, gpt-4o-mini-2024-07-18, gpt-4.1-2025-04-14 and gpt-4.1-mini-2025-04-14. The recommended replacement for all of them is gpt-6-luna. Fine-tuned models built on those snapshots shut down on the same date.

The next day, GitHub announced that Claude Opus 4.8, Claude Opus 5 and GPT-5.6 Terra leave GitHub Copilot on November 16, 2026, across Copilot Chat, inline edits, ask and agent modes and code completions. The suggested replacements are Claude Opus 5.5 for the two Claude models and GPT-6.1 Sol or GPT-6 Luna for Terra. Individual subscribers on annual plans keep Opus 4.8.

Neither notice is a crisis. Together they are a calendar, and most enterprises do not yet manage model dependencies on one.

The next 90 days

October 2026January 2027

1. NoticesOpenAI on Oct 14, GitHub on Oct 15
2. Nov 16Three Copilot models retire
3. Mid DecemberOur suggested last date to cut over API workloads
4. Jan 14, 2027API snapshots and their fine-tunes removed

What is and is not retiring

Precision matters here, because the wrong reading wastes a quarter. OpenAI’s notice covers specific dated API snapshots. It does not say every GPT-4 family model or ChatGPT is affected, and it does not mention ChatGPT at all. GitHub’s notice covers Copilot experiences, not the providers’ own APIs. If your team reads “GPT-4o is going away” and plans a ChatGPT change, or reads “Opus 5 is retired” and rewrites an Anthropic API integration, both are wrong.

Where model identifiers hide

The applications that call a model directly are the easy part of an inventory. The hard part is everything else that pins a model:

• Evaluation pipelines and LLM judges. A judge running on a retiring snapshot will change its scores when it moves, even if the system it grades does not. We saw this with Snowflake’s judge switch: scores across judge versions are not comparable.
• Fine-tuned models. These need retraining or replacement, not just a new identifier. Retraining needs the training data, which someone has to find.
• Routing configurations and gateways, where a model name sits in a policy file nobody associates with the application.
• Scripts, notebooks and scheduled jobs owned by analysts, outside any software inventory.
• Copilot model policies. GitHub says admins need no action if the global default for new models is on. If your enterprise turned that default off, replacements must be enabled by hand, or developers lose the models with nothing in their place.

A migration is a release

The replacement is more capable, and that is the risk. A newer model changes output length, formatting, refusal behavior, latency and cost per task. Prompts tuned for the old snapshot, parsers that expect its formatting and cost forecasts that assume its token counts can all break without any code change. As we wrote when Databricks retired models in early October, model retirement changes behavior, not syntax, so it needs a regression set, a side-by-side run and a named approver, like any other change.

For coding agents, the November date is closer and the evaluation is different. Developers will notice quality shifts before any dashboard does. Run the replacement models on a sample of real tasks now, compare acceptance of their changes, and decide which replacement becomes the default before the menu changes on its own.

Make the inventory permanent

These will not be the last notices. The useful outcome of this quarter is not two completed migrations; it is a register where every model dependency has an owner, a purpose, an evaluation set and a known retirement date, and where a new notice turns into tickets within a day. Google’s sale stop for Gemini Code Assist taught the same lesson from the procurement side: the renewal date is the real decision date. For models, the retirement date is.