OpenAI Is Deleting GPT-5 and o3 in December and the Teams That Pinned Their Models Break First

The change, and the date that matters

On June 11, 2026, OpenAI notified developers that six current-generation model snapshots will be removed from the first-party OpenAI API on December 11, 2026. The affected snapshots are gpt-5-2025-08-07, gpt-5-mini-2025-08-07, gpt-5-nano-2025-08-07, gpt-5-pro-2025-10-06, o3-2025-04-16, and o3-pro-2025-06-10. After the shutdown date, requests that target one of those exact dated IDs stop being served. There is no grace period baked into the IDs themselves: a request that named a retired snapshot the day before keeps working, and the same request the day after returns an error instead of a completion.

This is the direct OpenAI API, not Azure OpenAI. The two platforms run separate model lifecycles and separate retirement calendars, so an Azure deployment is governed by a different notice with different dates. If you also run models through Azure, track that timeline separately, as covered in our writeup of the Azure OpenAI GPT-4o retirement schedule.

Who gets hit hardest, and why

The teams most exposed are the ones who did exactly what OpenAI told them to do. Pinning an exact dated snapshot ID is OpenAI's own recommended practice for production, because it gives you reproducible behavior: the model behind the ID does not silently shift under you between deploys. That is the right call for anything where output stability matters, which is most serious systems.

The trade-off is that a pinned snapshot has a finite life. When OpenAI retires it, the pin that protected you from drift becomes the thing that breaks you. So the blast radius is widest for disciplined, reproducibility-conscious teams: regulated workloads, anything with a recorded eval baseline, agent frameworks where a single wrong token derails a tool call, and any service where the model ID lives in config rather than being chosen at runtime.

The ID is rarely in just one place. It tends to be scattered across application code, SDK initialization, environment variables, infrastructure-as-code, prompt templates, agent and tool definitions, batch jobs, and notebooks that someone promoted to a cron. Each copy is an independent failure point on the same date.

The failure mode in plain terms

There are two distinct behaviors, and conflating them is how teams get surprised.

If you pinned a dated snapshot, the failure is loud. After December 11, 2026, every call to a retired ID fails. Whether that surfaces as a handled error or a customer-visible outage depends entirely on how your code treats a model-level API failure, and most code treats it as fatal.

If you used the floating alias instead (for example gpt-5 rather than gpt-5-2025-08-07), the failure is quiet, and that is the more dangerous case. The alias keeps working because it is repointed to a newer model. Your requests still succeed, but the model answering them changes. Latency, token usage, refusal behavior, JSON adherence, and tool-call formatting can all shift without a single error in your logs. A loud break gets fixed in an afternoon. A silent behavior change gets discovered weeks later through a support ticket or a metric that drifted.

What the replacement targets are right now

At the time of writing, the deprecations page maps each retired snapshot to a specific replacement that is already live in the API: gpt-5-2025-08-07 and o3-2025-04-16 both point to gpt-5.5, gpt-5-pro-2025-10-06 and o3-pro-2025-06-10 point to gpt-5.5-pro, gpt-5-mini-2025-08-07 points to gpt-5.4-mini, and gpt-5-nano-2025-08-07 points to gpt-5.4-nano. These are all real, generally available API models as of mid-2026, so there is a concrete target to migrate to today rather than a placeholder. Treat that mapping as a snapshot in time, not a constant: vendor lineups shift, and OpenAI can update the recommended replacement after publication, so reconfirm the exact target on the deprecations page at the moment you cut over.

What to do before December

Treat this as a scheduled migration, not an incident waiting to happen. The work is small if you start now and ugly if you start on December 10.

• Inventory first. Grep the entire codebase, SDK config, environment files, IaC, and every prompt, agent, and tool definition for the six retired IDs and for any bare floating alias. Search artifacts that are not in the main repo too: notebooks, batch scripts, serverless functions, and vendored config.
• Decide pin versus alias deliberately per workload. Re-pin to a newer dated snapshot where reproducibility matters. Use a floating alias only where you genuinely accept silent model changes.
• Stage the replacement behind a feature flag so you can flip it forward and roll it back without a redeploy.
• Run a regression eval against your own task suite before cutover, comparing the new model to your recorded baseline on the outputs you actually care about, not a generic benchmark.
• Watch cost and latency in the eval, not just correctness. A newer model can change your token economics and your p95.
• Cut over early, well before the deadline, and keep the flag in place until the new model has run clean in production for a meaningful window.

One honest caveat

This is a planned, pre-announced retirement, not an emergency. OpenAI gave roughly six months of notice, published the list, and mapped each retired snapshot to a replacement that is already available. For a team that pins IDs and runs evals, this is routine lifecycle hygiene, the kind of thing that should be boring.

The risk is not the policy, it is latency-to-action. The danger is the forgotten pin in a low-traffic service, the notebook nobody owns, or the assumption that the floating alias makes you immune when it actually trades a loud failure for a silent one. Re-verify the snapshot list, the replacement targets, and the December 11, 2026 date directly against the official deprecations page before you act, because vendor model lineups change and a notice can be updated after publication. Do not over-rotate either: there is no need to rush a panicked swap in June for a December deadline. Plan it, eval it, ship it on your schedule.

How a senior team de-risks it

The reason this lands as a deadline for some teams and a non-event for others is almost entirely about pipeline maturity. The de-risked version looks the same as any other safe dependency upgrade: the model ID is a single configurable value, not a string copy-pasted across twelve files; swapping it is a flag flip, not a redeploy; and an eval suite gates the change so a regression is caught in CI instead of in production.

That is ordinary delivery engineering applied to a model dependency. A model ID is a dependency with an end-of-life date, and it deserves the same treatment as a runtime or a base image you know will be deprecated: inventoried, version-controlled, tested behind a flag, and rolled out on a schedule you chose. Building that muscle once, in a tested CI/CD pipeline, turns every future model retirement from a fire drill into a checklist. The next deprecation notice is not a question of if, so the work that makes this December boring is the same work that makes the next one boring too.

Sources

• OpenAI API Deprecations (official)
• OpenAI Platform Deprecations (redirects to the official deprecations page)
• Introducing GPT-5.5 (OpenAI)
• Introducing GPT-5.4 mini and nano (OpenAI)