The gpt-5 Alias Points at a Model OpenAI Deletes Dec 11

A support-ticket summarizer that has run quietly for a year stops returning anything on a Friday in December. Nobody deployed. Nobody touched a config file. The line in the code still says model: "gpt-5", the same three words it has said since launch, and that line now points at something OpenAI has switched off.

The date is already on a calendar. OpenAI has two model shutdowns inside the next four months, and the second one is the expensive one for most teams. There's also a comfortable assumption about who it hits, and the assumption is wrong.

Who this actually breaks

OpenAI's deprecation page lists two waves. The first, announced April 22 and landing October 23, 2026, clears out the old furniture: gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-turbo, gpt-4o-2024-05-13, o1-2024-12-17, o3-mini-2025-01-31, and their fine-tuned variants. The second, announced June 11 and landing December 11, 2026, removes what most production systems are running today: 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.

Read that list and an obvious reading suggests itself. Every ID on it carries a date, so the teams at risk must be the ones who pinned a dated snapshot for reproducibility. Everyone who typed the plain short name is presumably riding some maintained rolling release and can ignore the whole thing.

We checked that against the API instead of assuming it. It doesn't hold.

What we ran

Effloow Lab ran an OpenAI API check on August 14, 2026 against one standard company API account. Two things were tested. First, we asked the API to list every model the account can see and compared that list against both shutdown waves. Second, and this is the part that produced the finding, we sent a trivial request (the literal prompt "Reply with the single word: ok") to each undated model name, then read back which model the API said had answered.

Every response carries a model field. It reports the specific dated version that served the request, whatever you typed. It's the API telling you in writing what your traffic is really hitting.

Commands, raw response data, and everything that failed are in the public lab note.

What came back

Five out of five. On this account, on this date, every plain undated name in the gpt-5 and o3 families resolved to precisely the version on the December kill list.

So the comfortable reading collapses. Writing gpt-5 doesn't put you on a maintained rolling release. It puts you on gpt-5-2025-08-07 with a friendlier label. The team that pinned a date at least left a string in the repo that a search will find. The team that used the short name has nothing to grep for and the same deadline.

There's a second, quieter result. The account's model list returned 126 model IDs, and two officially deprecated IDs (gpt-4-1106-preview and o3-pro-2025-06-10) were already missing from it. A published shutdown date is when access is guaranteed to end, not when it starts to end. Some things go early.

The replacement that isn't a replacement

Two rows of OpenAI's migration table deserve separate attention, because a find-and-replace across your codebase will get them wrong.

Start with the shape of the mapping. It isn't one-to-one. Per the deprecation page, gpt-5-mini-2025-08-07 moves to gpt-5.6-terra and gpt-5-nano-2025-08-07 moves to gpt-5.6-luna, while gpt-5-2025-08-07 and o3-2025-04-16 both go to gpt-5.6-sol. Swapping every old ID for one new ID quietly changes the size and price class of half your traffic.

The pro tier is worse. Both gpt-5-pro-2025-10-06 and o3-pro-2025-06-10 are documented as replaced by gpt-5.6-sol with reasoning.mode set to pro. The "pro" capability stopped being a separate product and became a setting. Change the model name alone and you land on a cheaper, different configuration than the one you were paying for. Nothing errors to tell you.

We measured what switching that setting on costs. Same model, same prompt, only the reasoning object changed:

In plain terms: pro mode attached roughly fifteen hundred to two thousand extra tokens of input to a request that was one short sentence (+1,517 and +1,978 across the two pairs). On the short prompt that's about 117 times the input you thought you were sending. At volume, that difference is your bill.

Treat it as a budgeting fact rather than a verdict. Two request pairs is not a benchmark, and we make no claim about whether the output is any better. The point is narrower. The parameter isn't free, and a migration that flips it on everywhere without measuring will show up in the next invoice.

Can this survive your workflow?

Ask something narrower than "do we use OpenAI." Ask where a silent model swap or a hard stop would actually hurt:

• Support ticket triage and summarization. Built early, rarely touched since, usually on the plain gpt-5-mini name. Highest chance of an unfindable string.
• Order and invoice processing. A hard stop here means a queue backing up rather than a slightly worse answer. Loud, expensive, and it'll happen on a weekend.
• CRM enrichment and internal automation. Often written by whoever needed it, deployed once, owned by nobody in particular. No one is reading OpenAI's deprecation page on their behalf.
• Anything with a fine-tuned model. Fine-tunes on a retiring base have no string-swap path at all. That's a retraining project with a lead time, and October 23 is the date on it.
• Anything using pro-tier reasoning. Both routes into it collapse into one parameter. Cost and behaviour both move.

If one of those is yours and has no clear owner, look at it this month rather than in November.

Want someone to run this audit against your repositories and hand you the list? Effloow's Proof Studio does exactly this kind of claim-bound technical check, and our services page covers the write-up and migration documentation side.

When to act, and when to skip

Act now if: you have production traffic on any gpt-5, gpt-5-mini, gpt-5-nano, gpt-5-pro, or o3 name, dated or not; you run fine-tuned models on a 2024–2025 base; you use pro-tier reasoning; or you can't say from memory which model IDs live in your codebase.

Skip this if: you're already on the gpt-5.6 family (gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna), or on gpt-5.1 through gpt-5.5, none of which appear on either shutdown list as of this writing. Also skip if your only OpenAI usage is voice, realtime, or video. Those retire on separate schedules with their own dates and aren't covered here.

Don't treat a passing test suite as evidence. Everything on both lists still answers today. That's the trap. Nothing fails until the date, and then it all fails at once.

The honest limits of this check

Three things to hold against these results.

Model availability is scoped to an account. Our list of 126 models reflects one organization's tier and entitlements on one day. Yours will differ, which is exactly why the useful move is running the check yourself instead of citing ours.

Alias resolution is observed behaviour, not a written contract. OpenAI could repoint gpt-5 at a newer snapshot tomorrow without announcing it, and that would be a fix rather than a problem. It also means today's observation has a shelf life. Re-run it.

Error messages lie about causes. When we requested o3-pro-2025-06-10, the API returned a 404 saying the organization must be verified to use that model, saying nothing about deprecation. From the error text alone, "retired" and "you aren't entitled to this" look identical. Any audit script that probes models and parses error strings will mislabel some results.

We also didn't compare quality, latency, or cost between any old snapshot and its replacement. That comparison is unmeasured here, and we won't imply it.

What to do differently after reading this

Stop auditing for pinned date strings only. Search for the short names in the same pass: "gpt-5", "gpt-5-mini", "gpt-5-nano", "gpt-5-pro", "o3". Cover .env files, deployment configs, infrastructure-as-code, notebooks, and any prompt-management or routing layer. Model IDs sprawl across all of them and rarely sit in just one.

Then call the API once for each hit and read back the model field. That's the only answer reflecting reality rather than intent. Two minutes per service, and it turns "we think we're fine" into a fact.

Escalate instead of auto-fixing in two cases: fine-tuned models on retiring bases, and anything touching pro-tier reasoning. Neither one is a text substitution.

What Effloow added

OpenAI's deprecation page tells you which dated IDs end and when. It doesn't tell you what your undated alias currently resolves to, and that's where most of the exposure sits. We ran the resolution check against the live API and published the mapping, plus the token cost of the reasoning.mode: pro swap that the migration table implies but never prices. Complete commands, raw output, and failures are in the public lab note.

Related reading: our OpenAI Assistants API sunset port covers the same problem shape at the endpoint level, and the prompt tooling sunset migration scanner covers building the repository-scan side of this work. If billing behaviour under failure is your concern, see the spend limit 429 fail-closed audit.

Bottom Line

The short model name never protected you. It resolved to the same doomed snapshot as an explicit pin, minus the searchable string. Audit both this month, and read the model field back from a real request instead of trusting what your code says.

For your engineers

Everything below is method. Reproduce it before trusting it.

Environment. Python 3, standard library only (urllib.request, json). One standard OpenAI API account, not organization-verified for restricted models. Run date 2026-08-14.

Step 1: enumerate what the account can see.

req = urllib.request.Request(
    "https://api.openai.com/v1/models",
    headers={"Authorization": f"Bearer {key}"},
)
ids = sorted(m["id"] for m in json.load(urllib.request.urlopen(req))["data"])

Returned 126 IDs. Diff that set against both deprecation lists. gpt-4-1106-preview and o3-pro-2025-06-10 were already absent. Note that the bare string gpt-5.6 is not a valid ID; only gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna resolve.

Step 2: resolve aliases via the Responses API.

payload = {
    "model": "gpt-5",
    "input": "Reply with the single word: ok",
    "max_output_tokens": 16,
    "reasoning": {"effort": "low"},
}
# then read response["model"]

At max_output_tokens: 16 the reasoning models return status: "incomplete". Expected, and irrelevant here. The model field populates regardless, and it was the only field under test. Cost per probe is a few tokens.

Step 3: price the pro-mode parameter. Identical model (gpt-5.6-sol) and identical prompt, varying only the reasoning object between {"effort": "low"} and {"mode": "pro"}. Read usage.input_tokens. Results: 13 → 1,530 on the short prompt, 167 → 2,145 on the longer one. Two pairs, single account, single date. Treat it as a signal to measure your own workload, not as a published figure.

Step 4: error shape reference. A nonexistent ID (gpt-5-2025-08-08) returns HTTP 400 with code: "model_not_found". An entitlement failure (o3-pro-2025-06-10 on an unverified org) returns HTTP 404 with a verification message. Neither is a deprecation signal. If you build a probe-based scanner, treat 404-with-verification-text as "unknown" rather than "retired".

Primary sources.

• OpenAI model deprecations — both shutdown waves, ID lists, and replacement mappings (fetched 2026-08-14)
• GET https://api.openai.com/v1/models — live account model inventory
• POST https://api.openai.com/v1/responses — alias resolution and token accounting
• Effloow lab note — commands, raw results, failures, and limitations

Voice, realtime, and video model retirements run on separate schedules and are deliberately out of scope here.