Your Model Has an Expiry Date

On October 14, OpenAI told developers that gpt-4o, gpt-4o mini, gpt-4.1 and gpt-4.1 mini leave the API on January 14, 2027 [1]. Fine-tuned versions of those models follow the same schedule as the base model. The recommended replacement for all four is gpt-6-luna.

That is a complete deprecation notice: a date, a set of model IDs, a migration target. I have spent the last two years reading about how closed models can change under you without telling you, and here is a case where the provider is telling you, in writing, on a page you can refresh, three months before the call starts returning errors.

The sovereignty argument usually gets made at the level of ownership philosophy. The operational version of it is a calendar, and almost nobody has written down which model IDs their own systems call.

The floors are not the same

OpenAI publishes minimum notice periods rather than a single policy: at least six months for generally available models, at least three months for specialized variants like chat or Codex builds, and preview models that “may be retired with much shorter notice, such as 2 weeks” [1]. It also says plainly not to run preview models in production unless you can migrate on short notice, which is the sort of thing a vendor writes after watching customers do it anyway.

Anthropic’s floor is sixty days. “Anthropic notifies customers with active deployments for models with upcoming retirements, providing at least 60 days’ notice before model retirement for publicly released models” [2].

If your team plans quarterly, sixty days is one missed planning cycle from an outage. If it plans annually, both numbers are shorter than the plan. The migration work is roughly the same in either case: read the release notes, run your evals against the replacement, fix whatever the new model does differently, ship. What changes is how much of that work you can do without a fire drill.

Two announcements, two windows

The two most recent announcements on that same OpenAI page do not have the same window.

The gpt-5.1 family was deprecated on October 1, 2026 and comes out of the API on April 1, 2027, “with six months’ notice” [1]. Exactly six months, as advertised.

The GPT-4 series notice I opened with was given on October 14, 2026 for removal on January 14, 2027. That is three months. The page does not say whether those models had already been marked legacy before the announcement, which would explain the shorter clock, or whether the six-month floor simply did not apply. I cannot settle it from the page, and I would rather say that than pick the reading that makes the policy look tidy.

The practical lesson is the same either way. Read the announcement table for the model you call. Do not compute your own deadline from the policy paragraph, because the announcement is what the API will enforce.

Which model, on which route

A dependency inventory usually gets the model right and the route wrong. “Our model retires in January” is not a fact until you know how you reach it.

gpt-4o-2024-08-06 leaves OpenAI’s API on January 14, 2027 [1]. The same model and version label retires on Microsoft Foundry on April 14, 2027 [4]. Nothing in that model string tells you which calendar applies, so the same dependency lives three months longer on one route than the other. A different GPT-4o build, 2024-05-13, appears on Foundry but not on OpenAI’s own deprecation list and retires on December 9, 2026 [4], six weeks away.

gpt-4.1 shows the same split: January 14, 2027 direct, April 14, 2027 on Foundry [1][4].

Anthropic is explicit that this is expected behavior and not a bug. The dates on its page apply to Anthropic-operated platforms, and “Partner-operated platforms, Amazon Bedrock and Claude Models on Google Cloud (Google managed), set their own retirement schedules, so a model’s lifecycle status and dates can differ” [2]. If your workload runs on Bedrock, Anthropic’s first-party table is not your calendar.

I have not found a single document anywhere that reconciles these schedules against each other. You reconcile them, per model ID, per route, or you find out during an incident.

Three weeks from now

Microsoft’s Foundry table has a cluster on November 19, 2026: o1, o1-pro, o3, o3-mini, o3-pro, o4-mini and o3-deep-research, all deprecated and all retiring that day [4]. Llama-4-Maverick retires the same date. If your reasoning workloads on Azure were built in 2025, you have under a month.

At the partner edge the window collapses. Fireworks models on Standard per-token offerings “are subject to a 15-day notice period prior to model retirement” [4]. Fifteen days is enough time to notice a retirement, not enough time to migrate off one.

Two caveats on that table, both of which matter if you are going to plan against it. It was last updated September 23, 2026, and the foot of the page notes the article was created with AI assistance [4]. Treat the dates as a snapshot with a timestamp, not a contract.

Anthropic’s table carries its own warning label. Its retirement dates for active models sit in a column headed “Tentative retirement date”, and claude-haiku-4-5-20251001 is listed as active with a date of “Not sooner than October 15, 2026”, which has already passed while the table still calls the model active [2]. A date in a tentative column is a floor, not an expiry.

Sometimes it is not the model at all

Anthropic removed the temperature, top_p and top_k parameters in API version 2026-10-21. Sending them now returns a 400 error [2].

Your model can be pinned, your migration tested, your shutdown date circled, and your agent can still fail on a Tuesday because a sampling parameter your code has passed since 2024 is no longer accepted. Pinning a model version protects you from model changes and from nothing else. API versions, response formats, parameter sets and auth flows all move on their own schedules.

Why they do it

Anthropic’s own explanation is the least sentimental thing on either documentation site: retiring models “is currently necessary for making new models available and advancing the frontier, because the cost and complexity to keep models available publicly for inference scales roughly linearly with the number of models we serve” [3].

That is a serving economics problem. It is not a statement about capability, and it will not be solved by better models, because the constraint gets worse as the catalog grows.

The same page commits to preserving the weights of every publicly released model for at least the lifetime of the company [3]. It does not commit to serving them again. Preservation is not availability, and the weights still existing somewhere in a vault is not a continuity plan for the workflow that calls them.

OpenAI does offer an escape hatch, and it is commercial rather than technical: “In some cases, developers may be able to provision dedicated capacity for continued access after a model’s shutdown date. To explore this option, contact our sales team” [1]. That is the honest answer to “can’t we just keep using it”. Sometimes yes, at a price, through a conversation.

Fine-tuning does not buy permanence either, though on Azure it buys a little time. A fine-tuned gpt-4.1 has a training retirement no earlier than the base model’s date and a deployment retirement of October 14, 2027, six months after the base model goes [4]. You get to keep serving your fine-tune for a while. You do not get to keep training it.

One detail in Anthropic’s commitments page is easy to miss. Anthropic says it will produce a post-deployment report when it retires a model, which includes interviewing the model about its own development and deployment [3]. The stated reason is safety: in alignment evaluations, some Claude models took misaligned actions when faced with replacement and given no other recourse, and how a retirement is handled can shape whether that happens. Whatever you think of that research program, it means model retirement is being treated by at least one lab as an event significant enough to document.

The silent part

The standard argument for self-hosting rests on silent degradation: the model you depend on changes underneath you, quality drops, nobody tells you. That happened, and it is documented. Chen, Zaharia and Zou measured GPT-3.5 and GPT-4 across March and June 2023 and found GPT-4’s accuracy on identifying prime versus composite numbers falling from 84% to 51% on the same questions, and concluded that the behavior of the same service “can change substantially in a relatively short amount of time” [5].

That paper is three years old. The version of the risk that is live in 2026 is not silent at all. It arrives by email, it has a date in it, and it is published on a page you can poll.

What is silent is your own inventory. Providers cannot tell you which of your services will break, because they do not know what you built. The team that gets hurt is the one that cannot answer “which model IDs do we call, and when does the earliest one die” without a week of archaeology through six repositories.

What an afternoon buys

I do not think this requires an agent governance platform. The posts that say otherwise tend to be selling one.

Anthropic exposes a usage export in the Console, with usage “broken down by API key and model” [2]. That is your Anthropic inventory, from the provider’s own records, in one CSV. OpenAI exposes an optional shutdown_date field on GET /v1/models, which returns the date as a YYYY-MM-DD string or null if none has been announced [1]. Same idea, from the endpoint your code already authenticates against.

Then grep the repositories for model IDs and API version strings, and reconcile. Where a service calls a model, record the model ID, the route (direct, Bedrock, Foundry, a gateway), the shutdown date for that route, and a named person who owns the migration. Where the shutdown date is null or “tentative”, write the review date instead, because both providers say dates can move earlier for safety or compliance reasons [1][2].

The list will be wrong within a month, so put a recurring review on it and treat the review, not the file, as the control.

Where owning weights helps

I have written before about what self-hosting buys an individual and about the production stack that makes it real, and one part of that argument transfers directly to this problem. A checkpoint you host does not carry an expiry date that someone else sets. No provider can retire it out from under a workload on their own calendar, the route question stops applying because you are not renting a route, and Anthropic’s line about cost scaling linearly with the number of models served stops describing your situation.

What self-hosting removes is the external deadline and the dependency on a control plane you do not operate. It does not remove the operating cost. You still pay for GPU capacity and electricity, and you still need someone to keep the serving stack patched and someone to notice when output quality drifts. Whether that comes out ahead of a scheduled migration depends on whether you already run that capacity and the people to operate it. A team with neither is trading an occasional migration for a standing cost.

I would not oversell it either. The version you can afford to run locally is usually not the version you were calling.

There is also a legal layer that the sovereignty framing tends to skip. If you are selling into DoD, swapping a covered model for an open-weight one is not purely a technical decision, as the provenance rules now show. The open-weight escape route has its own paperwork.

Check the calendar, write down the models you call, and put a name against each migration. Then decide, with the dates in front of you, whether self-hosting is worth the inference team. That choice is worth making once a year, from a list someone is responsible for keeping current, rather than at 2am when a model that retired on a Tuesday turns out to have been inside a Lambda function nobody remembered.

Sources

1. Deprecations — OpenAI API docs
2. Model deprecations — Claude Platform Docs
3. Commitments on model deprecation and preservation — Anthropic
4. Model retirement schedule — Microsoft Foundry, Microsoft Learn (last updated 2026-09-23)
5. How is ChatGPT’s behavior changing over time? — Chen, Zaharia & Zou, arXiv:2307.09009 (2023)