OpenAI's Deprecation Calendar: Nov + Dec + Jan Shutdowns — What to Check Before Each

The October 23 shutdown got the headlines. Twelve model IDs, one deadline, a lot of us grepping at midnight.

But the calendar didn't stop on the 23rd — and the person who pointed that out wasn't me. In the comments on the Oct 23 piece, reader shuttlewright sketched the next three months from memory: the evals and prompts shutdown at the end of November, the GPT-4o batch on January 14, and an audit workflow smarter than the one I'd published. I checked every date below against OpenAI's own deprecations page (October 25) before writing a word of this. They were right — including about the workflow.

So this is the calendar shuttlewright outlined, verified, with the check to run before each date. If your stack touches OpenAI anywhere, at least one of these dates is yours.

The calendar, on one screen

Date	What shuts down
Oct 31	Evals go read-only — last chance to run or change them
Nov 30	Evals dashboard + API · v1/prompts and reusable prompt objects · Agent Builder
Dec 1	gpt-image-1-mini, gpt-image-1.5, chatgpt-image-latest
Dec 11	First-gen GPT-5 + o3: gpt-5, gpt-5-mini, gpt-5-nano, gpt-5-pro, o3, o3-pro
Jan 6	tts-1, tts-1-hd, gpt-4o-mini-tts · new fine-tuning job creation ends
Jan 14	The GPT-4o batch: gpt-4o snapshots, gpt-4o-mini, gpt-4.1, gpt-4.1 mini + their fine-tunes
Jan 20	Legacy realtime/audio batch: gpt-realtime, gpt-4o-realtime, gpt-audio, mini variants

Everything below is what breaks, and what to check before each date arrives.

Run this audit once, before any of the dates (shuttlewright's workflow)

My Oct 23 checklist said "grep your repos for the dead IDs." shuttlewright's version is better, and it's the one you should actually use:

1. Dashboard first, filtered by model. Open the OpenAI usage dashboard and filter by model. That gives you the list of IDs your organisation actually called in recent traffic — not the list the internet is worried about. Your real exposure is usually three or four IDs, not thirty.
2. Then grep — but only for the live dying IDs on your list. Intersect your dashboard list with the calendar above. Those are the only IDs worth searching for, and now the grep is small enough to do properly: app code, infra configs, env examples, CI variables, scheduled jobs.
3. Add the programmatic check so this stops being manual. OpenAI's deprecations page points out that GET /v1/models exposes a shutdown_date field per model. Poll it monthly, diff it, and a deprecation announcement becomes a calendar entry instead of a surprise. Ten lines of script, and this whole genre of article gets less necessary.

One warning carried over from Oct 23, because it's the mistake that keeps recurring: fine-tunes die with their base model. Every batch below takes its fine-tuned versions with it.

November: the platform features die (Oct 31 + Nov 30)

Oct 31 — evals go read-only. Six days from now. After the 31st you can look at your existing evals but not run or modify them. If your team has eval configurations or results worth keeping, export them this week, not next month.

Nov 30 — three shutdowns land on the same day:

• Evals dashboard and API shut down entirely. Whatever you use evals for in CI or release gating needs a new home. OpenAI's own deprecations page points to a Promptfoo migration guide — that's their suggested direction, and the read-only month of November is clearly the intended migration window.
• The v1/prompts API and reusable prompt objects shut down. If your code references stored prompt IDs, those calls start failing on Nov 30. OpenAI's migration advice is blunt: move the prompt content into your application code. This is content-moving work, not deep engineering — which is exactly why it gets left until it's an outage.
• Agent Builder shuts down. ChatKit stays. The deprecations page points Agent Builder users at the Agents SDK or ChatGPT Workspace Agents.

Check before Nov 30: grep for pmpt_ prompt IDs and any /v1/evals or /v1/prompts calls, and inventory anything built in Agent Builder. All three are findable in an afternoon — in November. In December they're archaeology.

December: the image models, then the first GPT-5s (Dec 1 + Dec 11)

Dec 1 — gpt-image-1-mini, gpt-image-1.5 (including the 2025-12-16 snapshot), and chatgpt-image-latest are removed. Replacement for all three: gpt-image-2.5-sunburst or gpt-image-2.5-flare. gpt-image-1 itself died in the Oct 23 batch; these are its siblings finishing the set. Same advice as October: image-model swaps change output style, so if users see your generated images, eyeball the new model's output before you commit the swap.

December 1 is apparently deadline season everywhere — it's also the day Gemini 4 Argon's API pricing doubles. Different vendor, same calendar problem.

Dec 11 — the first-generation GPT-5 family and o3 go. Announced back on June 11, which is precisely why it's dangerous: six-month-old news that everyone filed under "later."

Dying Dec 11	OpenAI's replacement
gpt-5 \	gpt-5-2025-08-07
gpt-5-mini \	gpt-5-mini-2025-08-07
gpt-5-nano \	gpt-5-nano-2025-08-07
gpt-5-pro \	gpt-5-pro-2025-10-06
o3 \	o3-2025-04-16
o3-pro \	o3-pro-2025-06-10

Note that the bare aliases are listed right alongside the snapshots — calling plain gpt-5 does not save you. And if you pinned the August 2025 snapshot for reproducibility (the responsible move at the time), you're on this list and may not know it.

Check before Dec 11: your dashboard-filtered list from the audit, intersected with the six IDs above. Swap, then replay real production prompts against the replacement and diff the outputs — a generation jump is not a drop-in, even when the parameter shapes line up.

January: voice first, then the big one (Jan 6, 14, 20)

Jan 6 — the text-to-speech models go: tts-1, tts-1-hd, and gpt-4o-mini-tts (both snapshots), all replaced by gpt-realtime-2.1-mini. TTS calls are the classic quiet dependency — narration features, accessibility read-aloud, IVR prompts — often set up once and never revisited. Also on Jan 6: creating new fine-tuning jobs closes for everyone, including active existing customers. Inference on existing fine-tunes continues until the base model dies, but if you were planning one more training run on an older base, December is your window.

Jan 14 — the GPT-4o batch. This is the big one, and the date shuttlewright flagged in October. Announced Oct 14:

Dying Jan 14	OpenAI's replacement
gpt-4o-2024-08-06, gpt-4o-2024-11-20	gpt-6-luna
gpt-4o-mini-2024-07-18	gpt-6-luna
gpt-4.1-2025-04-14	gpt-6-luna
gpt-4.1-mini-2025-04-14	gpt-6-luna

These are the snapshots a huge share of production code actually runs — 4o was the default for a long time, and "default for a long time" means it's embedded in places nobody has opened since. Fine-tuned versions of all four follow the same date. If you do one thing from this entire article in November, make it the dashboard audit with these four IDs highlighted.

Jan 20 — the legacy realtime/audio batch: gpt-realtime and its 2025-08-28 snapshot, gpt-4o-realtime, gpt-audio, gpt-4o-audio, gpt-realtime-mini, gpt-audio-mini, gpt-4o-mini-realtime, gpt-4o-mini-audio, and the March 2025 gpt-4o-mini-transcribe snapshot. Replacements are the gpt-realtime-2.1 and gpt-audio-1.5 families. Voice agents built in the 2025 realtime wave are the exposure here.

Check before January: treat Jan 6–20 as one window, not three surprises. TTS first (small, contained), the 4o swap as the main event, realtime last because it usually has the fewest call sites and the most behaviour to re-test.

What I'd actually do

This week: the dashboard-first audit. Twenty minutes, and every date above becomes either "not mine" or a ticket with a date on it.

November: the prompts/evals migration. It's content-moving, so I'd schedule it like content work — before the 30th, with the export done in October while evals are still writable.

Early December: image swap (with output eyeballing) and the GPT-5 snapshot swap (with prompt replay). I'd deliberately keep them a week apart — two behaviour changes in one deploy is how you end up unable to say which one broke the thing.

January: freeze the calendar, not the code. Jan 6, 14 and 20 are close enough together that I'd plan them as one migration arc with the 14th as the deadline that matters.

And the standing fix, same as I said in October: model IDs go in one config place, the /v1/models shutdown_date check goes in a monthly job, and a deprecation email gets treated like a CVE notice. This is the second calendar article I've written in a week — the other was Meta's crawler deadline — and I'd rather the genre died because everyone's inventory got boring, not because the shutdowns stopped. They won't.

So, honestly: which date on this calendar is yours? And did you know it before this list — or did a comment thread on the internet just save you a very bad morning?

No affiliate links in this one — it's a service post, not a buying guide. Every date and replacement above was verified against OpenAI's deprecations page on October 25, 2026; OpenAI can move dates, so re-check that page before scheduling around any of them. The calendar outline and the dashboard-first audit workflow came from reader **shuttlewright, in the comments on the Oct 23 piece — credit where it's due.

Comments

[Paul Lovelace]

@shuttlewright Ha, "the habit the calendar itself is trying to teach" — that's a better line than anything in the article, honestly. The monthly shutdown_date diff is the bit I'd actually want people to take away: announcements get buried, a diff doesn't. And you're right about Dec 1 and Jan 20 — the chat stack gets the attention and the dashboards, while the image and voice pipelines sit in some other service nobody owns until they 400. That's exactly how those two bite.

Posting this top-level, by the way — your comment isn't rendering on the article page for me, so I couldn't reply in the thread.

[Nzubechi Chukwu]

That’s a nice calendar and it’s good that the shuttlewright’s audit is covered too. A little note regarding the Evals rows though; when using the dashboard’s export, you get a JSONL file with the results of the run. That’s history and can’t be executed again, and OpenAI support has stated that not all types of evaluations can be exported to Promptfoo configuration. Evals API will be available until Nov 30 and it gets you everything: all evaluation data sources and graders, all runs and graded outputs. The safest thing for you to do this week would be to use the API and then create your own tests from scratch. Here’s the API route I used for that: dev.to/enzii/your-openai-evals-fre...

[Paul Lovelace]

That JSONL point is the one I'd missed — a history file you can't re-run isn't really a migration, it's just an archive. API before Nov 30 it is, then rebuild from scratch. Thanks for flagging the Promptfoo gap too, that's exactly the kind of thing that bites you a week later.

[Nzubechi Chukwu]

I’m glad I could help you out there, Paul. It was surprising that OpenAI's Promptfoo export has gaps, where the export looks like it works until you try it out. Thanks for maintaining the calendar.

[Paul Lovelace]

Yeah, that Promptfoo gap is the sneaky kind — looks like a clean export until you try to actually run it. Thanks for flagging it, and for the calendar kind words.

[Shuttlewright]

Thanks - and agreed on the API over the dashboard export. Whatever the exact cutoff date turns out to be, pulling everything through the API this week is the move that does not depend on it. One addition from having done similar migrations: save the raw API responses (graders, data sources, run configs) into version control next to the tests you recreate, not just into a scratch folder. When you rebuild the evals in your own harness, the grader definitions are the part you will diff against later, and a dated raw dump is the only reliable reference for what the original actually did.

[Paul Lovelace]

And yeah, the version-control bit — I'd have dumped it in a scratch folder and regretted it. A dated raw dump next to the rebuilt tests makes sense, the grader definitions are the part you'd actually diff later.

[Nzubechi Chukwu]

Good one, that. That highlighted a limitation of my tool: the API data from LLMShift gets converted into tests, but the actual response is discarded. Now, that limitation is fixed: --save-raw will save an archived copy of all API responses along with the tests. Thank you so much for the idea

[Paul Lovelace]

Ha, that's a quick turnaround — and --save-raw is exactly the version of that idea I'd actually use. A dated dump next to the rebuilt tests is the bit that saves you later, when you're diffing graders and can't remember what the original did.

[Shuttlewright]

"Announcements get buried, a diff doesn't" - and the diff catches one more thing worth naming: the retirement that was never announced at all. A model appearing in /v1/models with shutdown_date already set is a pre-announced death with no email and no article, and only the diff sees it. On the ownership point: "nobody owns it until it 400s" is an org problem wearing a tooling costume. The durable fix is an owner per pipeline - one named person for image, one for voice, one for chat - because a dashboard everyone checks is a dashboard nobody checks. The audit finds the exposure; the name next to it is what gets it fixed.

[Paul Lovelace]

The owner-per-pipeline line is the one I'm stealing this time. A dashboard everyone checks is a dashboard nobody checks — yeah, that's painfully true in my experience. The audit tells you where the exposure is, but without a name next to it nothing actually moves until the 400s start. And the unannounced-retirement angle is the scariest version of this, honestly — a shutdown_date sitting there quietly with no email and no article.

[Shuttlewright]

Correction to my wording above: OpenAI says it emails customers actively using a retiring model and documents deprecations on its deprecations page. shutdown_date is also available through the model APIs. A monthly diff is another way to track changes; it is not the only source, and I have not verified a retirement that went unannounced.

[Paul Lovelace]

Appreciate the correction — and you're right to flag it. I ran with the 'never announced' framing a bit too eagerly in my head too, and the honest version is what you wrote: the diff is another signal, not the only one. That's a better, more careful claim, and it's the one people should actually act on.