If your n8n, Make, or Zapier automation calls GPT-4o, GPT-4o mini, GPT-4.1, or GPT-4.1 mini through OpenAI’s API, it has an expiration date now. OpenAI announced on October 14, 2026 that these models leave the API on January 14, 2027, and the oldest GPT-4o snapshot is scheduled to go even sooner — October 23, 2026. The replacement OpenAI names for every model on the list is GPT-6 Luna.
Most of the coverage of this shutdown is written for developers. But if you’re like a lot of readers of this site, you don’t manage a codebase — you manage a stack of workflows you built with your mouse. Nobody is emailing you a migration plan. So this guide does it: how to find every automation that’s about to break, how to switch it over, the two traps that can silently wreck your workflows, and the real math on what the new model costs.
The calendar: this week’s problem comes first
Forget January for a minute. Here’s the actual shutdown schedule, straight from OpenAI’s official deprecations page and corroborated by reporting on it:
| Shutdown date | What’s leaving | Replacement |
|---|---|---|
| October 23, 2026 | gpt-4o-2024-05-13 (the first GPT-4o snapshot), gpt-4.1-nano, and older GPT-4 / GPT-4-turbo snapshots |
gpt-6-luna |
| January 14, 2027 | 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 |
gpt-6-luna |
| January 20, 2027 | GPT-4o audio and realtime models | (see OpenAI’s migration guidance) |
One line on OpenAI’s page matters more than anything else if you paid for custom training: “Fine-tuned versions of these models follow the same shutdown schedule as their underlying base models.” A fine-tune built on GPT-4o stops working on the same day GPT-4o does.
Read that first row again. October 23 is this week. If any of your workflows still pins the original May 2024 GPT-4o snapshot — and plenty do, because it was the default for months and people copy working setups without touching them — those automations can stop working within days, not months. Check those first.
(The January 20 audio/realtime date appears in secondary reporting on the deprecations page rather than in the sections I could read directly this week, so treat it as confirmed-by-reporting rather than something I personally verified against OpenAI’s page.)
Why the short notice matters for you
OpenAI’s own published policy promises generally available models at least six months of notice before removal. This notice runs three months. The policy does carry an exception — “if safety or compliance concerns require us to retire a model sooner, we will provide as much notice as reasonably possible” — but OpenAI’s page gives no reason for the shorter window. No journalist or analyst I’ve seen has found OpenAI tying this shutdown to that clause, either. So read it for what it is: less time than promised, with no explanation.
For a developer with a small codebase, three months is plenty. For a no-code automation owner running dozens of workflows built over two years, three months is tighter than it sounds — especially since the October 23 batch shrinks that window to essentially zero for the oldest snapshots.
One honest caveat before we go further: OpenAI also notes that “in some cases, developers may be able to provision dedicated capacity for continued access after a model’s shutdown date” through its sales team. That’s enterprise-tier conversation territory, not something you’ll buy on a $20 plan. For the rest of us, the move is to migrate.
Step 1: Find every workflow using the old models
This is the part most people skip, and it’s the part that burns them. The automations that break are never the ones you remember building — they’re the little classifier behind a feature nobody’s touched since launch, the ticket-router you copied from a template two years ago, the webhook handler running on a model string you typed in 2024.
If you self-host n8n
This is the fastest path. Open a terminal on the machine that runs n8n and export every workflow to its own file:
n8n export:workflow --backup --output=backup/
Then search those files for the dying model IDs. On Windows PowerShell:
Select-String -Path backup\*.json -Pattern "gpt-4o|gpt-4.1" -List
On macOS or Linux:
grep -rl "gpt-4o\|gpt-4.1" backup/
That pattern catches gpt-4o, gpt-4o-mini, gpt-4.1, and gpt-4.1-mini in one pass, including any pinned snapshot IDs like gpt-4o-2024-05-13. The -List flag (or grep -l) gives you one line per workflow — your hit list. Make a checklist from it before you change anything.
If you use n8n Cloud
There’s no command line, so it’s manual. Open each workflow, click into every OpenAI node, and read the model field. Tedious — but it’s the only reliable method. One shortcut: if you’re on a paid n8n plan, you can use the n8n public API to list workflows and scan the JSON programmatically, which amounts to the cloud version of the grep approach. If you’ve got more than about twenty workflows, that’s worth the setup time.
If you use Make
Open each scenario, click into the OpenAI modules (ChatGPT, “Create a Completion,” or any HTTP module pointing at api.openai.com), and check the model dropdown or any custom model string. The model field is the giveaway. Also check HTTP modules that call OpenAI’s endpoints directly with a hand-written body — the model name often hides in the JSON payload there, and it’s easy to miss because there’s no dropdown to glance at.
Make lets you export a scenario blueprint (the three-dot menu → Export). If you’re comfortable with it, export all your blueprints and search them the same way you’d search n8n JSON. It’s the same principle: the model name is a string, and strings are searchable.
If you use Zapier
Zapier’s built-in ChatGPT actions usually default to whatever model Zapier sets, and you can’t always pick the exact snapshot — but you absolutely must check every “Code by Zapier” step (Python or JavaScript) and every Webhooks step that posts to api.openai.com. Those are where hand-written model strings like "model": "gpt-4o-mini" live. Search your Zap history for the word “openai” first, then open every Zap that matches and read the code steps.
Here’s a walkthrough video that shows the audit process end-to-end for n8n and walks through OpenAI’s official deprecations page, the billing math, and the tool-calling trap below. If you’re more of a watch-it-than-read-it person, it’s a solid companion to this guide:
Step 2: Switch the model to GPT-6 Luna
Once you have your hit list, the change itself is boring — and that’s a compliment. GPT-6 Luna is OpenAI’s budget-tier model, launched September 22, 2026 alongside GPT-6 Sol. Luna is positioned for exactly the kind of work no-code automations do: high-volume, clearly-defined jobs like classification, extraction, summarization, and short answers.
The mechanics per platform:
- n8n (OpenAI Chat Model node): change the model to
gpt-6-luna. If you’re on a node version that has a “Use Responses API” toggle, turn it on — it matters for the tool-calling trap below. If your node predates the Responses API support, it’s worth upgrading the node rather than working around it. - Make: change the model field in each OpenAI module. For HTTP modules calling the API directly, replace the model string in your JSON payload.
- Zapier: for Code steps, replace the model string in your request body. For built-in ChatGPT actions, check whether Zapier has updated the available models — if the action still offers a GPT-4o-family model, switch to the newest available option and re-test.
Don’t just flip the string and walk away, though. The whole point of the next two sections is that a straight model swap can silently degrade your workflow.
Trap #1: GPT-6 Luna has no fine-tuning
If you paid OpenAI to fine-tune a GPT-4o or GPT-4o mini model — a classifier trained on your tickets, an extractor trained on your invoices, a router trained on your support patterns — that fine-tune dies on January 14 along with the base model, and GPT-6 Luna cannot take its place.
OpenAI’s own model references for the GPT-6 family list fine-tuning among the endpoints these models do not support. So there’s no “re-train on Luna” option. Your alternatives are:
- Prompt-engineer instead of fine-tune. For classification and extraction jobs — the most common things people fine-tuned small models for — a well-built few-shot prompt on Luna often matches or beats an old 4o-mini fine-tune, because Luna starts from a stronger baseline. Test before you conclude otherwise.
- Move to the Responses API with a strong system prompt. Sometimes the performance gap between a fine-tune and a prompt is mostly about consistency, and structured outputs plus a strict schema can close it.
- Accept a pricier model. If neither of the above passes your tests, GPT-6 Sol ($2/$10 per million input/output) supports the same APIs and is positioned for harder work. It’s the honest fallback when Luna genuinely isn’t enough.
This is the trap that costs real money, because fine-tuning isn’t cheap and people assume the replacement model will support it. Check whether any of your workflows reference a fine-tuned model ID (they look like ft:gpt-4o-mini-... with a suffix). Those need a redesign, not a model-string swap.
Trap #2: tool calling on Chat Completions needs reasoning_effort: "none" — or use the Responses API
This is the sneaky one, and it’s the one that will generate the most “my agent stopped working and I don’t know why” posts in January.
Here’s what’s documented: on GPT-6 Luna, function calling through the older Chat Completions endpoint only works when reasoning_effort is set to "none". The default reasoning effort is "medium". So if your workflow’s model call uses tools (function calling) and you migrate to Luna on Chat Completions without touching the effort setting, tool calls can fail or behave wrong — not with a helpful error, just broken agent behavior.
Your three options, per the documented behavior:
- Move the pipeline to the Responses API and keep your reasoning effort setting. This is the option OpenAI itself recommends, and it’s the future-proof one.
- Stay on Chat Completions and set
reasoning_effortto"none". Simple, but you lose reasoning entirely. - Remove tool calls from the model step and do lookups in code around it.
For no-code folks, what this means concretely: in n8n, turn on “Use Responses API” in the OpenAI Chat Model node for any workflow where the model uses tools. In Make or Zapier HTTP calls, either switch the endpoint from /v1/chat/completions to the Responses API endpoint or add "reasoning_effort": "none" to your request. Either way, test any tool-using workflow on Luna before January — don’t discover the breakage in production.
A related gotcha worth knowing: structured outputs and streaming don’t carry this restriction, so extraction workflows that return strict JSON are fine on either endpoint.
The cost math: what Luna actually does to your bill
Here’s the good news, and I’ve done the math with current published prices so you can check it yourself.
Verified list prices (USD per million tokens):
| Model | Input | Output | Cached input |
|---|---|---|---|
| GPT-4o mini | $0.15 | $0.60 | $0.075 |
| GPT-4o | $2.50 | $10.00 | $1.25 |
| GPT-6 Luna | $0.10 | $0.50 | $0.01 (90% discount on cached reads) |
Take a realistic no-code workload: 1,000 workflow runs a day, each using 2,000 input tokens and 500 output tokens. That’s 60 million input tokens and 15 million output tokens per month.
- On GPT-4o mini: (60 × $0.15) + (15 × $0.60) = $9 + $9 = $18/month
- On GPT-6 Luna: (60 × $0.10) + (15 × $0.50) = $6 + $7.50 = $13.50/month
- On GPT-4o: (60 × $2.50) + (15 × $10) = $150 + $150 = $300/month
So for the typical automation that runs on the mini model — and that’s most no-code automations — migrating to Luna saves about $4.50 a month on this workload, roughly 25% cheaper. Nice, not life-changing.
But if any of your workflows run on full GPT-4o (people over-provisioned constantly), the same workload drops from $300 to $13.50 — a $286.50 monthly saving, about 95%. That alone can pay for the migration afternoon.
Now the honest asterisk, and it’s important: reasoning tokens are billed as output tokens. Luna defaults to "medium" reasoning effort, which means it can generate internal reasoning tokens you never see in the response but absolutely see on the bill. On a high-volume workflow, medium reasoning can inflate your token usage well past what the table above suggests.
The fix is simple: for clerical work (classification, extraction, summarization), set reasoning effort to "none" — it’s the lowest latency and the cheapest, and these tasks don’t need reasoning. Reserve medium or higher for jobs where you can measure that the extra reasoning actually improves results. And either way, watch your first few runs after migrating. Log token usage per run, compare it to your old baseline, and set a daily spend alert in your OpenAI dashboard. The cheapest model in the catalog can still surprise you if its default settings spend tokens your old model never did.
Your pre-January checklist
Here’s the whole migration as a list you can work through in one sitting:
- This week: search for
gpt-4o-2024-05-13specifically — the October 23 batch is the urgent one. Anything pinning that snapshot needs to move first. - Audit everything: run the export-and-search for your platform (Step 1 above) and build your hit list. Don’t trust your memory; trust grep.
- Flag the fine-tunes: any
ft:model ID needs a redesign, not a swap. Those get their own project. - Flag the tool users: any workflow where the model calls functions needs the Responses API or
reasoning_effort: "none". Test these individually — they’re the most likely to break silently. - Swap the model strings to
gpt-6-lunaon the simple ones (straight text in, text out). - Run representative workloads against Luna and compare outputs to your old results. Check output formats, not just vibes — parsers downstream of the model are picky.
- Tune reasoning effort to
"none"for clerical tasks; measure before using medium. - Set a daily spend alert in the OpenAI dashboard and watch the first week of billed runs.
- Roll out gradually. Migrate one workflow at a time, verify it, then move on. The workflows you migrate in December are the ones that won’t wake you up on January 14.
While you’re in there: OpenAI’s Decisions API entered public beta this month, and its always-on agents are the other big new way to run agent work on OpenAI infrastructure. If you’re auditing every workflow anyway, it’s a good moment to see what the new API surfaces can do.
Frequently Asked Questions
Does this shutdown affect my ChatGPT subscription?
No. This is strictly about the API — the thing your automations call programmatically. Your ChatGPT Plus, Pro, or Free experience is unaffected. If the only “AI” you use is the ChatGPT website or app, you can ignore all of this.
What happens if I do nothing?
On the shutdown date, API calls to the retired models stop working — they return errors instead of completions. Any automation that still references the old model string breaks at that moment. For the October 23 batch, “that moment” is this week.
I’m on n8n Cloud and can’t use the export command. Now what?
Open each workflow and check the model field in every OpenAI node manually. If you’re on a paid plan, the n8n public API lets you list workflows and download their JSON — that’s the cloud equivalent of the export-and-grep approach, and it’s worth setting up if you have more than a couple dozen workflows.
Can I just keep using GPT-4o mini until January 13?
Yes — the models work normally until their shutdown date. But don’t confuse “works” with “safe.” The risk isn’t the model degrading; it’s that January 14 arrives and every workflow you forgot about breaks simultaneously. Migrate early, migrate gradually.
Is GPT-6 Luna actually good enough for my automations?
For high-volume clerical work — classification, extraction, summarization, short answers — yes, that’s literally what it’s built for, and it’s cheaper than the mini models it replaces. For genuinely hard reasoning, coding, or complex multi-step agents, consider GPT-6 Sol ($2 input / $10 output per million tokens) instead. The right move is to test Luna on your representative workloads and measure, not to guess from a blog post (including this one).
What about Azure OpenAI? Does the same January 14 date apply?
Not necessarily. Reporting on this shutdown notes that most of these models retire on Azure OpenAI on a different schedule — April 14, 2027 was cited for Azure. If your automations run through Azure rather than OpenAI directly, check Azure’s own retirement schedule for your deployments instead of assuming the OpenAI dates.