OpenAI shuts down the Assistants API and retires models: how to migrate your automations before 23 October

A retired API doesn't warn the end user. The first warning usually comes from an annoyed customer.

On 26 August 2026 OpenAI shut down the Assistants API. It had announced the date a year earlier, on 26 August 2025, and it kept to it. Any chatbot, internal assistant or n8n flow still creating threads and runs against that endpoint has returned an error since that day. The official replacements are the Responses API and the Conversations API, according to OpenAI's deprecations page.

More is coming. On 23 October 2026 OpenAI switches off gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-turbo, o1, o1-pro, o3-mini and fine-tunes built on older models. On 30 November, Evals, Agent Builder and the Reusable prompts API go. On 1 December, several GPT Image models. On 26 February 2027 it's the turn of whisper-1 and the gpt-4o family of transcription models.

If you built automations on OpenAI in 2023 or 2024 and nobody has reviewed them since, at least one of them is on that list. This article explains how to migrate off the OpenAI Assistants API and the retired models with a four-step method: inventory, replacement table, order by risk and testing before you touch production.

Providers retire models. It's part of the deal. What costs money is finding out three weeks late.

What OpenAI has shut down and what's next: timeline from August 2026 to February 2027

First, the full map. This table brings together everything dated between August 2026 and February 2027 that affects typical small-business automations.

Three notes on this table.

The "latest" aliases are already gone. Make published a notice for its users: gpt-5.2-chat-latest and gpt-5.3-chat-latest were shut down on 10 August 2026 and the scenarios using them stopped running. If your scenario has been throwing errors since August and nobody has noticed, that's the symptom.

23 October takes more than it seems. The notice is dated 22 April 2026 and the official list includes models many people think of as recent, such as gpt-4o-2024-05-13, gpt-4.1-nano or o4-mini. If your flow uses one of those with the date written into the name, it's affected.

The replacement column is a starting point. For the Assistants API and for Whisper there's little to decide. For the 23 October models, the right replacement depends on what you used each one for. You decide that in step 2, flow by flow.

Why your automations can fail without anyone noticing

An AI automation runs in the background. Nobody watches it while it works. That's the point of automating, and it's also where the risk sits.

Almost all of these integrations started the same way in 2023 and 2024. Someone connected the website form to an OpenAI assistant, or a Teams recording to Whisper to produce the minutes. It worked first time, and it was left as it was.

When the endpoint or the model disappears, things like this happen:

• The website chatbot replies with a generic message. "Sorry, something went wrong. Please try again later." The visitor leaves. Nobody at the company ever asks their own chatbot anything.
• The n8n flow stops at a node. If there's no error workflow configured, the failed execution sits in the history. Nobody opens the history.
• The Make scenario deactivates itself after several errors in a row. With a scheduled trigger, Make switches it off by default after three consecutive errors. The alert goes by email to whoever has notifications turned on, which is sometimes someone who no longer works at the company.
• The transcription comes back empty. The meeting minutes arrive with no content, or don't arrive at all. For a couple of weeks everyone assumes someone else will send them.

Example: a 14-person payroll and employment advisory firm in Sabadell, near Barcelona, has an assistant on its website about the working calendar and payroll deadlines, built in 2024 on the Assistants API. On 26 August it stops responding. In August nobody at the firm visits its own website. The first warning arrives in mid-September, from a client who mentions on the phone that the website chat isn't working.

Translation: the technical error happens in a second, and the process gap stretches it to three weeks. The gap is not knowing what depends on what.

Step 1: inventory your integrations before migrating off the OpenAI Assistants API

Before changing anything, you need a list. Without one, you migrate what you remember and leave the rest behind.

Where to look

OpenAI usage dashboard. Start here. On the OpenAI platform you can see usage broken down by model and by API key. If you see usage on a key you don't recognise, write it down: that's the one that will give you the most trouble.

API key list. Go through every key in the organisation and in each project. For each one, ask where it's pasted. A key nobody can place is a dependency with no owner.

n8n. Find every workflow with OpenAI nodes. Watch out for the ones that pick the model with an expression. The fastest route is to export the workflows to JSON and search the text. If you set up n8n following the guide to automation with n8n without your own servers, your flows are all in one place and the inventory takes an afternoon.

Make. Check the scenarios with OpenAI modules. Deactivated scenarios count too: one of them may have switched itself off after errors without anyone realising.

Zapier. Same exercise with the zaps that use the OpenAI or ChatGPT app. Go through each one's run history looking for errors since August.

Your own code. If you have scripts in Python, Node or Apps Script for Google Sheets, search the repositories for model names and calls to assistants, threads and runs. A text search is enough:

grep -rnE "assistants|threads|runs\.create|gpt-4-turbo|gpt-4-0613|gpt-4-1106|gpt-3\.5-turbo|gpt-4o-2024-05-13|gpt-4\.1-nano|o1|o3-mini|o4-mini|gpt-image-1|whisper-1|transcribe|ft:" .

You'll get false positives. Better to review twenty lines too many than to miss one.

Check configuration files and environment variables too. Often the model isn't in the code at all: it's in a .env file or in a spreadsheet the script reads on start-up.

Third-party plugins and SaaS. WordPress chatbot plugins, customer service tools, CRMs with "built-in AI" where you pasted your key. Either the provider picked the model, or you picked it from a dropdown two years ago. If there's no way to see it, ask the provider's support which model and which endpoint they use with your key.

The inventory sheet

A simple spreadsheet. Nothing more. These columns:

The last column sets the order of work later. A failure a customer sees weighs more than one a colleague sees.

Rule: if a flow has no owner, you're the owner until someone else is assigned.

Step 2: replacement table by endpoint and model

There are two very different kinds of change here: endpoint and model.

Endpoint change: from the Assistants API to the Responses API

The Assistants API worked with four pieces: assistant, thread, messages and runs. In the Responses API each call is a response, and the history, if you need it, is stored with the Conversations API.

In practice, the mapping looks like this:

Critical note: don't move the assistant's instructions to a reusable prompt stored on the OpenAI platform. The Reusable prompts API is retired on 30 November 2026. If you do, you'll be migrating again in December. Instructions belong in your repository or in your flow.

If your assistant answered from uploaded files (the typical FAQ PDF), check they're still accessible from the new configuration. It's the detail people forget most often: the chatbot keeps answering, but it makes up what it used to read from the PDF.

Model change: the models retired on 23 October

OpenAI assigns a replacement to each model in its deprecations table: gpt-5.6-sol for gpt-4-0613, gpt-4-1106-preview, gpt-4-turbo, gpt-4o-2024-05-13, o1, o1-pro and o3-mini; gpt-5.6-terra for gpt-3.5-turbo-0125 and o4-mini; and gpt-5.6-luna for gpt-4.1-nano. That's your first candidate. Before applying it, ask yourself what you used that model for.

Many 2023 flows used gpt-3.5-turbo for tasks that don't need a language model at all: normalising province names, detecting whether an email is an invoice, assigning a category from a closed list. The migration is a good moment to take the model out of the loop. In the article on determinism before LLMs I explain when a function or a lookup catalogue does that job better and cheaper.

If the flow does need AI, pick the model for the task it solves. Habit is not a criterion. The guide to models by task separates OCR, extraction, classification and reasoning. A flow that used o1 to pull four fields from a delivery note was probably paying for reasoning it never used.

Transcription: from whisper-1 to gpt-transcribe or gpt-live-transcribe

On 26 February 2027 whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe and gpt-4o-transcribe-diarize are retired. OpenAI names two replacements: gpt-live-transcribe and gpt-transcribe.

If your flow transcribes finished recordings (Monday's meeting minutes, recorded calls from the switchboard), start by testing gpt-transcribe. If it transcribes live, the natural candidate is gpt-live-transcribe. Confirm it on each model's page before deciding.

If you used gpt-4o-transcribe-diarize, it's because you needed to know who was speaking at each moment. Check that the replacement separates speakers. Minutes without names are worth a lot less.

Images: GPT Image in two rounds

gpt-image-1 goes on 23 October. gpt-image-1-mini, gpt-image-1.5 and chatgpt-image-latest go on 1 December 2026, with gpt-image-2.5-sunburst or gpt-image-2.5-flare as replacements. Here the test is visual: the same ten images from the old model and the new one, side by side.

Evals, Agent Builder and reusable prompts

These three pieces are retired on 30 November 2026. If someone on your team built an agent in Agent Builder or has evaluation suites in Evals, copy out everything you can now: instructions, test cases, configurations. A simple agent fits in an n8n flow. A set of evaluations fits in a sheet with inputs, expected outputs and a script that compares them.

Whatever you don't get out before the date, you rebuild from memory.

Step 3: in what order to migrate off the OpenAI Assistants API and the rest, by risk

That leaves the order. Two criteria: when it shuts down and who notices the failure.

Priority 1: what's already broken. Everything that depended on the Assistants API or on the gpt-5.2-chat-latest and gpt-5.3-chat-latest aliases. If something like that shows up in the inventory and seems to work, check it. It may have been failing silently since August.

Priority 2: customer-facing flows on 23 October models. Chatbots, automatic replies, quotes or documents generated for people outside the company. If they fail, the customer notices before you do.

Priority 3: fine-tunes. They also go on 23 October, but they get their own slot because they take longer: find the training set, retrain and test. If the set has been lost, rebuilding it takes days.

Priority 4: internal flows on 23 October models. Email classification, summaries for the team, data extraction someone reviews afterwards. If they fail, a colleague notices. Annoying, but it stays inside.

Priority 5: Evals, Agent Builder and reusable prompts. Date: 30 November. Start by getting the information out, even if you do the migration later.

Priority 6: GPT Image. Date: 1 December. If you use gpt-image-1, move it up to priority 2 or 4.

Priority 7: transcription. Date: 26 February 2027. It's the last one, but don't leave it until February. Minutes usually matter to senior management, and senior management takes it very badly when the minutes of a board meeting go missing.

Example: an electrical supplies distributor with 40 employees in Zaragoza does the inventory and finds six flows. A website chatbot on the Assistants API (priority 1, down since August without anyone knowing). A Make flow that drafts replies to quote requests with gpt-4-turbo (priority 2). A 2023 fine-tune that classifies product references (priority 3). An n8n flow that summarises warehouse incidents with gpt-3.5-turbo-0125 (priority 4). A test agent in Agent Builder nobody uses (priority 5). And the minutes of the weekly committee with whisper-1 (priority 7).

With that list, the plan fits into six weeks for two people: the chatbot and the copy of reference outputs in the first week, quotes and the fine-tune in the second and third, the rest afterwards.

Step 4: test before changing production

Changing the model in a dropdown takes a moment. Discovering that the new one returns the JSON with a different structure takes a lot longer.

The testing method is simple:

1. Gather real cases. Real inputs from the last month, including the odd ones: the email in Catalan, the crooked scanned PDF, the audio with background noise. Easy cases work with any model.
2. Save the outputs of the old system. If the old model still responds (the 23 October ones, until that date), run the cases and save the results. That's your reference. After the shutdown you won't be able to generate it.
3. Duplicate the flow. In n8n, duplicate the workflow and pin the input data so you can repeat the same test. In Make, clone the scenario. In code, a separate branch. You never test on the flow that's in production.
4. Compare output against output. Check format, length, tone and accuracy. If the flow expects JSON with specific fields, check that the same fields come out with the same names. And test the whole flow: a model that answers "Invoice." with a full stop breaks a filter three steps further down that expected "Invoice".
5. Look at cost and response time. The OpenAI usage dashboard shows you consumption. A reasoning model can be slower and more expensive than the one you had. In a chatbot, a few seconds of waiting are noticeable.
6. Switch production with someone watching. On the day of the change, someone reviews the first real executions. Not on a Friday afternoon.

Real perspective: most model migrations are boring. You change the name, you test, it works. The ones that cause trouble had a very tight output format or a prompt written around the old model's quirks. You find those in testing or in production. Your choice.

Common mistakes

Mistake 1: Trusting the "latest" aliases. Symptom: a scenario nobody has touched stops working on 10 August. Nobody changed anything. The model behind the alias disappeared. Fix: in production, always use a pinned model version. The "latest" alias is for testing. For a flow your business depends on, use a pinned version and put a review date in the calendar.

Mistake 2: Forgotten fine-tunes. Symptom: a node shows a model starting with ft: and nobody remembers who trained it or on what data. On 23 October it stops responding. Fix: find the training set now. If it exists, retrain on a current base model and test. If it doesn't, consider whether the task really needs a fine-tune or whether a current model with good instructions and a few examples will do.

Mistake 3: Shared keys with no owner. Symptom: a single API key pasted into the chatbot, n8n, Make and a Sheets script. Someone who has since left created it. You can't rotate it without breaking everything, and you don't know what each thing spends. Fix: one key per project or per flow, with a descriptive name and an owner. Then the usage dashboard tells you which flow uses which model, and the inventory almost maintains itself.

Mistake 4: Migrating to another piece that's also being retired. Symptom: in September you move the assistant's instructions to a reusable prompt on the OpenAI platform, or build the replacement in Agent Builder. On 30 November it fails again. Fix: before choosing a destination, check it against the deprecations page. Instructions and logic belong in your code or in your flow.

How not to go through this again: dependency register and an intermediate layer

Providers retire models and endpoints on a regular basis. It will happen again. Two pieces let you find out in time.

A register of AI dependencies with an owner

The step 1 sheet doesn't get thrown away after the migration. It stays as a live register: every new flow that calls a model goes into the sheet on the day it goes into production.

Alongside the register, an owner. One named person who:

• Checks OpenAI's deprecations page (and that of any other provider you use) once a month.
• Checks new dates against the register.
• Opens a task for each affected flow, with its deadline.
• Makes sure provider notices reach an inbox someone reads, not the personal email of whoever signed up for the account.

What matters is that the task has an owner. In a small company it takes a short while each month.

And every flow gets an error alert that reaches a person: an error workflow in n8n, notifications to a shared inbox in Make, logging with alerts in code. You need to see a failure on the day it happens.

An intermediate layer between your flows and the provider

The underlying problem is that the model name is written in twenty places: every n8n node, every Make module, every script. When the model goes, you have to visit all twenty.

The structural fix is for your flows to call an intermediate layer that decides which model to use for each task, instead of going straight to OpenAI. If a model is retired or you want to try another provider, you change the configuration in one place. I explain it in detail in the article on an AI model gateway without lock-in, including how to migrate a flow in production without interrupting the service.

For a small business with three or four flows, the intermediate layer can be as simple as a single n8n workflow that all the others call, with the model defined in a variable. To start with, that's plenty.

It's not complicated. It's discipline.

Frequently asked questions

What happens to the OpenAI Assistants API after 26 August 2026?

It stops working. OpenAI retired it that day, a year after announcing it, and calls that create assistants, threads or runs return an error. To migrate off the OpenAI Assistants API you have to move to the Responses API, with the Conversations API if you need to store the conversation history.

Which OpenAI models are retired on 23 October 2026?

Among others, gpt-3.5-turbo-0125, gpt-4-0613, gpt-4-1106-preview, gpt-4-turbo, gpt-4o-2024-05-13, gpt-4.1-nano, o1, o1-pro, o3-mini, o4-mini and gpt-image-1, plus fine-tunes of gpt-3.5-turbo, gpt-4, gpt-4.1-nano, babbage-002 and davinci-002. Any flow that calls them by name will return an error from that date. OpenAI proposes gpt-5.6-sol, gpt-5.6-terra or gpt-5.6-luna as replacements, depending on the model.

Why has my OpenAI automation in n8n or Make stopped working?

Most likely it uses a model or an endpoint that has already been retired. If it failed on 10 August 2026, check whether it used the gpt-5.2-chat-latest or gpt-5.3-chat-latest aliases. If it failed on 26 August, it used the Assistants API. Open the execution history, find the first error and look at which model or operation appears in the failing node.

When is Whisper retired from the OpenAI API and what replaces it?

whisper-1 is retired on 26 February 2027, along with gpt-4o-transcribe, gpt-4o-mini-transcribe and gpt-4o-transcribe-diarize. The replacements are gpt-live-transcribe and gpt-transcribe. If you needed to separate speakers, check that the replacement you choose handles it before migrating.

How do I migrate from the Assistants API to the Responses API?

Keep the assistant's instructions in your own code or flow, replace each run with a call to the Responses API and use the Conversations API for the history. Declare the tools in the call itself. Don't move the instructions to a reusable prompt on the platform, because that API is also retired on 30 November 2026.

How do I find out which OpenAI models my automations use?

Start with the OpenAI usage dashboard, which shows consumption by model and by API key. Then go through n8n, Make and Zapier, search your code for model names and record everything in a sheet with flow, model, key and owner.

What to do this week

23 October is 17 days from the date of this article. If you haven't done the inventory, open the OpenAI usage dashboard today. You'll know straight away whether anything of yours calls gpt-4-turbo, o1 or gpt-3.5-turbo-0125. That alone tells you whether you have work to do.

Then, the four steps. None of them needs a large technical team. All of them need someone to sit down and do them.

If you'd rather go through it with me, services explains how I handle this kind of job: an inventory of AI dependencies, a migration plan by priority and an intermediate layer, so the next model retirement is solved by changing one line of configuration.

Sources:

• OpenAI: API deprecations page
• Make: notice on the deprecation of GPT models on 10 August 2026
• Make: scenario settings and consecutive errors