GPT-4o 退役日期、替代型號與遷移指南

GPT-4o leaves the OpenAI API on 14 January 2027. As of 22 October 2026, that date covers the listed GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini snapshots and the fine-tunes built on them, and OpenAI names gpt-6-luna as the replacement. Azure retires most of the same versions on 14 April 2027. ChatGPT dropped GPT-4o in February 2026, which did not touch the API.

Changing the model string takes a minute, but proving the product still behaves takes the rest of the migration, because Luna handles tool calls, reasoning and sampling differently from the model your evals were scored on. This guide gives the dates, then the order of checks we recommend for this swap and every one after it.

When is GPT-4o deprecated on the OpenAI API, Azure and ChatGPT?

Plan against the earliest date that touches any id you call. Each platform runs its own schedule, and a team that reads one page and assumes it covers the others plans for the wrong day.

Where the model is called	Shutdown date	Listed replacement
OpenAI API	14 January 2027 for `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`, and fine-tunes on them	`gpt-6-luna`
OpenAI API, earlier batch	23 October 2026 for `gpt-4o-2024-05-13` and `gpt-4.1-nano`, including its fine-tune	`gpt-5.6-sol` for the GPT-4o snapshot, `gpt-5.6-luna` for nano
Azure OpenAI	9 December 2026 for `gpt-4o` 2024-05-13. 14 April 2027 for `gpt-4o` 2024-08-06 and 2024-11-20, `gpt-4o-mini`, and all three GPT-4.1 sizes	`gpt-5.6-sol` for 2024-05-13, `gpt-5.1` for the later GPT-4o versions, none listed for GPT-4.1 or `gpt-4o-mini`
Azure OpenAI, fine-tuned deployments	1 October 2027 for GPT-4o and GPT-4o mini fine-tunes, 14 October 2027 for GPT-4.1 fine-tunes	Training ends earlier, no earlier than April 2027 for existing customers
ChatGPT	Retired 13 February 2026	Not an API change

Dates are as listed on OpenAI's deprecations page and Microsoft's retirement schedule on 22 October 2026. Any call still pinned to the 23 October batch should already be on its replacement, scored on live traffic from the first day.

Size your retest window to three months, not six. OpenAI's policy promises at least six months' notice for a generally available model, with less allowed for a specialized variant or for safety and compliance reasons. The GPT-4 series notice went out on 14 October 2026 for a 14 January 2027 shutdown, three months, so a plan that assumed six has already lost half its time.

On Azure, set versionUpgradeOption deliberately on every deployment. Standard, Data Zone Standard and Global Standard deployments are upgraded automatically at retirement, so a gpt-4o 2024-05-13 deployment becomes gpt-5.6-sol on 9 December 2026 with no code change. NoAutoUpgrade makes the deployment stop working at retirement instead. Provisioned deployments, which reserve fixed capacity, are never upgraded and have to be moved by hand. Score an automatic upgrade exactly as you would score a change you chose.

Why does a passing eval on GPT-4o not carry over to the replacement?

Treat the replacement as a new system and score it from the start, even when the prompt is identical. The agent can pick a different tool or fill a field with a different value. A tool schema can stay valid while the arguments change shape, and a structured-output schema can still parse while one field now means something else. One good completion on Luna shows none of that.

We design for this before any migration is planned. The trademark drafting system, in production with a client, logs the base model and the fine-tuned model on the same inputs against a 0 to 10 legal-integrity harness on six axes, and every draft passes that harness before an attorney sees it. A regression from a model change appears as a score movement, before an attorney reads the draft.

Our own sales roleplay coach takes the other half of the idea. Its score comes from a versioned rubric with weighted dimensions and behavioural markers, and the model only writes the qualitative read. Raw model scores drift between sessions, conversation lengths and personas. If the model also set the number, an upgrade would move every historical comparison, and nobody could tell a better rep from a different model.

Survey data points the same way: in VentureBeat's September 2026 survey of 109 opt-in respondents, 59 percent of the companies that replaced a model in a production app saw performance drop and reworked the app or went back to the original. Read it as a reason to score your own cases, not as a rate to plan around.

How do you run LLM regression testing before the model id changes?

Run the same eval cases on the current model and the replacement, each case several times, and only then move traffic in stages. The order we recommend is the same whatever the vendor, and each row below names what to record and what fails if the step is skipped.

Step	What to record	What fails if it is skipped
Inventory	Every model id in code, config and stored jobs, including dated snapshots, fine-tune ids and Azure deployment names	A forgotten snapshot stops answering on the shutdown date while the tests stay green
Pin	The replacement id, written into the eval report beside the id it replaces	An alias that moves later is a second change nobody scored
Same cases	The existing eval set, run on the current model and on the replacement	A score with no pair cannot show a regression
Repeats	A pass rate where wording may vary, and a pass on every repeat for a safety case	One green run hides a completion that will not come back
Contracts	Tool name, arguments and the structured-output schema, checked on their own	The prose still reads well while the integration stops parsing
Shadow	The new id run on live inputs, scored, with no action taken	The canary becomes the first time the live mix of requests appears
Canary	A slice of traffic, with the old id still callable	A full cutover has no rollback once config has forgotten the old id
Cost	Tokens, reasoning tokens and cache writes, on your own traces	A lower token price on a longer trace can still cost more
Retire	The old id removed from the inventory once the canary holds	The next person to read the config puts back an id that is about to stop answering

OpenAI's own migration note has four steps: record a baseline of quality, latency and cost, evaluate Luna starting at reasoning effort none, tune and retest, then send a limited share of production traffic. All four sit inside this table, so add the two rows it leaves out. A baseline that stores one completion per case cannot give you a pass rate, and a prose score cannot show that a tool call changed shape.

Score each case more than once, because a hosted model does not return the same answer twice even at temperature 0. Why LLM temperature 0 is not deterministic explains why a safety case has to pass on every repeat while a quality case ships on its pass rate. Take the cases from failures your team has already read, as our guide to LLM evaluation sets out, rather than writing new ones for the migration.

Move the eval set itself out of OpenAI's platform if it lives there. Existing evals on the Evals dashboard become read-only on 31 October 2026, and the Evals API, reusable prompt objects and the v1/prompts API shut down on 30 November 2026. Keep prompts and cases in your own repository, where the next migration can rerun them.

Keep the old id callable until the canary's scores hold, or until the shutdown date removes the choice. Deleting it from config on the day the evals pass leaves no way back if the next day's traffic is a different mix from the one you scored.

What does GPT-6 Luna change in a GPT-4o request?

Start the migration at reasoning effort none, on the endpoint you already use. It keeps the request closest to the old one, and on Chat Completions it is the only setting where tools still work. Then test higher settings against quality, latency and cost.

Reasoning effort on Luna runs from none through low, medium, high, xhigh and max, and the default is medium. A request that sends no setting therefore starts reasoning, which the GPT-4o call never did, and reasoning tokens bill as output.

Tool calls move endpoint once reasoning is on. Luna accepts function calling on v1/chat/completions only at reasoning effort none, and reasoning combined with tools goes through the Responses API. GPT-6 Astra and GPT-6.1 Sol need Responses for any tool call. Chat Completions has no shutdown date, but plan the move to Responses now for any route that will need reasoning and tools together.

Sampling settings go too: at any reasoning effort other than none, the request has to drop temperature, top_p and top_logprobs, plus logprobs on Chat Completions. A prompt that relied on a low temperature to hold its format loses that control, so the format can move with nothing on the request to explain it. Check the structured-output contract on its own at every reasoning level you test.

Compare total cost on your own traces, not the price per token. As of 22 October 2026 Luna lists $0.10 per million input tokens and $0.50 per million output, with cached input at $0.01 and cache writes at $0.125. A prompt over 272,000 input tokens is billed at twice the input and cache rates and 1.5 times the output rate for the whole request. The context window is 1,050,000 tokens, so a retrieval prompt that sat under GPT-4o's limit can now cross that price step with no change to the chunker. What a production AI agent costs works through how a longer trace shows up on the bill.

What happens to GPT-4o fine-tunes?

Work out what each fine-tune is holding before 6 January 2027, because the replacement OpenAI names cannot be fine-tuned. On the OpenAI API, fine-tunes on the January bases shut down with the base model on 14 January 2027, and from 6 January existing customers can no longer create fine-tuning jobs. As of 22 October 2026 the GPT-6 Luna model page lists the fine-tuning endpoint as not supported.

Do not start a fresh job on a GPT-4o base before the cutoff, because a model trained in late December is one you have to leave again in January. Use the eight days between 6 and 14 January as an overlap, with the replacement scored beside the fine-tune that still answers.

Sort each behaviour the tune carries by where it can live next. On the trademark system, fine-tuning carries the reasoning patterns, section boundaries and tone of an attorney's opinion, and it does not handle citation integrity. Citations come from retrieval over an approved index of case law, statutes and registry data, and validators check the five-section structure. A change of base model there would mean retraining tone and structure only, because the citations never lived in the weights.

RAG vs fine-tuning vs agentic search is the test for each behaviour. A tune that was standing in for examples can often be replaced by examples in the prompt. A behaviour that has to outlive this base needs a base you can still train and serve. An open-weight model, one whose weights you can download and host, is that path only after the same eval set passes on it.

Where should rules live so they survive a model swap?

Put sums, permissions and thresholds in code, not in the prompt or the weights. On our insurance voice agent, a required disclosure is a condition in the tool contract, so the question "can this payment run without the disclosure?" has the answer no whatever model sits behind it. A rule enforced in code carries across a migration untouched. A rule written into the prompt has to be retested on every model you try.

Keep the model id behind an interface the application owns, so a swap edits one place and no business logic. Our desktop chief-of-staff agent calls the model as a reasoning service and keeps credentials, the tool registry and execution on the user's machine. A second provider belongs behind the same interface as a tested option, not as an extra hop every request depends on, because every vendor in one flow has to be up for that flow to run.

Model routing can still send an easy case to a smaller model. Retune the threshold whenever either model changes, because a route left on the old threshold changes which model acts with no alert, and the regression gets blamed on the wrong file. TypeSafe's Jev, a typed decision model built for routing and other bounded decisions, keeps that choice outside the generative model; how to introduce Jev into agentic workflows covers where it fits.

How do you see the next OpenAI model deprecation in time?

Make the next shutdown date fail a check while the id still answers, instead of arriving as an email. The 14 January date is one row on a page that already lists later ones, including GPT-5.1, GPT-5.3-Codex and GPT-5.4 nano on 1 April 2027.

On the OpenAI API, call GET /v1/models and read each model's optional shutdown_date, which the retrieve-a-model endpoint returns as well.

On Azure, read lifecycleStatus and deprecation.inference from the Models API, and mind the naming. A model the docs call deprecated, still serving existing customers, shows in the API as Deprecating. The API value Deprecated means the model is already retired and every call returns 410 Gone. Alert on Deprecating, because a check that waits for Deprecated fires after the outage.

Run that read on a schedule against the ids in your inventory, and fail the check when a date falls inside your retest window, which the GPT-4 notice suggests should be three months. Send the failure as a pull request or a page to the person who owns the model, while there is still time to run the table above.

Common questions

When is GPT-4o deprecated on the OpenAI API?

As of 22 October 2026, OpenAI's deprecations page shuts down 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 on 14 January 2027, with fine-tunes on those bases on the same day. The older gpt-4o-2024-05-13 snapshot and gpt-4.1-nano shut down on 23 October 2026. New fine-tuning jobs end on 6 January 2027.

What replaces GPT-4o?

On the OpenAI API, gpt-6-luna replaces the January 2027 GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini snapshots, and gpt-5.6-sol replaces the older gpt-4o-2024-05-13. Azure lists gpt-5.6-sol for 2024-05-13 and gpt-5.1 for the later GPT-4o versions, and names no replacement for GPT-4.1 or gpt-4o-mini. Score the replacement on your own cases before you move traffic.

What happens to GPT-4o fine-tuned models?

On the OpenAI API they shut down with their base model, on 14 January 2027 for the listed snapshots, and existing customers cannot create new fine-tuning jobs from 6 January 2027. GPT-6 Luna does not support fine-tuning. On Azure, GPT-4o and GPT-4o mini fine-tuned deployments run until 1 October 2027 and GPT-4.1 fine-tunes until 14 October 2027.

Are the Azure OpenAI retirement dates the same?

No. Microsoft's schedule, as of 22 October 2026, retires gpt-4o 2024-05-13 on 9 December 2026 and the later GPT-4o versions, gpt-4o-mini and all three GPT-4.1 sizes on 14 April 2027. Standard deployments are upgraded to the listed replacement automatically at retirement unless versionUpgradeOption says otherwise, and provisioned deployments are not upgraded at all.

Is GPT-4o still in ChatGPT?

No. OpenAI retired GPT-4o, GPT-4.1, GPT-4.1 mini and o4-mini from ChatGPT on 13 February 2026, and said at the time that nothing changed in the API. The ChatGPT date and the API date are separate decisions, so a team calling the API should plan against the deprecations page.

How do you test an LLM before switching models?

Run the same eval cases on the current model and the replacement, several times each, and check tool-call arguments and structured-output schemas on their own. Then run the new model in shadow on live inputs, send it a canary slice of traffic, and keep the old id callable until the canary's scores hold. A single green run on the new model is one sample.

Can Chat Completions still call tools on GPT-6 Luna?

Only at reasoning effort none. Reasoning together with tool calls uses the Responses API, and GPT-6 Astra and GPT-6.1 Sol need Responses for any tool call. At any other reasoning effort, temperature, top_p, top_logprobs and logprobs have to be removed from the request. OpenAI suggests starting most GPT-4.x workloads at none.

How do you find out when an OpenAI model will be deprecated?

Call GET /v1/models and read shutdown_date on each id you use. It is a year-month-day string once a date is announced and null before that. On Azure, read lifecycleStatus and deprecation.inference from the Models API, where Deprecating means a date is set and Deprecated means already retired. Fail a scheduled check while the id still answers.