The AI model your business runs on is being retired: the 2026 shutdown calendar

OpenAI already shut down the Assistants API on 26 August 2026. The next cutoffs are 24 September, when it retires the Videos API and sora-2; 28 September, for the last legacy completion snapshots; and 23 October, for gpt-3.5-turbo and gpt-4. If your business runs a chatbot, an email classifier or any AI automation that was built for you in 2023 or 2024, there is a very high chance it is wired to one of those last two models. And on shutdown day it will not degrade gracefully: it will return an error and stop working.

This is not speculation or industry chatter. These are dates published by the providers themselves on their own deprecation pages, with six months’ notice. The problem is that the notice arrives by email to the developer account that created the API key — which half the time belongs to an agency that no longer works with you.

This article is the full calendar, how to find out in three minutes whether it affects you, and what to do if it does. If what you need is what each model costs, that lives in the guide to OpenAI, Claude and Gemini API pricing; here we go straight to what shuts down and when.

What nobody told you when you bought it

AI models are not software you buy once. They are a service with an expiry date, and the provider decides the date.

OpenAI puts it plainly in its documentation: “software relying on OpenAI models may need occasional updates to keep working.” Anthropic writes almost the same sentence. Translated into the language of the person paying the invoice: the chatbot you were handed as “finished” carries mandatory maintenance, and nobody put it in the quote.

This changes a decision plenty of businesses got wrong. When you asked for a quote to automate something with AI, you compared the implementation price and the monthly token cost. What you did not compare — because nobody showed you — was how often you would be paying for a migration. And on that, as we will see, providers are nothing alike.

---

First: does this affect you? The three-minute check

Before reading the calendar, find out which model you actually use. Not what you think you use: what is written in the code.

If you have access to the OpenAI dashboard

1. Sign in to platform.openai.com with the account that pays for the API.
2. Go to Usage and switch the breakdown to group by model.
3. Look at the last 30 days. Those names are what you are really running.

If you have access to the Anthropic console

1. Open the Usage page in the Claude Console.
2. Click Export.
3. The CSV gives you usage broken down by API key and by model. Anthropic documents this exact procedure for auditing deprecated models.

If you have access to nothing

This is the most common case, and it is the finding in itself. If nobody at your company can log into the provider’s dashboard:

• The API key belongs to a third party. The retirement notice goes to them, not to you.
• You cannot audit the spend, so you also do not know whether you are overpaying.
• You cannot migrate without them, which means the continuity of a business process depends on that person picking up the phone.

All three are governance problems, not technical ones, and they are fixed the same way: the AI provider account is opened in the company’s name, paid by the company, and the external developer is added as an invited user. If this is your situation, that is the first job — before any migration.

---

OpenAI’s shutdown calendar

These are the dates published on OpenAI’s official deprecations page, checked on 16 August 2026 and reconfirmed on 13 September 2026. I have bolded the ones that hit small businesses hardest.

Two of those dates are closer than the headline one, and easy to miss because they read like small print next to it. 24 September retires the Videos API along with sora-2 and sora-2-pro — with no replacement listed, so anything built on video generation needs a different plan, not just a different model string. 28 September retires the last of the old completion-style snapshots (gpt-3.5-turbo-instruct, babbage-002, davinci-002, gpt-3.5-turbo-1106) into gpt-5.6-terra. Neither is wired into as many small-business chatbots as gpt-3.5-turbo or gpt-4 are — but if your stack touches either one, your date is 24 or 28 September, not 23 October.

And a third one shows that six months’ notice does not apply to everything: gpt-5.4-cyber was announced on 11 September and shuts down on 1 October, twenty days later. The six-month minimum OpenAI promises covers generally available models, not its whole catalogue, so do not assume it for variants like this one.

Three readings of that table matter more than the table itself:

1. 23 October is the big one. gpt-3.5-turbo and gpt-4-0613 are the models that appear literally in every tutorial from 2023 and 2024. Any integration copied from a blog, a course or the documentation of that era has them hardcoded. And because they worked without complaining for three years, nobody has touched them since. (For what actually changed in the replacements, see the GPT-5.6 launch rundown.) ⚠️ And if the GPT-6 Astra launch on 3 September tempts you to migrate straight there: for a chatbot or a classifier that is an expensive mistake. Astra costs 20x the input and 33x the output of gpt-3.5-turbo, and its million-token window hides a 2x surcharge past 272K. The migration ladder by workload type is in GPT-6 Astra for developers.

2. Whole APIs are shutting down, not just models. The Assistants API, Agent Builder, the Evals platform and reusable prompts all disappear. That is not fixed by changing a string: it is rewriting the integration. Anyone who built on Assistants is looking at days of work, not minutes.

Reusable prompts are the sneakiest case, because the prompt text is not in your repository: it is stored in the OpenAI dashboard, and your code only references it with prompt: { id: "pmpt_…" } in the Responses API call. On 30 November the v1/prompts API and those prompt objects shut down, so the official migration guide asks you to take the content out of the dashboard, move it into your code and send it as input. Evals also has an intermediate step: from 31 October your existing evals become read-only, a month before the dashboard and API disappear.

3. Pinned snapshots die even when the model “lives on”. Look at gpt-5-2025-08-07. GPT-5 is not disappearing as a family, but that specific snapshot is. If your code pins the date — which is the good practice for reproducible results — then you are on the shutdown calendar even while running a model that feels current.

---

Anthropic’s calendar works differently

Anthropic publishes the same thing on its model deprecations page, but with one difference that changes how you plan.

Careful not to read those “not sooner than” entries as shutdown dates: they are floors, not announcements. As of 13 September 2026 none of the three Claude 4.5 models has an announced deprecation, and with the 60 days’ notice Anthropic commits to, none of them can be retired before 12 November.

The difference is in the notice period, and it is a big one:

Sixty days is not much. claude-opus-4-1 was announced on 5 June and switched off on 5 August: two months exactly. If your business slows down in August, or your developer is on holiday, or nobody simply reads that email, the entire notice window passes you by.

This does not make Anthropic a bad choice — its models are excellent, and the retirement pace is the flip side of a very high release pace. It means the notice period is a product feature you should compare before choosing, the same as price or latency. And it appears in none of the comparison posts doing the rounds.

---

Gemini: two shutdowns between September and October

Google publishes its own on the Gemini API deprecations page, checked on 13 September 2026. Between September and December 2026 there are two dates, plus one that has already passed and is worth checking if your integration dates from 2025:

Two details in that table. gemini-omni-flash-preview, the video generation model, launched on 30 June and shuts down three months later: the textbook example of why you do not build a business process on a preview. And for gemini-2.5-flash-image — the original Nano Banana — the official page lists gemini-3.1-flash-image-preview as the replacement, but that preview was already shut down on 25 June 2026 and the same page gives the stable version, gemini-3.1-flash-image (Nano Banana 2), as its replacement, which is where it makes sense to migrate directly.

Gemini 2.5’s text models (gemini-2.5-pro, gemini-2.5-flash, gemini-2.5-flash-lite) still have no announced shutdown date.

---

The trap that catches the most people: where you run it changes the date

This is the detail nobody has written up properly, and the one that produces the most expensive surprises.

The dates above are the original provider’s. If you consume the same model through somebody else’s cloud, the dates are different.

• Anthropic says so explicitly: its dates apply to the Claude API, the Claude Platform on AWS and Microsoft Foundry. Amazon Bedrock and Google Cloud Vertex AI set their own retirement schedules, so the same model’s status and dates can differ.
• The same is true of OpenAI: Azure OpenAI publishes its own retirements table, which is not always in sync with OpenAI direct.

flowchart TB
    A["Same model,<br/>three different dates"] --> B["Provider's direct API"]
    A --> C["Azure OpenAI / Microsoft Foundry"]
    A --> D["Amazon Bedrock / Google Vertex"]
    B --> B1["Date on the official<br/>deprecations page"]
    C --> C1["Microsoft's own schedule"]
    D --> D1["Cloud operator's<br/>own schedule"]
    B1 --> E["⚠️ Check the table for<br/>WHERE YOU RUN IT,<br/>not the model maker's"]
    C1 --> E
    D1 --> E

The practical consequence: if your integration goes through Bedrock or Azure, the table you need is not the one I just published. It is your cloud’s. Setting the alarm for the wrong date is as bad as not setting one.

---

What else breaks, and it isn’t a model

Beyond the shutdowns, there are silent retirements that break code without any model dying.

The live example right now: Anthropic deprecated the temperature, top_p and top_k parameters as of Claude Opus 4.7. It does not ignore them — it returns a 400 error if you send them with anything other than the default value. Any integration that tuned the model’s “creativity” with temperature: 0.7 — which is practically every integration from 2023–2024 — stops working the moment you move to a current model.

This matters because it dismantles the naive plan. Plenty of people assume migrating means swapping "gpt-4" for "gpt-5.6-sol" and done. Sometimes it is. But you may also be facing:

• Parameters that are no longer accepted (the case above).
• Different response formats, if you used structured output.
• Entire APIs rewritten (Assistants → Responses).
• Prompts that stop performing the same. A new model is not the old one but better: it is a different one. Prompts tuned by trial and error against gpt-4 can do worse on gpt-5.6-sol until they are readjusted.

That last point eats the most budget and is the one that never gets quoted.

---

The migration procedure

If you have a technical team, this is the order that works. If you do not, skip to the next section.

1. Inventory before touching anything

Search the whole codebase for model strings, not just the obvious file:

# OpenAI models hardcoded in the code
grep -rn "gpt-3.5-turbo\|gpt-4-0613\|gpt-4-turbo\|gpt-4o-2024" \
  --include="*.php" --include="*.js" --include="*.ts" --include="*.py" .

# Prompts stored in the OpenAI dashboard (v1/prompts shuts down 30 Nov 2026)
grep -rn "pmpt_\|prompt_id" .

# Anthropic models
grep -rn "claude-3\|claude-sonnet-4-2025\|claude-opus-4-2025" .

# And what nearly everyone forgets: environment variables and config
grep -rn "MODEL" .env .env.example config/ 2>/dev/null

Also check the places where the model name is not in the repository at all: n8n or Make panels, serverless functions, cron jobs, and any third-party automation consuming your key.

This kind of break stays invisible until the exact day for a specific reason: a hardcoded model ID needs no validation to keep working. It succeeds every single time you call it, for as long as the model is alive, then fails on the very next call after retirement. There is no warning header on the 200 responses the week before, no gradual dip in quality to notice — the API goes straight from working to a 400 or 404 the moment the shutdown date arrives. If nothing in your code specifically catches that error, the person using your product just sees something break, with nothing in the interface pointing at the real cause.

That is also why it is worth pulling your API logs now, not only grepping your code. A spike in 400 or 404 responses from api.openai.com or api.anthropic.com around a retirement date is the model dying in production — and it is usually a customer who reports it first, not a dashboard.

2. Pin the version, don’t use the alias

If your code says plain "gpt-4", you are using an alias the provider repoints whenever it likes. That looks convenient and is exactly the opposite: it means your system’s behaviour can change on a Tuesday without you touching anything.

The correct practice is to pin the dated snapshot and control yourself when you move up. Yes, that puts you on the shutdown calendar — but it puts you there predictably, which is precisely what you want.

3. Compare side by side before switching

Do not swap the model in production and wait to see what happens. Take 30 or 50 real cases from your history, run them through the old model and the new one, and compare outputs side by side. It is an afternoon’s work and it is the difference between a migration and an incident.

4. Put the provider behind your own layer

This is the work that makes the next shutdown boring. Instead of calling the provider’s SDK from twenty places, call it from one:

// A single place where the decision of which model to use lives.
// The rest of the application asks for "reasoning" or "classification",
// not for "gpt-5.6-sol".

const MODELS = {
  reasoning:      { provider: 'openai',    model: 'gpt-5.6-sol' },
  classification: { provider: 'openai',    model: 'gpt-5.6-terra' },
  summarisation:  { provider: 'anthropic', model: 'claude-sonnet-5' },
} as const;

export async function complete(task: keyof typeof MODELS, prompt: string) {
  const { provider, model } = MODELS[task];
  return provider === 'openai'
    ? callOpenAI(model, prompt)
    : callAnthropic(model, prompt);
}

With that in place, the next shutdown is editing one line of an object and re-running step 3’s comparison. Without it, it is find-and-replace across twenty files and hoping.

You do not need a framework for this. LangChain or LlamaIndex solve the same problem and bring far more baggage than a small business needs; thirty lines of your own usually do the job without adding a dependency that can also be deprecated.

---

If you have no technical team: what to demand, and from whom

For the owner or operations lead who will not be touching code, the job is different — and more important.

What to ask, in writing, from whoever maintains your integration:

1. Which exact model each process uses, with the full name and snapshot date. “We use ChatGPT” is not an answer.
2. Which platform it runs on — direct API, Azure, Bedrock, Vertex — because the real date depends on it.
3. The shutdown date for each one, taken from that platform’s table.
4. Who receives the deprecation emails. If it is an account you do not control, change that this week.
5. What the migration costs and who pays for it. This is the uncomfortable question, and it needs asking now, not in October.

And what belongs in the contract from here on: deprecation maintenance is not an enhancement or a nice-to-have — it is what keeps the system switched on. Either it is covered by a retainer, or it is priced up front. Discovering it on shutdown day, with the process already down, is the worst negotiating position available.

I say this from the uncomfortable side of the table: I make a living building these integrations. And even so, a client who does not understand that this carries maintenance is a client who will feel ripped off a year from now — rightly.

---

What the switch costs (and why you sometimes come out ahead)

Migrating is not always a net expense. Newer models tend to be considerably cheaper per token than the ones they replace, and considerably more capable, so three effects offset each other:

• In your favour: the replacement’s price per million tokens is usually lower. A process that cost X on gpt-4 can cost a fraction on its successor.
• In your favour: more capable models need shorter prompts for the same quality, and a shorter prompt is fewer tokens.
• Against you: reasoning models burn internal tokens that you also pay for. Switching to one of those by accident can multiply the bill even as the unit price drops.

The only honest way to know is to measure it with your real data before switching. The numbers and the method are in the OpenAI, Claude and Gemini API pricing guide, and if you want to estimate a specific prompt’s consumption before sending it, the token counter alongside does it with no signup.

---

The radical way out: make it un-switchoffable

There is one way to make this article never apply to you: run the model yourself.

An open model running on your own hardware cannot be retired by anyone. It keeps working exactly the same three years from now, with the same outputs, no deprecation emails and no date on the calendar. For stable internal processes — classifying email, extracting data from documents, summarising — it is a real option, and today it runs on affordable hardware.

It is not free: you pay in hardware, in electricity, and in quality that trails the frontier models. I wrote the full analysis, with the machine I use and measured numbers, in AI without sending data outside: a local LLM for small firms. The continuity section of that article is exactly this problem seen from the other side.

For most people the sensible call is not picking a side but splitting: provider models for what needs frontier quality, your own model for the stable processes you would rather not tie to anybody’s calendar.

---

Frequently asked questions

What exactly happens on shutdown day?

The request fails. There is no degradation and no automatic substitution: the model stops being reachable and the API returns an error. Anthropic says it literally — “requests to retired models will fail” — and OpenAI that the model or endpoint “will no longer be accessible.” If your application does not handle that error, what the end user sees is a broken screen.

I use ChatGPT in the browser, not the API. Does this affect me?

Far less. The dates in this article are for the API, which is what integrations consume. In the ChatGPT app, retired models are swapped for the current one automatically and at most you notice it answers differently. The serious risk is to anything automated.

How do I know if my chatbot uses the Assistants API?

Ask whoever built it, and if you cannot, check the OpenAI dashboard: if assistants appear under Assistants, it is in use. The code gives it away too — it will call endpoints under /v1/assistants or /v1/threads. If you have not migrated yet, that one is no longer a countdown: the Assistants API already shut down on 26 August 2026, so a chatbot still calling it is already broken, not about to be.

Is migrating just changing the model name?

Sometimes yes, sometimes no. Swapping the string is enough if you only used plain text generation. But you may need to rewrite if you used the Assistants API, if you send already-deprecated parameters — temperature returns a 400 error on current Claude models — or if your prompts were tuned against the old model. Budget for the output comparison, which is the part that actually takes time.

How often will this happen again?

Permanently. OpenAI gives at least 6 months’ notice for generally available models; Anthropic, 60 days. At that pace, the realistic plan is a model review every six months and a small migration once a year. It is recurring maintenance, like upgrading the framework or renewing an SSL certificate.

Does using LangChain or a chatbot SaaS protect me?

Partly, with caveats. An abstraction layer makes the switch cheaper, but it does not stop the underlying model dying or remove the need to revalidate quality. And if the middleman is a SaaS, you inherit its calendar and the risk that it deprecates features of its own — which is exactly what OpenAI did with Agent Builder, its own product, retiring on 30 November 2026.

---

Conclusion: put it in the calendar today

Boiled down to what to do this week:

1. Find out which model you actually use. OpenAI dashboard grouped by model, or the CSV export from the Claude console. Three minutes.
2. Check which platform it runs on, because that is what determines the real date.
3. Set an alarm for every date that applies to you: 24 September 2026 if you use Sora or the Videos API; 28 September if you still call old completion-style models; 30 September or 2 October if you generate video or images with Gemini (gemini-omni-flash-preview, gemini-2.5-flash-image); 23 October if any gpt-3.5-turbo or gpt-4 shows up in your inventory; 31 October and 30 November if you use Evals, Agent Builder or prompts stored in the dashboard; 1 December if you generate images with gpt-image-1.5 or gpt-image-1-mini; and 11 December if you pin gpt-5 or o3 snapshots. (If you were still calling the Assistants API, that alarm already went off on 26 August — check today whether it is broken.)
4. If your code calls the Responses API with prompt: { id: "pmpt_…" }, copy that prompt into your repository. The text lives in the OpenAI dashboard, not in your code, and on 30 November 2026 the v1/prompts API and reusable prompts shut down. The official guide says to move the content into your code and send it as input. If the account belongs to your agency, ask them for it now, not on 30 November.
5. Verify who receives the deprecation emails. If it is not somebody at your company, fix that before anything else.
6. And ask what the migration costs, while there is still room to negotiate it calmly.

Model shutdowns are not an exotic technical problem: they are ordinary maintenance for a technology moving fast. What is a problem is finding out about them on the day the chatbot stops answering.

If you have an AI integration in production and cannot answer question 1 on that list, get in touch and we will review it. Auditing which models you run and when they die is a short job, and it is better done weeks before the shutdown than the day after.