Your GPT-4o path ends in January

January 14 is not a soft reminder

If your production agents or apps still pin GPT-4o, GPT-4o mini, GPT-4.1, or GPT-4.1 mini, put January 14, 2027 on the wall. On October 14, 2026, OpenAI updated its API deprecations page and named those four GPT-4 series snapshots for removal from the API that day. The recommended replacement for all four is gpt-6-luna. Fine-tuned versions of those bases follow the same shutdown.

This is not a ChatGPT nostalgia story, and it is not a consumer petition. It is a buying and operating decision for anyone whose checkout helpers, support agents, catalog tools, or internal copilots still call those model IDs. When the date lands, those calls stop working. A friendly alias will not save a hard-coded snapshot. If you sell or run software that leans on these models, the question is not whether the notice is interesting. The question is which of your paths still name the retiring IDs, who owns the cutover, and whether your eval fixtures already cover tool calls and structured outputs on the replacement.

What actually shuts down

OpenAI's October 14, 2026 notice is specific. The snapshots leaving the API on January 14, 2027 are:

• GPT-4o: gpt-4o-2024-08-06 and gpt-4o-2024-11-20
• GPT-4o mini: gpt-4o-mini-2024-07-18
• GPT-4.1: gpt-4.1-2025-04-14
• GPT-4.1 mini: gpt-4.1-mini-2025-04-14

Every row points at the same replacement: gpt-6-luna. Fine-tunes built on those bases die with them. That last line is the one teams miss when they treat a fine-tune as a permanent asset instead of a lease on a base model.

OpenAI's own notice policy on the same page says generally available models normally get at least six months before retirement. This notice runs about three months from announcement to shutdown. Treat that as a calendar fact, not a negotiation. Plan the migration for the date on the table, not for the longer window you might have expected from the policy paragraph above it. Dedicated capacity after shutdown is mentioned on the same page as something to explore with sales; do not assume you have it unless that conversation is already done and written into the runbook next to the pin.

Inventory every pin before you rewrite anything

Start with a list, not a prompt rewrite. Search your repos, config stores, secret managers, deployment manifests, and agent harnesses for the four snapshot strings above, plus any aliases that still resolve to them. Include staging, shadow traffic, eval jobs, batch backfills, and that one weekend experiment that somehow made it into a cron.

For each hit, record four things:

1. Who owns the call — product, ops, or a contractor who left last quarter.
2. What the call does — tool use, structured output, plain chat, image in, function routing.
3. Whether a fine-tune sits underneath — if yes, that path ends on the same day; budget time to retrain or to drop the fine-tune and re-eval prompts on gpt-6-luna.
4. What fails if the model vanishes tomorrow — a degraded reply is one kind of failure; a blocked order, a stuck ticket, or a silent tool loop is another.

Group the list by blast radius. A read-only summarizer is not the same problem as an agent that writes to inventory or charges a card. If you cannot name an owner for a pin, it is already a production risk. Put it on the migration board with a date and a name before anyone debates temperature settings or system-prompt wording.

Regression on gpt-6-luna before cutover

Do not flip the model string in production and hope. Stand up a parallel path that sends the same fixtures to gpt-6-luna and compare what matters for your product:

• Tool-call shape and argument fidelity against your live tools
• Structured outputs and schema adherence
• Refusal and escalation behavior on the cases your agents must not invent
• Latency and error rates under the traffic pattern you actually run

Keep the old model as the control until the new path clears your gate. If a fine-tune carried most of the quality, treat that as a rebuild: same fixtures, new base, new scores. A green chat demo in a notebook is not a gate. A fixed fixture pack with pass/fail on tool calls and schemas is.

When something regresses, decide in writing whether you fix the prompt, change the tools, accept a narrower job for that agent, or pursue dedicated capacity only if OpenAI's post-shutdown path still applies to you. Write the decision next to the pin, including who may flip traffic and who may roll back. Do not leave it to January 13, when every team that waited is filing the same ticket and your on-call is learning the model ID for the first time.

Watch shutdown_date; do not wait for the outage

OpenAI documents an optional shutdown_date field on models returned from GET /v1/models (and on retrieve-model). When present, it is a YYYY-MM-DD string, or null if no shutdown is announced. Wire a small check into whatever already lists your models for cost or routing. Alert when a model your production pins still call gains a shutdown date, or when that date moves.

That monitor is cheaper than discovering the cutover in an error-budget burn. Pair it with a calendar hold for mid-December at latest: inventory done, fixtures green on gpt-6-luna, fine-tunes decided, owners named, rollback path written. January 14 is the last day those four snapshots answer, not the day you start looking. If your org still has pinned traffic on those IDs in the first week of January, you are already late—you are just not in production pain yet. The monitor and the hold exist so January is a confirmation day, not a discovery day.

Put this into practice

This week, export every model ID your apps and agents still call. Highlight the four GPT-4 series snapshots above. Open a migration ticket per pin with an owner, a blast-radius note, and a gpt-6-luna regression date before December. If a fine-tune is on the list, schedule the rebuild or the retirement now, on the same board as the base cutover.

If the work is tangled across several agents and environments, that is ordinary AI applications and agents delivery: inventory, eval gates, and a cutover you can reverse. Web apps that embed the same calls belong in the same pass, not a separate surprise in January. If you want a second pair of eyes on the pin list, tell us which models still answer in production.

Related work: Spin:Market.