The model behind your assistant gets switched off

The assistant on your website answers questions at eleven at night. It quotes prices correctly, it knows which days you are closed, and after a year of small corrections it sounds like your business, not like software.

Underneath it is a specific model, named with a version and a date, chosen by whoever built the thing. That name has a retirement date attached to it, and the date is no secret: it is published in a table, months in advance, by the company that made the model.

Which raises the only question this article is really about. The date is public, the notice is generous, the replacement is named - and none of that helps if nobody in your business has ever opened the page. No vendor behaves badly in this story. What it is about is an obligation that quietly landed on you when you started using something you did not build.

What happens on the day a model is retired?

Requests to it stop being answered. Anthropic's page is quoted here because it sets the rule out most plainly; the other seven vendors in this article end in the same place by their own wording, and the comparison follows below.

Anthropic publishes four lifecycle states, and the last one reads: "Retired: The model is no longer available for use. Requests to retired models will fail." The state before it is the one that carries the warning: "Deprecated: The model is still functional but no longer recommended. Anthropic provides a recommended replacement and assigns a retirement date."

The notice policy, quoted whole because the qualifiers matter, reads: "Anthropic notifies customers with active deployments for models with upcoming retirements, providing at least 60 days' notice before model retirement for publicly released models."

Two months, in writing, with a named replacement. The published table shows the promise being met by the smallest possible margin: the model identified as claude-opus-4-1-20250805 was marked deprecated on 5 June 2026 and retired on 5 August 2026, which is sixty-one days against a sixty-day floor. An earlier one, claude-3-7-sonnet-20250219, was retired on 19 February 2026.

There is a smaller version of the same thing that catches people who did not change a model at all. Settings can be retired too. The same vendor's table marks three long-standing tuning options as deprecated, noting that one "Returns a 400 error when set to a non-default value on Claude 4.7 and later models...". A setting somebody adjusted two years ago to make replies less repetitive can turn into a refusal, on a model that is otherwise perfectly current.

Why does a published date fail as a warning?

Because of where the notice arrives, when there is one. Three of the vendors here promise to tell somebody, and all three describe that somebody the same way: as the holder of the technical account.

OpenAI: "When we announce a model deprecation, we notify customers who are actively using the model by email and document the deprecation on this page." Anthropic: "customers with active deployments". Microsoft's retirement notifications are described as going to subscription owners with active deployments. The others in the table make no such promise on the pages I read.

Every one of those descriptions is accurate and reasonable. Now put it beside how a small business actually gets an assistant. Somebody built it - an agency, a contractor, a person who has since moved on - and the technical account belongs to them, or to the automation platform hosting it, or to a shared address created during setup. This next part is reasoning rather than a documented vendor statement, and it should be read that way: nothing on any of those pages says the email reaches the business owner, and on a hosted platform the customer of record is the platform, not you.

So the sequence is fully documented, entirely above board, and still ends with nobody in your building knowing. This is a close relative of the automation failure nobody was told about, with one difference that makes it worse rather than better: here, the warning was generated, sent, and delivered. It simply landed somewhere that is not your inbox.

Why does the date depend on where you bought it?

There is no industry-wide schedule. There is not even one schedule per model. Here is what eight vendors publish on their own documentation pages, checked one by one.

Vendor	Forward schedule with dates?	Stated notice period
OpenAI	Yes	"At least 6 months" for generally available models; preview models "such as 2 weeks"
Anthropic	Yes, headed "Tentative retirement date"	"at least 60 days' notice ... for publicly released models"
AWS Bedrock	Yes	"at least 12 months" on the platform before end of life; "at least 6 months" in the legacy state
Mistral	Yes, on its separate models page	Six months for generally available models, one month for preview
Microsoft Azure	Yes, per version	Set at launch eighteen months out, with "no separate 'announcement.'"; "at least 30 days notice" before a preview model is forced up
Google, Gemini API	Yes, but "the earliest possible dates"	None stated for stable models; "at least 2 weeks" for preview
Google, Vertex	Yes, and dates "won't be moved to an earlier date"	Not stated as a number
Cohere	No forward schedule	None found on the page

That table is a claim about eight pages, read in September 2026, belonging to seven companies - Google appears twice, because its two platforms disagree with each other. Vendors not on it were not checked.

The row that changes the practical question is not in the table at all, because it is about the same model appearing twice. Anthropic states plainly that "Partner-operated platforms (Amazon Bedrock and Google Cloud) set their own retirement schedules, so a model's lifecycle status and dates can differ". And they do differ, substantially: the model retired by Anthropic on 5 August 2026 is listed by AWS with an end-of-life date of 8 January 2027 - a hundred and fifty-six days later. Amazon spells out which one governs: "Model lifecycle dates on this page are specific to Amazon Bedrock and may differ from dates published by model providers... For Amazon Bedrock usage, only the dates on this page apply."

So "check the vendor's table" is already the wrong instruction. The right one is "find out which company you actually buy this through, and read that company's table".

Which parts of your business now depend on something with a clock on it? And what would each cost on the day it stops? That is the first half of the process audit: what can be automated, in what order, and what each piece is worth, in writing, in three business days.

Some platforms replace the model for you, on purpose

Two of the largest platforms in that table have opposite policies about what happens if you do nothing, and both are documented in a single sentence each.

Microsoft upgrades you. Its documentation gives a worked example, and the date in it is 1 October 2026: "When gpt-4o version 2024-05-13 retires on 2026-10-01, the service automatically upgrades it to gpt-5.1 on the Standard SKU in each region where that version is currently available." Customers who have paid to reserve capacity are excluded from that, and the opt-out is a door that locks behind you: the setting named NoAutoUpgrade is described as "never auto-upgrade—deployment stops working at retirement". For preview models there is no choice at all - "There's no option to remain on a retiring preview model—all preview deployments are either upgraded or terminated."

AWS does the reverse, in five words: "Migration will not happen automatically." Its page continues: "On, or soon after the EOL date, the model is no longer available for use in all AWS Regions and requests made to this version will fail, unless there is a private arrangement between you and the provider for continued access."

Both policies are defensible. What matters for a business is that they produce completely different failure modes, and neither is visible from inside your own product. Under one, the day passes and the assistant keeps answering - in a slightly different voice. Under the other, the day passes and the assistant stops answering. If you cannot say which of those two describes your setup, that is the finding, and it takes one question to whoever built it to resolve.

The risk is a different answer, arriving on time

The instinct is to worry about downtime. The vendors' own migration guidance suggests the more likely outcome is subtler and harder to notice: the thing keeps working and starts saying something else.

Anthropic's migration guide is explicit that some differences are not failures at all: "The following items are not breaking changes; they describe behavior differences worth checking after you swap the model ID." Among them: "If your product depends on a certain style or verbosity of output, you may need to tune your prompts", and "As with any new model, prose style on long-form writing may shift." The hedge is theirs - may, not will.

Microsoft, which performs the swap automatically, gives its customers this advice in the same breath: "When you choose a target, evaluate candidate models against your own application, prompts, and representative data", and "Apply prompt engineering and fine-tuning as needed to match prior accuracy." Match prior accuracy. That is a vendor conceding that accuracy is not automatically preserved by an upgrade the vendor itself carries out.

Mistral names the same thing as a property of naming a model loosely - by a label that always points at the current version, rather than by a fixed version number: "using an alias may expose you to silent updates in model behavior and pricing."

Somebody described what this feels like on OpenAI's own community forum, on 14 June 2026: "For my use case, gpt-image-2 is not a drop-in replacement. I spent hours testing and iterating prompts, trying to recreate the old style. The results are technically impressive, but they look clearly different." A reply the same day opens "Join the club." and then goes on to argue that the replacement is the better model - which is the point. Better is not the same as interchangeable.

For a business, "clearly different" is not an aesthetic complaint. The assistant that had been trained by a year of corrections to answer a refund question carefully now answers it its own way, and the first person to notice is a customer. Which is a different chapter of the same subject as being liable when your automation is wrong: the answer that goes out under your name is yours, whichever version of whatever model produced it.

What did it look like when one sunset reached ordinary automations?

Most of this article is documentation. There is one case where a retirement travelled all the way from a model vendor to non-technical customers' running automations, and it is worth following in order, because it shows how much notice was given and how little that helped.

OpenAI announced the deprecation of an entire interface - the one many assistants were built on - and set the removal a year out: "On August 26th, 2025, we notified developers using the Assistants API of its deprecation and removal from the API one year later, on August 26, 2026." Three hundred and sixty-five days of notice. The date passed thirteen days before this was written.

Zapier, which had built several of its actions on that interface, published its own notice: "OpenAI is deprecating the Assistants API. Zapier has deprecated all ChatGPT (OpenAI) actions that use it. On August 26, 2026, Zaps using these actions will stop working. If your Zaps use any of the affected actions, review or update them before that date."

One of them had a direct replacement, and Zapier did the work: "Zapier will automatically migrate Zaps that use Conversation With Assistant (Legacy) to the new Conversation action". Then comes this:

Migrated Zaps are left turned off so you can review them first.

That is a defensible engineering decision - moving an automation to a new component without a human checking it would be worse. But look at the outcome from your side of it. The automation still exists, correctly migrated, and it is off; it stays off until somebody opens it, and nothing in that page promises anybody an email. The actions with no direct replacement simply stopped working on the day.

Nothing about that sequence involved a failure. Every party did what it said it would do, a year in advance, in public. The only step nobody owned was somebody in the business noticing.

What does your own tool say about it?

Very little, in most cases, and that is checkable rather than a matter of impression.

HubSpot's page for its custom AI workflow action explains that the action "lets you select from multiple supported LLM providers and models to generate outputs directly within a workflow", and says nothing about what happens when one of those models is retired. The n8n documentation for its OpenAI chat model node explains that "n8n dynamically loads models from OpenAI, and you'll only see the models available to your account", which means a retired model quietly stops appearing in a dropdown, with nothing said about a workflow that already names one. Zapier's own AI step documents an "Auto" setting that "uses the default model for your selected tier", so the model can change without anybody choosing a new one. Intercom's page about the engine behind its AI agent describes careful testing before changes - "A rigorous amount of testing happens before any changes are made to the AI engine architecture" - and never names the underlying model at all.

Searching the body text of those pages for "deprecated", "retire" and "notify" returns nothing on each - n8n's site menu has a link with the word in it, which is not the same as an answer. That is an absence in documentation, and not proof that no message is ever sent. But if you were planning to rely on your automation platform to tell you, the plan currently rests on something none of these four pages promises.

One vendor publishes no schedule at all

Absence deserves the same care as evidence, so here is one stated precisely.

Cohere uses the same vocabulary as the others - a model can be deprecated, and then shut down, its endpoint being the address other software calls to reach it: "Shutdown: The model and endpoint are no longer available for users. Requests to shutdown models and endpoints will fail." Its deprecations page is a history: it records what has already been retired, in reverse chronological order. Searching it for a forward-looking schedule, or for any commitment to a number of days or months of notice, returns one thing only - a definition of who counts as an existing user, "anyone who has used the model or endpoint within 90 days of the deprecation announcement".

That is one page, read on one day, and pages change. What it demonstrates is that "the vendor publishes a table of dates" is a property of some vendors rather than a property of the industry, and that the question "where is my supplier's table" sometimes has no answer.

A retirement is not an outage

It would be easy to leave the impression that these dates are disasters waiting in a calendar. Mostly they are not, and the fair version of the story has three parts.

The word "deprecated" causes more alarm than the event does. When a customer found models missing from a filtered list in one region, a Microsoft moderator answered: "Nothing was withdrawn from the region, and this isn't an outage; it's a model lifecycle transition", and confirmed the model "continues to be available for use by customers with existing deployments until the model is retired". Deprecated means "start planning", not "broken".

Some retirements are absorbed before they reach anybody. Azure's default setting upgrades ordinary deployments with no customer action at all, and Zapier migrated the action it could migrate. Where that happens the day passes and nothing visible occurs, which is exactly why the risk worth naming is the changed answer rather than the error page.

And a switch-off is not always absolute. OpenAI notes that "In some cases, developers may be able to provision dedicated capacity for continued access after a model's shutdown date", and AWS documents a paid extended-access period. Those are arrangements for large customers, and mentioning them is a matter of accuracy and not as advice.

Who in your business is watching the table?

That is the whole question, and it belongs to whoever owns the process, not to whoever understands the technology.

Every fact in this article was public before it mattered. The dates were published, the replacements were named, the notices went out, and several vendors gave between two months and a year of warning. Secrecy is not the failure mode here. A small business has no role whose job description includes reading a supplier's lifecycle page, and no reason to invent one until the first time it costs something.

The fix is proportionate to the size of the problem, and it is mostly a piece of paper. If you keep a register of what is automated, it needs one more column: what each AI step is running on, and where that is bought from. If you do not keep one, this is the second-best reason to start, after the first time somebody asks what your assistant is actually connected to. The same register is where the answer to what happens to customer data you paste into an AI tool belongs, and the two questions are usually answered by the same person in the same conversation.

What should you check in your own setup?

Five questions, in the order they are worth asking.

1. Is anything in your business answering customers or sorting information with AI? Include the invisible ones: a step inside an automation, a summarising action in your help desk, a categoriser on your inbox. These are rarely on anybody's list, because nobody thinks of them as software.
2. For each one, which model is named, and where is it bought? The second half matters as much as the first, because the same model retires on different days depending on the answer. If the setting says "auto" or "default", write that down too - it means the choice is being made for you.
3. Ask what happens on the retirement date under your particular arrangement. The two documented answers are opposite: replaced automatically, or stopped. Whoever built the thing can answer in one sentence.
4. Find out where the vendor's notice goes. Not whether one is sent - which address. If it is an account created during setup by a contractor, the notification exists and does not reach you.
5. Decide who re-reads the answers afterwards. A replaced model still answers. The check that matters is somebody putting your ten most common customer questions to it a week later and reading the replies as a customer would.

None of that prevents a retirement. It changes who finds out, and when, which is the only part of this you control.

When this stops being a settings question

For one assistant with one model behind it, this is a note in a calendar and half an hour of somebody's attention twice a year.

It stops being that when you cannot say how many places in your business now have an AI step in them, who chose the model in each, and what would change in the answers your customers receive if any of them were replaced tomorrow. Model lifecycles are the small half of that. A part of how your business speaks to its customers has no owner.

If you would rather have somebody find where that is true and work out what can be automated, in what order, and what each piece is worth, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.