The AI inside your software has a shutdown date. The dangerous day isn't the one it stops working.
Sixteen days from now, on 26 August, OpenAI switches off its Assistants API. If you've never heard of it, that's rather the point — for a couple of years it was one of the standard ways to build an AI assistant into a piece of software, which means it's plumbing underneath products whose customers have no idea it exists. The shutdown was announced twelve months ahead, in a documentation table, to developers. Nobody emailed the businesses paying for the software sitting on top of it.
That date isn't the story. The pattern behind it is, and it's one almost nobody buying business software has been told about: the AI inside the tools you pay for is not a feature. It's a dependency on somebody else's model, and that model has a published expiry date.
The dates are public. Have a look at them.
You can read both of the big labs' retirement schedules right now without an account. They're not hidden — they're just written for developers, in the tone of a train timetable, which is why they've stayed invisible to everyone else.
- 26 August 2026 — OpenAI's Assistants API shuts down, replaced by the Responses and Conversations APIs. Announced exactly a year earlier, to the day.
- 24 September 2026 — the Videos API and the Sora 2 models go, with no listed replacement.
- 23 October 2026 — GPT-4, GPT-4 Turbo, GPT-3.5 Turbo and the o1 series retire together.
- 11 December 2026 — the GPT-5 series retires. That model was released in August 2025. Sixteen months, start to finish.
- Already gone on Anthropic's side — Claude Sonnet 4 and Opus 4 retired on 15 June, and Opus 4.1 was switched off last Wednesday, 5 August, having been announced in June.
Read that list as a whole and the shape of it is unmistakable. This isn't a legacy clear-out of ancient stuff nobody uses. A frontier model released in the second half of 2025 is being retired in the second half of 2026. The cycle is roughly a year — closer to eighteen months if you're lucky — and it applies to the good ones, the ones your software was probably built on precisely because they were the best available the month somebody wrote the code.
The failure mode isn't the one you're bracing for
Here's where most write-ups of this go wrong. They treat it as an outage risk: the model dies, the feature breaks, someone scrambles. And yes, that happens — requests to a retired model just fail — but it's the version of this problem you don't need to worry about, because it's loud. A broken feature generates support tickets within the hour. It has a cause and a date and somebody fixes it by Thursday.
The one worth your attention is the quiet one. Long before a model is switched off, your vendor moves you onto its replacement. They have to — that's the responsible thing to do, and they'd be negligent not to. So one Tuesday, a line of configuration changes. The prompt still runs. Nothing errors. Every screen looks identical. And the AI that reads your enquiries and drafts your replies is now a different model with a different personality, and it writes slightly differently than the one your team spent four months learning to trust.
Usually the replacement is better, because that's why it exists. But better on a benchmark and better at your job are different measurements. If the previous model had learned — via your prompt, your documents, your corrections — to write quotes the way your customers expect them, "better" arrives as a change you have to absorb, not a gift. And you'll absorb it without ever being told there was a change.
Why they do it, which is duller than the conspiracy
It's not planned obsolescence and there's no upsell hiding in it. Anthropic states the reason plainly in its own deprecation docs: it retires models to free up capacity for new ones. These things run on physical hardware in finite quantity, and keeping a two-year-old model warm means not running the new one. The company also lists the downsides of doing it — that researchers lose access, that people who liked a specific model have to move — and has committed to preserving the weights of retired models rather than deleting them. Reading a vendor document that argues against its own decision is unusual enough to be worth noting.
Even the dials expire, incidentally. On Claude Opus 4.7 and later, the old temperature and top_p settings now return an error if you set them — parameters that were standard practice a year ago are gone, on the grounds that you should just describe what you want instead. That's the whole industry in miniature: the ground moves, including the bits that felt like permanent furniture.
The labs publishing shutdown dates are the safe part
This is the bit I'd most want a business owner to take away, because it inverts the obvious reaction. Your instinct on reading that list of dates is to be wary of the big labs. It should be the reverse. OpenAI and Anthropic both publish their retirement tables in public, with dates. Anthropic commits to at least sixty days' notice before a model goes, and publishes a "not sooner than" floor for every model currently live — so you can look up today the earliest date a model you depend on could possibly be retired. That's a genuinely high standard, and it's more than you get from most suppliers of anything.
The uncertainty doesn't live at the lab. It lives in the layer between the lab and you — the software vendor who picked a model, wired it in, and told you their product has AI. They received the sixty days' notice. The question is what they did with it, and whether any of it reached you.
What actually survives a model swap
There's a practical line running through all of this, and it's about which of your assets are durable and which quietly aren't.
A prompt tuned to one model's habits is disposable. All the fiddling that got a particular version to stop being verbose, or to format a quote just so, is tied to a thing with a shutdown date — and when the model changes, most of that work is void without anybody telling you it's void. It felt like building. It was really renting.
What survives is written-down knowledge that belongs to you. Your price list. Your service descriptions. The answers to the questions customers actually ask. The rules about what you don't quote on. Those are true regardless of which model reads them, and a new model reads them just as well as the old one — better, usually. It's the difference between training a staff member by having them shadow you for a year, and writing the handbook. One of those transfers when the staff member leaves.
If the only place your business knowledge exists is inside a prompt tuned to a model with an expiry date, you don't own it. You're leasing it, from a landlord who publishes the eviction date in a table you've never read.
Five questions and a folder
None of this needs a project. It's four questions to a vendor and one document you keep.
- Ask which model is behind the AI feature you're paying for. You're not going to audit the answer — you're finding out whether they can give you one at all. "We use AI" as a complete answer to that question tells you plenty.
- Ask what happens when it retires, and whether you'll be told. A vendor who has thought about it will say something specific. A vendor who hasn't will be hearing the question for the first time, which is itself the answer.
- Keep your own copy of everything you've taught it — the price list, the service docs, the FAQs. If that knowledge only lives inside somebody's product, you're one model change or one contract ending away from rebuilding it from memory.
- Keep a golden set. Five real enquiries you've received, and next to each, the AI answer you were happy with, with the date on it. That's the folder. It takes ten minutes once.
- Re-run the five whenever something feels off, and compare against what's in the file. This isn't measuring whether the AI is good — it's catching the day it changed. Without a fixed reference you'll never know if the drafts got worse or you just got fussier, and memory is no use here at all.
That last one is the only real defence against the quiet failure mode, and it works precisely because it doesn't rely on anyone telling you anything.
Where we land on it
We're downstream of all this too, and it'd be dishonest to write a thousand words on vendor risk while implying we sit outside it. We don't set retirement dates, we don't get told earlier than anyone else, and the AI in Dispatch runs on models with published end dates like everybody's does. What we did decide is where the knowledge lives: you upload your own pricing and service documents, and the agent reads from those. That's your file, in your words, and it outlives whatever is reading it. The reply still waits for you to send it, which means a model that starts writing differently gets caught by a human before it reaches a customer — not by a dashboard.
Ask us the four questions too. Any vendor who flinches at them is telling you something.
The broader point is worth sitting with. Software you bought used to be a thing you had a version of, and versions changed when you agreed to change them. A tool with AI in it now contains a component with a published expiry date, replaced on a schedule set three companies away from you, and the replacement arrives silently because there's no good way to announce "the writing might feel a bit different from Tuesday." That's not a scandal and it's not a reason to avoid the tools — the cycle is what makes them keep getting better. But it's a fact about what you're buying, it's published in public, and up to now essentially nobody has been reading it.
Software for service businesses — built by an operator.
Job management, books, and AI agents that actually know your business.