OpenAI's October retirement timetable: is your vibe project still calling models that shut down in January and April 2027?

One timetable, two deadlines

OpenAI published two model retirement timetables in October 2026. The first, dated October 1, retires gpt-5.1, gpt-5.3-codex, and gpt-5.4-nano from the API on April 1, 2027, with what OpenAI calls six months' notice; on the same day, tts-1, tts-1-hd, and two gpt-4o-mini-tts snapshots were scheduled to shut down on January 6, 2027, with at least three months' notice, all pointing to gpt-realtime-2.1-mini. The second, dated October 14, retires specified GPT-4o, GPT-4o mini, GPT-4.1, and GPT-4.1 mini snapshots on January 14, 2027, all pointing to gpt-6-luna. Two batches shut down in January 2027, another in April. For a vibe project, that is not distant industry news: any model ID hard-coded in your config, prompts, plugin settings, or a template you copied may be on this list.

The most common misreading needs correcting first: "deprecated" does not mean "already unusable." On OpenAI's own definitions, deprecation is the start of the retirement process; shutdown is the day access ends. An October 1 notice means your calls still work today, but January 6 and April 1, 2027 are hard cutoffs — on those days calls fail outright, they do not get slower or gracefully downgrade. Treating "still works" as "nothing to do" is the classic mistake with this kind of announcement.

Check line by line: which entry catches your project

Batch one, shutting down January 6, 2027, is the speech line: tts-1, tts-1-hd, gpt-4o-mini-tts-2025-03-20, and gpt-4o-mini-tts-2025-12-15, all replaced by gpt-realtime-2.1-mini. If you build narration, read-aloud, or voice-assistant vibe projects, check these voice IDs first — they hide in config files you rarely open. Batch two, January 14, 2027, is the GPT-4 series snapshots: 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, all replaced by gpt-6-luna; fine-tuned versions follow the same schedule as their base models, so a fine-tuned project cannot be fixed by renaming the base model alone. Batch three, April 1, 2027: gpt-5.1 (including snapshot gpt-5.1-2025-11-13) and gpt-5.3-codex point to gpt-6-sol, and gpt-5.4-nano (including snapshot gpt-5.4-nano-2026-03-17) points to gpt-6-luna.

There is a trap specific to vibe coding here: many solo projects do not call the OpenAI API directly. They go through a wrapper, plugin, gateway, or someone else's template, so the model ID may live not in your code but in a dashboard setting, an environment variable on your hosting platform, or a third-party tool's model picker. Do not rely on memory. Grep three places: model ID strings in your repository, environment variables on your deployment platform, and the model settings of every third-party tool you actually use. OpenAI also offers a programmatic check: the model list endpoint exposes an optional shutdown_date field for each model — wiring that into your health check beats manually re-reading announcements.

Renaming is not migrating: three places it actually breaks

First, the default reasoning effort changes. According to independent analysis of this retirement, gpt-5.1 and gpt-5.4-nano default to no reasoning (effort none), while their replacements gpt-6-sol and gpt-6-luna default to medium. Swap only the model ID and the same request suddenly starts producing reasoning tokens — billed as output, adding latency and changing output style. For a vibe project that means: after switching, re-run your representative use cases and compare output quality, latency, and token usage, not just whether the API returns 200.

Second, the price direction is inconsistent. On the same analysis, moving gpt-5.1 to gpt-6-sol raises input price, moving gpt-5.3-codex to gpt-6-sol cuts output price by roughly 30 percent, and moving gpt-5.4-nano to gpt-6-luna gets cheaper; the GPT-4o series moving to gpt-6-luna shows a much larger input-price drop. No single sentence like "the new models are cheaper" covers this migration. You have to run the numbers on your own input-output mix and cache ratio — and for agent loops heavy on caching, cache read and write prices may move the total more than input price does.

Third, a "recommended replacement" is a vendor recommendation, not an equivalence guarantee. OpenAI's deprecations page is explicit: the notice period exists so developers can "evaluate recommended replacement models, test application behavior, and complete migrations." Evaluation and testing are your job. GPT-4o was positioned as a general flagship; gpt-6-luna is positioned as the most efficient model "for focused, high-volume tasks." Different positioning language is itself a signal: anywhere you leaned on GPT-4o's general abilities — open-ended writing, hard reasoning, long-context understanding — needs item-by-item regression, not a default pass.

Why OpenAI can shut down two batches within three months

My read: this is not a one-off cleanup but a pipeline that has been running most of the year. The same deprecations page shows GPT-5 and o3 snapshots announced June 11, 2026 for shutdown December 11, 2026; transcription models announced August 26 for February 26, 2027; and gpt-5.4-cyber announced September 11 for October 1 — only about 20 days, because safety or compliance reasons allow a faster timeline. October's two notices are simply the latest stops on that pipeline. In other words, model retirement at OpenAI has gone from "rare event" to "routine operations": your project should assume a notice like this arrives roughly every six months, not treat each one as a surprise emergency.

One more contrast worth noting: OpenAI promises at least six months' notice for generally available models, at least three months for specialized variants, and possibly as little as two weeks for preview models. The October 1 models sit exactly on the six-month line; the October 14 GPT-4 series got about three months, under a different timeline. When reading an announcement, do not just count the months — check which tier it falls in, because the tier decides how little time you might get next time. For a vibe project usually maintained by one person with no dedicated ops, the practical move is to put "model retirement" into your own release checklist rather than depending on vendor email — OpenAI says it emails customers actively using a model, but if you call through a gateway or wrapper, that email may never reach you.

A migration checklist you can finish this week

Step one, within 48 hours, inventory: list every OpenAI model ID your project calls directly or indirectly, with its shutdown date and recommended replacement; mark anything uncertain as "to confirm" rather than guessing. Step two, work backwards from the deadlines: the January 6, 2027 speech line goes first because it is nearest and because a voice feature failing is instantly visible to users; the January 14 GPT-4 series next; the April 1 GPT-5 series last, but tested before the end of 2026, not left to March 2027. Step three, regress each replacement separately: same prompts, same test cases, comparing output, latency, token counts, and cost, and checking whether the default reasoning effort needs to be explicitly set back to none. Step four, wire the shutdown_date check into your monitoring or health check, so the next vendor announcement triggers your own alert instead of a user bug report. Step five, handle fine-tuned projects as a separate track: confirm whether the fine-tune follows the base model's shutdown date, and prepare a re-fine-tune or base-model-plus-prompt plan in advance.

One blunt closing thought for solo builders: a model ID hard-coded in your code is, in effect, outsourcing your product's fate to a timetable you do not control. A vibe project's real moat was never "which model it uses" — it is "how many places you must change, and how many test rounds you must run, when the model changes." After this retirement wave, it is worth pulling model IDs into one central config behind a thin abstraction, so that next time a timetable arrives, you change one config and run one test round instead of grepping a whole repository at midnight.