GPT-4o and GPT-4.1 API Deprecation: Migrate to GPT-6 Luna
A practical compatibility, testing and cutover plan before January 14, 2027
OpenAI announced the deprecation on October 14, 2026. The affected GPT-4o and GPT-4.1 API models are scheduled to be removed on January 14, 2027. OpenAI names gpt-6-luna as the recommended replacement for every model in this notice.
The safe response is not a blind model-string replacement. GPT-6 Luna is a reasoning-capable model with different request settings, tool-calling rules, prompt-cache behavior and fine-tuning support. Treat the next three months as a migration window: inventory exact model IDs, build a representative evaluation set, update the API path where necessary, run a shadow comparison and cut over with rollback controls.
Fact versus recommendation: the affected IDs, notification date, shutdown date and recommended replacement come from OpenAI's deprecations page. The staged workflow and test thresholds below are Rubic8's practical recommendations, not an OpenAI requirement or an independent performance benchmark.
Which GPT-4 Models Are Being Removed?
OpenAI's October 14 notice covers four base-model lines and their listed snapshots:
| Deprecated model | Listed snapshot | Shutdown date | Recommended replacement |
|---|---|---|---|
| GPT-4o | gpt-4o-2024-08-06, gpt-4o-2024-11-20 |
January 14, 2027 | gpt-6-luna |
| GPT-4o mini | gpt-4o-mini-2024-07-18 |
January 14, 2027 | gpt-6-luna |
| GPT-4.1 | gpt-4.1-2025-04-14 |
January 14, 2027 | gpt-6-luna |
| GPT-4.1 mini | gpt-4.1-mini-2025-04-14 |
January 14, 2027 | gpt-6-luna |
Fine-tuned versions follow the same shutdown schedule as their underlying base model. This matters because GPT-6 Luna's current model page says fine-tuning is not supported. A team with a fine-tuned GPT-4o or GPT-4.1 deployment therefore needs more than an endpoint swap: it must reproduce the required behavior through prompting, retrieval, tools or another validated model path.
Do not extend this notice to every product whose name contains “GPT-4o.” The table does not say that GPT-4o transcription, text-to-speech or Realtime models share this January 14 deadline. Audit exact IDs rather than matching a name fragment and assuming the entire family is covered.
Why OpenAI Recommends GPT-6 Luna
OpenAI describes GPT-6 Luna as its most efficient model for focused, high-volume tasks. The current GPT-6 Luna model page lists text and image input, text output, streaming, function calling, Structured Outputs and built-in tools through the Responses API. Its standard short-context text prices are $0.10 per million input tokens, $0.01 per million cached input tokens, $0.125 per million cache-write tokens and $0.50 per million output tokens.
The model also lists a 1,050,000-token context window, a 128,000-token maximum output and a May 18, 2026 knowledge cutoff. Those are published specifications, not evidence that Luna will match an older model on your application. A newer cutoff, larger output allowance or lower price does not guarantee equal classification accuracy, tool selection or tone.
If you are choosing between members of the current family, Rubic8's GPT-6 Sol vs Luna guide explains how to compare completed-task cost rather than token price alone. OpenAI specifically recommends Luna for this deprecation, so start there. Escalate to a stronger candidate only when a representative evaluation shows that Luna misses an important requirement.
GPT-4o, GPT-4.1 and GPT-6 Luna: Current Specs and Prices
The comparison below uses the current OpenAI model comparison checked on October 14, 2026. Prices are standard text-token rates per one million tokens. Tool calls, regional processing, Batch/Flex/Fast modes and long-context pricing can change the final bill.
| Model | Input | Cached input | Output | Context | Max output |
|---|---|---|---|---|---|
| GPT-4o | $2.50 | $1.25 | $10.00 | 128,000 | 16,384 |
| GPT-4o mini | $0.15 | $0.075 | $0.60 | 128,000 | 16,384 |
| GPT-4.1 | $2.00 | $0.50 | $8.00 | 1,047,576 | 32,768 |
| GPT-4.1 mini | $0.40 | $0.10 | $1.60 | 1,047,576 | 32,768 |
| GPT-6 Luna | $0.10 | $0.01 | $0.50 | 1,050,000 | 128,000 |
GPT-6 Luna also has a separate cache-write charge, currently $0.125 per million short-context tokens. Earlier GPT-4 models do not use the same cache-write accounting. Do not estimate a migration by copying the old cached-input formula into a new spreadsheet.
A transparent cost example
Assume one request uses 10,000 uncached input tokens and produces 2,000 billable output tokens. Exclude cache writes, tool calls, regional premiums and retries. Under those fixed assumptions:
- GPT-4o: (10,000 × $2.50 + 2,000 × $10.00) / 1,000,000 = $0.045
- GPT-4.1: (10,000 × $2.00 + 2,000 × $8.00) / 1,000,000 = $0.036
- GPT-6 Luna: (10,000 × $0.10 + 2,000 × $0.50) / 1,000,000 = $0.002
That makes Luna 95.6% cheaper than GPT-4o and 94.4% cheaper than GPT-4.1 in this arithmetic example. It is a price calculation, not a benchmark. Reasoning tokens are billed as output, token usage can differ by model, and a failed task or retry can erase part of the apparent saving.
Migration Changes That Can Break an Existing Integration
1. Reasoning settings are now part of the request
GPT-6 Luna supports none, low, medium, high, xhigh and max reasoning effort. OpenAI lists medium as the default. A migration that omits the setting may therefore behave differently from a non-reasoning GPT-4.1 request.
For a first compatibility test, explicitly try reasoning: { effort: "none" } for bounded transformations where you want behavior closest to a direct model call. Then compare low or medium when the task benefits from more reasoning. This is a test strategy, not a promise that none reproduces GPT-4 behavior.
2. Tool calling should move to the Responses API
OpenAI says to use the Responses API for built-in tools and function calling with GPT-6 Luna. Chat Completions supports function calling only when reasoning_effort is none. If an existing GPT-4o application combines Chat Completions, tools and nonzero reasoning, a one-line model change is not enough.
3. Sampling parameters have compatibility limits
OpenAI's GPT-6 migration guidance says to remove temperature, top_p and top_logprobs when reasoning effort is not none. Chat Completions users must also remove logprobs. Search configuration files as well as application code; these values are often stored in environment-specific presets.
4. Prompt caching uses new controls and billing
For GPT-5.6 and later, OpenAI documents explicit cache breakpoints, exact eligible-boundary reporting and prompt_cache_options.ttl. GPT-6 Luna also charges for cache writes and offers a discounted cache-read rate. Recalculate both reads and writes, then confirm actual cached-token fields in API responses.
5. Fine-tuned models need a separate plan
OpenAI says fine-tuned versions of the deprecated models share the January 14 shutdown date, while the current Luna page lists fine-tuning as unsupported. Export your training and evaluation assets now, document what the fine-tune was meant to improve and test whether prompting, retrieval or Structured Outputs can meet the same acceptance criteria. Do not wait until the final week to discover that your replacement path needs a different architecture.
Before-and-After API Examples
A minimal GPT-4o Chat Completions request may look like this:
import OpenAI from "openai";
const client = new OpenAI();
const completion = await client.chat.completions.create({
model: "gpt-4o-2024-11-20",
temperature: 0,
messages: [
{ role: "user", content: "Return the support ticket category." }
]
});
console.log(completion.choices[0].message.content);
A conservative first Luna test through Responses can make the model and reasoning choice explicit:
import OpenAI from "openai";
const client = new OpenAI();
const response = await client.responses.create({
model: "gpt-6-luna",
reasoning: { effort: "none" },
input: "Return the support ticket category."
});
console.log(response.output_text);
For production extraction, use Structured Outputs with a schema rather than trusting free-form text. After saving a test response, Rubic8's JSON Formatter can make it easier to inspect, while the JSON Validator can catch syntax errors. Valid JSON is not the same as a correct business answer, so validate allowed labels and domain rules separately.
What to Test for Each Source Model
Migrating from GPT-4o
Prioritize mixed text-and-image cases, Structured Outputs, long system prompts and any workflows that depend on a particular writing style. GPT-4o's context window is much smaller than Luna's published window, but capacity alone does not prove that a long prompt will be followed in the same way. Compare image-detail settings, extracted facts and refusal behavior with a human-reviewed sample.
Migrating from GPT-4o mini
GPT-4o mini often appears in high-volume classification, tagging and extraction pipelines. Small error-rate changes can matter at that scale. Measure exact-label accuracy, invalid schemas, retry rate and accepted records per dollar. Luna's lower published token rates are promising, but only accepted output belongs in the savings calculation.
Migrating from GPT-4.1
GPT-4.1 is documented as a low-latency model without a reasoning step, with strong instruction following and tool calling. Test Luna with reasoning set explicitly to none before adding more reasoning. Pay special attention to tools, because an existing Chat Completions integration may need to move to Responses to use Luna's reasoning and tool capabilities together.
Migrating from GPT-4.1 mini
For bounded tasks, compare Luna at none and low effort. Track output length and hidden reasoning tokens as well as task success. If a pipeline uses a pinned snapshot to stabilize behavior, add prompt and schema versioning to the new deployment so future changes remain explainable.
A Safe GPT-6 Luna Migration Plan
Step 1: Find every exact model reference
Search application code, environment variables, dashboards, batch jobs, fine-tuning records, fallback routers, evaluation scripts and infrastructure templates. Record endpoint, model ID, owner, traffic, latency target, data region, tools, response format, reasoning or sampling settings and rollback path.
Also inspect aliases. The deprecation notice lists named model lines and snapshots; your inventory should show which exact identifier the application actually sends.
Step 2: Build a representative evaluation set
Use real tasks after removing secrets and personal data. Include common inputs, difficult edge cases, image inputs if used, long documents, tool failures, refusal cases and malformed data. Define acceptance criteria before looking at Luna's answers.
Useful measures include exact-label accuracy, schema validity, tool-call correctness, human review score, end-to-end latency, retries, input and output tokens, cache reads and writes, and cost per accepted result.
Step 3: Test the smallest compatible request first
Start with Luna and reasoning effort none for simple deterministic jobs. Remove unsupported sampling parameters only when the chosen reasoning mode requires it. Then add schemas, tools, caching and longer contexts one layer at a time. This makes failures easier to diagnose than changing the model, endpoint and prompt simultaneously.
Step 4: Run shadow traffic
Send a privacy-safe sample of production requests to both the current model and Luna without exposing Luna's result to users. Compare accepted outcomes, not just eloquence. For actions with side effects, keep the shadow path read-only and never execute duplicate tool calls.
Step 5: Canary the cutover
Move a small percentage of eligible traffic, monitor errors and quality signals, and preserve a configuration-level rollback. Increase traffic only after the canary meets its thresholds. Finish the cutover well before January 14 so the shutdown date is not your first full-load test.
Suggested Timeline Before January 14, 2027
- By October 31: complete the inventory, identify fine-tuned deployments and assign owners.
- By November 21: finish the evaluation set and first Responses API compatibility build.
- By December 12: complete shadow testing, cost review and security review.
- By December 22: start canary traffic with documented rollback.
- By January 7: complete production cutover and keep one week for observation.
- January 14: OpenAI's scheduled removal date for the listed models.
The intermediate dates are Rubic8's proposed project milestones. Only January 14 is the vendor's published shutdown date.
Frequently Asked Questions
When will GPT-4o and GPT-4.1 be removed from the API?
OpenAI's October 14, 2026 notice schedules the listed GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini models for removal on January 14, 2027.
What model should replace them?
OpenAI recommends gpt-6-luna for all four model lines in this notice. Treat that as the evaluation starting point, then test your own quality, latency and compatibility requirements.
Can I keep using Chat Completions?
GPT-6 Luna supports Chat Completions, but function calling there requires reasoning_effort: "none". OpenAI recommends the Responses API for built-in tools and function calling.
Is GPT-6 Luna cheaper?
Its published standard short-context token rates are lower than those of all four deprecated base models. Actual savings depend on reasoning tokens, output length, caching, tool charges, retries, processing tier and whether the result passes your acceptance test.
Can I migrate a fine-tuned GPT-4 model directly to Luna?
Not as a direct fine-tune replacement under the current specifications: deprecated fine-tuned models share the shutdown schedule, while GPT-6 Luna currently lists fine-tuning as unsupported. Build a separate behavior-migration plan and validate it early.
Final Recommendation
Start the migration now, but do not treat the deadline as permission to skip evaluation. Inventory exact IDs, use GPT-6 Luna as OpenAI's recommended first candidate, move tool-enabled workflows toward Responses, test reasoning and cache settings explicitly, and measure cost per accepted result.
The strongest migration is uneventful: users see the same or better outcomes, operators retain rollback control, and the old models can disappear on January 14 without becoming an incident.
Rubic8 Editorial Team
Editorial Team
Rubic8 creates practical guides and free tools for developers, webmasters, and digital publishers. Our fast-changing technical content is reviewed against current primary documentation before publication.