When a model leaves a chat dropdown, a user picks another one. When a pinned API snapshot goes, every prompt, eval suite and compliance document calibrated against its behaviour has to be revalidated. The frontier-model market has no semantic versioning, no LTS tier and no standard notice period. This piece separates the three OpenAI deprecations, explains what actually breaks, and gives a checklist for surviving the next one.
Three things happened at OpenAI in the last week, and most coverage has compressed them into one. They are not one.
On 26 August 2026, o3 disappeared from the ChatGPT model picker, ending a 90-day sunset announced on 28 May. That retirement notice explicitly left the API alone. A separate developer notice dated 11 June 2026 set removal of the o3-2025-04-16 and o3-pro-2025-06-10 snapshots from the API for 11 December 2026. And on the same day o3 left ChatGPT, the Assistants API shut down — announced a full year earlier, on 26 August 2025, with no automated tool to migrate Threads.
Ninety days. Six months. Twelve months. Three different notice periods, three different classes of user, one company, and no discernible principle connecting them. That is not a criticism of OpenAI. It is a description of an industry that has built process for none of this.
When a model leaves a chat interface, the user opens a dropdown and picks a different one. The output is a bit different. They adapt in an afternoon. This is an inconvenience.
When a pinned model snapshot leaves an API, the failure mode is categorically different, and it is worth being concrete about it for readers who have never shipped against one.
A snapshot like o3-2025-04-16 is a frozen artefact. Teams pin to it precisely because it does not change — that is the entire value proposition of version pinning. Over the following months, work accretes on top of that fixed behaviour. Prompts get tuned to its particular reasoning cadence, its tendency to over- or under-elaborate, the specific phrasing that reliably gets structured output. Evaluation suites get calibrated against its outputs, so that a regression test means something. Retrieval pipelines get tuned to its context handling. In regulated settings, the model version gets written into documentation as part of a control — a named component of a validated system, referenced in an audit trail.
The replacement is not that model with a bug fix. It is a different system with different failure modes, different verbosity, different refusal boundaries and different latency. Every one of those accreted artefacts has to be revalidated, and in the regulated case the documentation naming the old version has to be revised and the control re-evidenced. None of that is hard. All of it is slow, and none of it can start until you know what you are migrating to.
Pinning is a promise of stability that expires on a date the vendor chooses. That is a strange thing for infrastructure to be, and the market has not noticed it is strange.
The notice periods run in roughly the right direction — more time for the users with more to migrate — which is more disciplined than the framing they just killed it implies. But the shape is still wrong in an instructive way.
The Assistants API got the longest runway of the three: twelve months, announced 26 August 2025 for a 26 August 2026 shutdown. And it is still the case that generated the most migration pain, because notice period and migration cost are different variables and only one of them was managed. OpenAI's own migration guide points teams to the Responses API for model calls and tools, plus the Conversations API for persisting chat history. Vector stores and files carry over to the Responses API's file search tool. But Thread and Assistant objects do not migrate automatically — teams had to iterate their existing Threads, convert message types into the Conversations API item format, and recreate them, before the cutoff. After it, calls to the v1/assistants, v1/threads and v1/threads/runs endpoints simply stop.
So the useful lesson is not that twelve months was too short. It is that a long notice period without migration tooling still lands the full cost on the customer, and the customers carrying that cost are the ones with the most state to move and the slowest change-control process to move it through. Notice is cheap for a vendor to give. Tooling is not. The market currently prices only the first one.
Search for a cross-vendor deprecation standard for frontier models and you will not find one — at least, none was identified in the reporting behind this piece, and the absence is worth stating carefully rather than declared as fact. There appears to be no semantic-versioning convention that would tell you whether a model change is breaking. No long-term-support tier you can pay for. No minimum notice period, contractual or conventional. No standard deprecation feed format. No agreed definition of what counts as a compatible successor.
Every other infrastructure market that enterprises depend on settled these questions, usually after a period that looked like this one. Linux distributions have LTS releases with published multi-year support windows. Major databases publish end-of-life calendars years out. Cloud providers commit contractually to deprecation notice periods and, in many cases, to migration assistance. Java has an LTS cadence precisely because enterprises told vendors that shipping onto a moving target was unacceptable.
None of that emerged from vendor generosity. It emerged from procurement leverage — buyers large enough to make support terms a condition of purchase. The frontier-model market has not reached that point, partly because it is young and partly because release cadence is still fast enough that customers are more focused on getting the newest thing than on keeping the old one. Twelve new models shipped across seven providers in August 2026 alone, by aggregator counts. When the frontier moves that fast, staying still feels like the greater risk.
Retiring low-usage models is legitimate and normal. Serving every historical checkpoint forever is neither free nor sensible — it consumes capacity that could serve better models, and it requires maintaining inference paths for architectures the vendor has moved past. Nobody is entitled to indefinite support for a two-year-old snapshot at commodity prices.
And OpenAI did the procedurally right things here. It gave notice. It published dates. It separated the consumer and API timelines rather than collapsing them into a single retirement, which is precisely the distinction this piece is arguing matters. It maintains a public deprecations page. The Assistants API got a year and a written migration guide. That is a more considered process than the loudest reactions suggest.
It should also be said in one line and left there: every major lab does this. The argument is about a missing market norm, not about a company behaving badly. If a competitor had made these decisions, the analysis would be identical.
The next deprecation is already scheduled somewhere. Five things reduce what it costs you:
The 11 December date is three and a half months away and public. The teams that will be fine are the ones treating it as a scheduled maintenance window rather than a surprise — and the ones who are surprised will mostly be surprised by their own documentation, not by OpenAI.
If you pinned an explicit snapshot, API calls to that snapshot begin failing on the removal date — for o3-2025-04-16 and o3-pro-2025-06-10, that is 11 December 2026. If you pointed at a floating model alias, you will typically be routed to a successor automatically, which sounds better but means your application's behaviour changes without a deployment on your side. Neither is free. The first gives you a dated failure you can plan for; the second gives you an undated behavioural drift you may not detect.
DrafterDaily covers what AI actually costs to depend on — deprecation, governance, procurement. One clear read a day.
Get the daily briefClaude Fable 5.1 costs exactly what Fable 5 cost per token. The 25-to-45% saving Anthropic advertises comes from one repriced line item — cached input, now billed at 2.5% of list instead of 10%. That is a discount you only collect if you keep the agent running.
Anthropic was not breached. The malware was already on the customer's machine, and it took a session cookie rather than a password — which is why two-factor authentication did nothing and why server-side revocation is the only lever the vendor has.
OpenAI's incident report on the Hugging Face breach leads on a security failure. The remarkable part is a verbatim chain-of-thought in which a model identifies its action as unauthorised and proceeds anyway — and an escape route that was a package manager, not a superintelligence.