- Every model behind every AI tool you use has a retirement date, and the vendors publish them. Almost nobody selling you a tool mentions this.
- OpenAI's published policy is at least six months notice for generally available models, three months for specialised variants, and as little as two weeks for previews.
- Anthropic commits to at least 60 days notice before retiring a publicly released model, and its documentation states plainly that requests to a retired model will fail.
- Google's published shutdown dates are the earliest possible dates rather than the actual ones, with the exact date communicated later.
- The risk for a small business is rarely an outage. It is that the replacement model writes differently, and your product descriptions or support replies quietly change tone on a Tuesday.
- The defence costs an afternoon: keep your prompts in a file you own, keep ten real inputs with their approved outputs, and know which of your tools call which vendor.
A seller sets up an assistant to draft product descriptions in March. By November the descriptions read differently. Slightly longer, a bit more enthusiastic, with a habit of opening on a rhetorical question that was not there before. Nothing broke. No email arrived. The prompt is unchanged and the tool looks identical.
What changed is underneath. The model that tool calls was retired or quietly upgraded, and nobody involved in that decision knew the seller existed.
What does deprecation actually mean here?
It means the vendor has announced the end of a model and set a date after which calls to it stop working. The vocabulary is consistent across the major providers and worth learning, because it is what the notices you eventually receive will use.
Anthropic's documentation defines four states in its model deprecations page. Active means fully supported and recommended. Legacy means no more updates and possible deprecation later. Deprecated means still working but no longer recommended, with a replacement named and a retirement date assigned. Retired means requests fail. It also warns that deprecated models are likely to be less reliable than active ones, which is the sentence to notice: degradation can start before the shutdown.
OpenAI draws the line in two steps on its deprecations page. Announcing a deprecation makes the model deprecated immediately, while it stays callable, and a separate shutdown date is when access ends. Google uses the same split on the Gemini deprecations page, defining deprecation as the announcement that support is withdrawn and shutdown as the endpoint being turned off.
One detail on the Google page deserves more attention than it gets. The shutdown dates published in the table are the earliest possible dates a model might be retired, with the exact date communicated to users later. That is a floor, not a schedule, and reading it as a schedule is how a plan built on those dates goes wrong in both directions.
How much warning do you actually get?
Between two weeks and six months, depending on the vendor and the tier of model, and the differences are large enough to matter when you are choosing what to build a workflow on.
| Vendor | Stated minimum notice | How you are told | What the published dates mean |
|---|---|---|---|
| OpenAI, generally available models | At least 6 months | Deprecations page, notice on announcement | Fixed shutdown dates listed per model |
| OpenAI, specialised variants | At least 3 months | Same page, listed by family | Covers chat, Codex and deep research variants |
| OpenAI, preview models | As little as 2 weeks | Same page | Explicitly much shorter notice |
| Anthropic, public models | At least 60 days | Email to customers with active deployments, plus docs | Retirement dates listed, partner clouds differ |
| Google, Gemini API | Advance notice, amount not fixed | Deprecations page and later communication | Listed dates are the earliest possible retirement |
Two things about that table are the actual news for a small seller. The notice goes to the account holder, which is the vendor of your tool, not you. And on partner clouds the schedule is different again: Anthropic's page states that Amazon Bedrock and Google Cloud set their own retirement dates, so the same model can be active in one place and retired in another.
So if you use an AI writing assistant, a support bot or a listing generator built by somebody else, you are two removes from the notice. Your supplier gets the email. Whether they tell you, and whether they migrate carefully or in a hurry the week before the deadline, is entirely their decision.
What is actually on the shutdown lists right now?
Reading the current tables is the fastest way to understand the pace, and it is more sobering than the policy language suggests. OpenAI's page lists shutdowns clustered on a handful of dates: legacy GPT models including gpt-3.5-turbo, gpt-4, gpt-4-turbo, o1, o3-mini and o4-mini on 23 October 2026, GPT-5 and o3 snapshots on 11 December 2026, and the legacy audio and realtime families in January 2027. Notably the same table also lists product surfaces, with a reusable prompts API, an evaluations platform and an agent builder scheduled for 30 November 2026.
Google's table covers the same ground for its own lineup, with gemini-2.0-flash and gemini-2.0-flash-lite reaching shutdown on 1 June 2026 and named successors alongside each row, plus an embedding model and image and video generation models on their own dates. Anthropic's table is structured differently, listing every model with a state and a tentative retirement date, and its history section records that several 2025 era models were deprecated and then retired roughly two months later.
Three patterns fall out of reading all three. Embedding models get retired like any other model, which breaks stored vectors rather than prompts and is a genuinely harder migration because the old and new numbers are not comparable. Image and video models are on the lists too, so a shop generating catalogue imagery has the same exposure as one generating text. And the cheapest, most widely used models are not spared: high volume workhorses appear on the shutdown tables next to the flagships.
Why does this hit a shop rather than an engineer?
Because the failure mode is not an error message. An engineer whose API call starts returning a 400 finds out in minutes and fixes it. A seller whose descriptions changed register finds out from a customer, or from a slow decline in conversion, or never.
Think about where a model sits in an ordinary shop. It writes product copy. It drafts replies to customers. It categorises incoming messages. It generates the alt text on your images. It summarises reviews. Every one of those is a task where the output is judged by taste rather than by a test, which means a behaviour change passes straight through with nothing to catch it.
The specific things that shift on a model change, in rough order of how often they surprise people: length, formatting habits such as headings and bullets, how eagerly the model makes claims about a product, how it handles instructions it considers borderline, and its default register in languages other than English. That last one is the sharpest, because a small shift in formality can read as rude in one market and stiff in another, and it is the change least likely to be noticed by a founder reviewing English output.
There is a second, quieter version of this that has no deprecation notice at all. If your tool calls a floating alias that always points at the vendor's newest release, your outputs change whenever the vendor ships, with no announcement, no date and no migration window. Pinning trades that for a deadline you can see coming.
What should a small business actually do?
Four things, and none of them require a developer.
Keep your prompts somewhere you own. A text file, a document, a note. If your prompts live only inside a tool's settings screen, changing tools means rewriting them from memory, which is the single largest hidden cost of switching. This is the cheapest item on the list and the one most often skipped.
Build a ten example test set. Pick ten real inputs from your actual business, a difficult product, an awkward customer message, something in your second language, and save the output you were happy with alongside each. That file is your regression test. When anything changes, run the ten and read them. It takes fifteen minutes and it converts an invisible drift into something you can see.
Write down which tools call which vendor. Most sellers cannot answer this, and it is the question that turns a vendor announcement into an action. Three columns: the tool, the vendor behind it, whether you can choose the model. The third column is the one that tells you whether a change is yours to manage or your supplier's.
Ask your suppliers the question in writing. What model does this use, can I pin it, and what is your notice period to me when it changes. A supplier who cannot answer is telling you something useful. This belongs alongside the other questions in our piece on the due diligence questions worth asking before you buy an AI tool, which most security questionnaires miss entirely.
The drill, in the order that works
When a notice reaches you, whether from a vendor or a supplier, the sequence below keeps the migration to a day rather than a fortnight.
Start by confirming what is actually affected, which is usually less than the announcement implies. Vendors deprecate families, and your workflow may touch one member of it. If you have the tool to vendor list, this is a two minute check rather than an audit.
Run your ten examples on the current setup and save the outputs with the date. This is the before picture, and it is worthless if you take it after switching. Then run the same ten on the proposed replacement and read them side by side, not as a scoring exercise but as an editor: what would you have to fix in each.
Rewrite the prompts against the new model rather than assuming they carry. Fix the things your comparison surfaced, and pay particular attention to instructions about length and format, which are the first to change behaviour across a version boundary.
Switch one workflow rather than all of them, and pick the one where a mistake is cheapest and most visible. Internal drafting before customer replies, always. Watch it for a week before moving the rest.
Finally, write down what you changed and why, in the same file as the prompts. The next deprecation is not a hypothetical, and a note explaining why a particular sentence exists in the prompt saves an hour the next time somebody wonders whether it can be deleted.
The whole drill assumes you did the preparation. Without the examples file, step two is impossible and every judgement about the replacement becomes a matter of impression, which is how a quiet degradation gets approved.
Is switching vendors as hard as it sounds?
Less hard than it was, and harder than the marketing suggests. The mechanical part has largely converged: most providers speak a similar request format, so the plumbing is usually a base URL and a key. What does not port is everything you tuned by hand.
Prompts carry across but do not behave identically. Instructions that one model follows reliably need restating for another, and the phrasing that worked as a workaround for one model's habit becomes noise on a model that never had the habit. Budget for a rewrite pass rather than a copy and paste, and use your ten examples to decide when you are finished.
Costs move too, and not always in the direction you expect, because the same task can take a different number of tokens on a different model even at a lower headline price. We worked through how that arithmetic actually behaves in the piece on what a token costs once you account for the whole request, and the short version is that comparing per million prices without measuring your own workload is how a migration ends up more expensive.
The part that genuinely does not transfer is anything the vendor stored on your behalf: assistants, saved prompt objects, uploaded files, conversation history held server side. OpenAI's own page lists product surfaces alongside models in its shutdown table, including a reusable prompts API and an agent building tool. Anything living only in a vendor's account is a dependency with the same expiry risk as the model, and it is worth knowing which of your work sits there.
Should I pin a model version or take the latest?
Pin, if the tool lets you and the output is customer facing. A pinned version gives you stable behaviour and a deadline you can see on a page. A floating alias gives you no deadline and no notice, which sounds easier until the week your product copy changes character without explanation. Take the latest for internal drafting where nobody but you reads the result.
How do I know if my tool already changed?
Compare old output to new on the same input, which is exactly what the ten example file is for. Without it you are relying on memory, and memory is unreliable about writing style. Failing that, look at anything you generated in bulk months apart and read the two batches side by side.
Does this affect open weight models too?
Differently, and it is the strongest argument for them. A model you can download does not get retired out from under you, because a copy of the weights keeps working as long as you can run it. What you lose instead is the hosted provider's convenience, and any hosting service can still stop offering a given model on its own schedule.
The thing worth internalising
Software you buy usually keeps working the way it worked. AI tools are the exception: the thing doing the work is replaced periodically by the supplier's supplier, on a schedule published in documentation you have never read, and the replacement is better on average and different in particular.
That is not a reason to avoid them. It is a reason to hold the parts that are yours. Your prompts, your examples, your standards for what an acceptable output looks like: those survive every deprecation, and they are what turns a migration from a crisis into an afternoon. Everything held only inside somebody else's account is on somebody else's calendar.
The same logic runs through how we think about the rest of a shop's stack, which is why our pricing page is built around usage you can see rather than a lock in, and why the code a merchant generates with us is theirs to move. A dependency you can inspect is a dependency you can plan around.
Set a calendar reminder for one hour, twice a year. Read your vendors' deprecation pages, run your ten examples, and update the tool to vendor list. That is the whole practice, and it is the difference between finding out from documentation and finding out from a customer.