GPT-4o 與 GPT-4.1 API 將於 2027 年 1 月 14 日退役：遷移檢查清單

OpenAI published a deprecation notice on October 14 with a date that is
already uncomfortably close: on January 14, 2027, GPT-4o, GPT-4o mini,
GPT-4.1 and GPT-4.1 mini leave the API. Not the chat app. The API that
your code, your cron jobs and your agents call. That is 92 days of
warning, against OpenAI's own policy of six months. I read the notice,
the pricing pages and four independent migration writeups, then wrote
down the 10 checks I would run on any production system before touching
a single model name.

The short answer

On January 14, 2027, five OpenAI snapshots stop answering: 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. The listed replacement is gpt-6-luna, which is dramatically cheaper on paper but is a reasoning model with different tool-calling behavior. Audit every model reference this week, test Luna on your own traffic, and finish the switch by mid-December so January is a monitoring month, not a firefight.

What is actually retiring

OpenAI's deprecations page is short and worth reproducing exactly, because paraphrasing model IDs is how migrations break:

Two lines from that page carry most of the weight. First: "Fine-tuned versions of these models follow the same shutdown schedule as their underlying base models." Your ft-gpt-4o custom model dies the same day. Second: the notice itself is the anomaly. OpenAI's own page sets a minimum notice of six months for generally available models, and this one gives 92 days. The policy carries an exception for safety or compliance retirements, but I found no statement from OpenAI tying this notice to that clause. Read it as it is: an unusually short window.

Check 1: one of the retiring snapshots dies today

Before touching the January deadline, check the one that is already here. A separate notice from April 22, 2026 retires an older wave of models on October 23, 2026. Today. That wave includes gpt-4o-2024-05-13 (the very first GPT-4o snapshot), gpt-4-turbo, gpt-3.5-turbo, gpt-4.1-nano, o1, o3-mini and o4-mini.

If your codebase pins any of these, something may already be failing while you read this. The recommended replacements for this wave are the GPT-5.6 family (gpt-5.6-terra, gpt-5.6-sol, gpt-5.6-luna), not Luna, so do not blend the two migration lists. And keep December 11 on your radar too: the o3-2025-04-16 snapshot retires then, separate from both waves.

The main app gets attention. The silent failures live in the auxiliary tooling: the code review bot configured a year ago, the changelog summarizer in CI, the script that labels support tickets. They keep working until the day they don't. Grep everything, not just the repo you are proud of.

Check 2: find every pinned reference

This is the boring check that catches the expensive bugs. Search your code, your infrastructure and your vendor configs for the retiring model IDs:

grep -rn "gpt-4o-2024-08-06\|gpt-4o-2024-11-20\|gpt-4o-mini-2024-07-18\|gpt-4\.1-2025-04-14\|gpt-4\.1-mini-2025-04-14" \
  --include="*.py" --include="*.ts" --include="*.js" --include="*.json" \
  --include="*.yaml" --include="*.yml" --include="*.env*" .

Do not stop at the app code. Check CI workflows, prompt files, agent definitions, Docker build args, Terraform, and any .env or secrets manager that stores a model name. Then check the tools you did not write: plugins, no-code automations and third-party integrations often hardcode a model ID at install time, and their vendors may or may not have migrated you. If your stack stores the model name in an environment variable, a single config change flips the whole system. If it does not, this migration is also the moment to start.

Check 3: do not forget the fine-tunes

I keep repeating this because teams keep missing it: fine-tuned versions follow the base model's shutdown schedule. A fine-tune on GPT-4o is not a separate asset with its own lifecycle; it is a lease that expires with the base model.

The uncomfortable part is the replacement story. The reported model pages list fine-tuning as "Not supported" on gpt-6-luna, which means a model swap is not a plan for fine-tune teams at all. You need a retraining target: either a model that supports fine-tuning, or a rewrite of the workload as a prompted pipeline on Luna with enough evals to prove the quality holds. Either way, start the eval work now, because retraining on a new base model needs its own data and its own timeline, and January is closer than it feels.

Check 4: Azure buyers get three extra months

If you call OpenAI models through Azure, the dates differ. Microsoft's retirement schedule (last updated September 23, 2026) lists April 14, 2027 for the gpt-4o and GPT-4.1 snapshots that OpenAI itself removes on January 14. The very first GPT-4o snapshot, gpt-4o-2024-05-13, retires on Azure on December 9, 2026.

Treat the April date as planning buffer, not an exemption. Being pinned to Azure buys you time to migrate carefully; it does not buy you immunity from the migration. If your deployment spans both direct OpenAI API calls and Azure endpoints, migrate to the direct-API date. The system is only as durable as its earliest deadline.

Check 5: understand the 92-day notice

OpenAI's normal minimum is six months for generally available models. The October 14 notice gives 92 days. That is a third shorter runway than its own policy, with no reason stated.

There is exactly one official escape hatch I could verify: OpenAI says that in some cases developers may be able to provision dedicated capacity for continued access after a model's shutdown date, arranged through the sales team. That is an enterprise conversation with enterprise pricing, not a migration plan. If you need it, start that conversation now, because sales cycles do not respect deprecation calendars.

The honest read of the short notice is that model retirements are becoming routine. OpenAI, Anthropic and Google all deprecate older generations on a couple of years' cycle. Any pipeline that hardcodes a single model ID has a built-in expiry date, and the professional response is not outrage. It is a model layer you can swap, which is what Check 9 is about.

Check 6: GPT-6 Luna is a reasoning model, not a drop-in swap

This is the trap the headline writers skip. Luna is dramatically cheaper per token, but it does not behave like GPT-4o or GPT-4.1, and the differences are exactly the kind that pass a smoke test and fail in production:

• It reasons by default. Luna's reasoning.effort defaults to medium, and reasoning tokens are billed as output tokens. The same request can produce far more output tokens on Luna than on GPT-4o, so per-token prices do not translate directly to per-request costs.
• Tool calls need the right API. Function calling through the Chat Completions API needs reasoning_effort set to none. Combining reasoning with tools requires the Responses API. If your agents call tools through Chat Completions, this is a code change, not a config flip.
• Parameters change. Enabling reasoning drops temperature, top_p and logprobs that GPT-4.1 supported. If your prompts rely on temperature tuning for variety or consistency, expect different behavior and retest.

Set reasoning_effort to none if you want the closest thing to 4o-style behavior and cost. My recommendation: only enable reasoning for workloads where you have measured that it improves the output. Reasoning is a cost you choose, not a default you accept.

Check 7: run the bill math before believing the headline

The headline number is real and it is misleading at the same time. Standard list prices per million tokens:

Against GPT-4o that is 25x cheaper on input and 20x on output. But a worked example from the cost analysis tells the fuller story: on a month of 200M input and 20M output tokens with reasoning off, Luna costs $30 against $42 for GPT-4o mini. The saving is real. But at the default medium reasoning effort, the saving evaporates once Luna's reasoning tokens pass about 24M a month, roughly 1.2x the visible output. One reported catch: once a prompt exceeds 272,000 input tokens, the input rate doubles and the output rate rises 50 percent for the whole request.

So do the math on your own traffic, with your own reasoning effort setting, not on the headline ratio. I ran through this exercise myself on my own API bills in my real cost of running an AI SaaS work, and the pattern holds every time: the headline price is the least important number in your bill.

Check 8: test the replacement on your own data

Every careful writeup agrees on this step, and they are right. A newer model formats answers differently, follows the same instructions differently and costs differently. Move a copy of real traffic, not a curated sample, and compare three things: output quality against your existing evals, output format stability (parsers downstream of the model are the first casualty of a swap), and cost at your actual volume.

If you have no evals, write a small one before the migration. Ten to twenty representative prompts with recorded expected outputs is enough to catch the big regressions. Shadow-run Luna beside the retiring model for a week and diff the outputs. The teams that get hurt by model retirements are never the ones that tested; they are the ones who treated the swap as a config change.

Check 9: pin the replacement so this does not happen again

The deeper lesson from this retirement is architectural. Pinning a dated snapshot does not avoid migration; it trades "whenever the alias is retargeted" for "the retirement date on the provider's schedule," which at least you can plan around. That is strictly better, and it is what made this checklist possible at all.

For the next cycle, build the swap point once:

1. Read the model name from an environment variable or config service, never hardcode it in application code.
2. Pin to dated snapshots in production so a provider-side alias change cannot surprise you mid-week.
3. Keep a per-workload mapping of model to API surface (Chat Completions vs Responses), so the next forced move is a table update, not an archaeology dig.

Model lifecycles in the API era are a couple of years at best. The teams that survive them calmly are the ones whose model choice is a row in a config file, not a string buried in twelve repos.

Check 10: the timeline I would follow

Deadlines work when they are earlier than the real one. Mine:

• This week: run Check 2 across every repo, config and vendor integration. Inventory fine-tunes (Check 3) and note which workloads call tools (Check 6).
• By mid-December: finish evals and shadow runs (Check 8), complete the bill math (Check 7), and switch production traffic. December is for migration; January is for monitoring.
• January: watch error rates and costs on the new model for two weeks. Keep the old code path behind a feature flag until you are confident, then delete it. Dead code referencing dead models is how the next retirement surprises you.

What I would actually do

If I were handed this on Monday morning, I would not start with Luna. I would start with the grep, because in my experience the inventory is always worse than the team believes: at least one model reference will be hiding in a place nobody remembers. Then I would split workloads by tool use. Anything that calls tools through Chat Completions either gets reasoning_effort: none on Luna or moves to the Responses API, and that decision is per workload, not per company. Fine-tune owners get the uncomfortable conversation early, because retraining has its own timeline and January does not negotiate. The price drop is genuinely good news, but I would treat it as a bonus discovered after the migration is proven, not as the reason for it.

Frequently asked questions

Which OpenAI models retire on January 14, 2027?

Five snapshots across four models: 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. The notice was posted on October 14, 2026, which is only 92 days of warning. Fine-tuned versions of these models follow the same shutdown date as their base model.

What should I migrate to instead of GPT-4o or GPT-4.1?

OpenAI's deprecations page lists gpt-6-luna as the recommended replacement for all five retiring snapshots. It costs $0.10 per million input tokens and $0.50 per million output tokens against $2.50 and $10 for GPT-4o, but it is a reasoning model with different tool-calling behavior, so it is not a drop-in swap.

Does my fine-tuned GPT-4o model keep working after January 14?

No. OpenAI states plainly that fine-tuned versions of these models follow the same shutdown schedule as their underlying base models. A fine-tune on GPT-4o dies the same day as GPT-4o, and gpt-6-luna does not support fine-tuning, so fine-tune teams need a retraining plan on a different model, not just a model swap.

Why is GPT-6 Luna not a simple drop-in replacement?

Luna is a reasoning model that defaults to medium reasoning effort, and reasoning tokens are billed as output tokens. Function calling through Chat Completions needs reasoning_effort set to none; combining tools with reasoning requires the Responses API; and turning reasoning on drops temperature, top_p and logprobs that GPT-4.1 supported.

Does Azure OpenAI retire GPT-4o on the same date?

No. Microsoft's retirement schedule, last updated September 23, 2026, lists April 14, 2027 for the gpt-4o and GPT-4.1 snapshots that OpenAI removes on January 14. Azure buys you three extra months of buffer, not an exemption. Plan to be migrated by January anyway.

What happens if I miss the January 14 deadline?

API requests to the retired model IDs start failing after that date, which means whatever still names them goes silent: chatbots, triage scripts, code review bots, summarizers. In some cases OpenAI says developers can provision dedicated capacity for continued access after shutdown through its sales team, but that is an enterprise escape hatch, not a plan.

The money angle

Retirement deadlines are consulting gold. Every team pinned to GPT-4o or GPT-4.1 needs the same three things between now and mid-December: an audit, an eval-driven migration, and a bill review. If you offer OpenAI migration work to clients, this is your outreach angle for the next six weeks, and it expires on January 14. The same playbook applies to every future retirement, so the first engagement builds you a reusable offer.

If your production system calls GPT-4o or GPT-4.1 and you want the audit and migration handled by someone who has done it before, reach out through the contact section on my homepage. I take on a small number of API migration and cost-optimization engagements each month.

Sources

• OpenAI, Deprecations - the October 14 and April 22 notices, fine-tuning schedule, dedicated capacity note
• Nothing Left to Tune - price table, fine-tuning status, reasoning effort levels
• GPT-4o and GPT-4.1 Retirement: Migration Cost to Luna - cost math, Azure dates, cached input pricing
• Built on GPT-4o? OpenAI Switches It Off on January 14, 2027 - audit-first timeline
• Pin the model id or use the alias - the October 23 wave table, snapshot pinning strategy
• Devshot, October 16, 2026 - tool-call behavior differences, long-context pricing threshold
• GPT-4o API Shutdown - the short-notice policy analysis, dedicated capacity
• What it means for AI code review - auxiliary tooling blind spots
• Model retirement and small-business automations - testing before switching

{/* MONETIZATION NOTE: swap the contact CTA for an affiliate placement if a relevant program (OpenAI partner, migration tooling) exists */}