On 26 August 2026, OpenAI was scheduled to remove the Assistants API from service, twelve months to the day after it notified developers of the deprecation. We reported the deadline the day before it fell. It has now fallen, and OpenAI’s own record has caught up with it.

When we first checked, on 27 August 2026, OpenAI’s deprecations page still carried the sentence it had carried for a year: “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.” The entry was listed with a shutdown date. It was not marked as removed. Every source asserting that the endpoints were already returning errors was a migration-guide blog, a vendor content-marketing post or a roundup rewrite — not OpenAI, and not a named outlet reporting a call it had made itself. We held the story rather than print an existence claim resting on that tier of sourcing.

On a follow-up check, the entry has moved. OpenAI’s deprecations page now lists the Assistants API under “Past deprecations”, with the wording changed from a forward-looking notice to: “The Assistants API was officially sunset on August 26, 2026.” That is the vendor’s own record stating, in the past tense, that the removal happened. It is the specific piece of evidence our original reporting said would settle the question, and it now exists.

Why it matters

The gap between a scheduled removal and a confirmed one is not pedantry — it is the difference between a date you plan around and a date you have verified. Teams that migrated can now decommission fallback code against the vendor’s own record rather than a calendar assumption. Teams that did not migrate no longer have room to treat the date as aspirational: OpenAI’s own page states the API is gone, not going.

The calendar is the part that was never in question

What the deprecations page has established throughout is how much else is scheduled for withdrawal over the next five months. Read directly rather than through a summary, the list runs: legacy GPT model snapshots on 23 October 2026; reusable prompts, the Evals platform and Agent Builder, all on 30 November 2026; GPT Image model deprecations on 1 December 2026; GPT-5 and o3 model snapshots on 11 December 2026; and legacy audio, realtime and transcription models on 20 January 2027.

That is eight separate withdrawal events in twenty-one weeks. Three of them — reusable prompts, the Evals platform and Agent Builder — are platform surfaces rather than models. A team that adopted OpenAI’s own tooling for prompt management, evaluation and agent construction is being asked to move all three inside the same fortnight, and those are precisely the components least likely to have a documented migration path, because they were the newest.

The model retirements are the more predictable half of the list. Pinning a model snapshot is the standard defence against silent behavioural change, and 11 December 2026 is the date on which pinned GPT-5 and o3 snapshots stop being a defence and become a liability instead. Anyone who pinned specifically to avoid surprises has a dated appointment with one.

The original sunset announcement is worth reading for its reasoning as much as its date. OpenAI’s stated case was that the Responses API “has already overtaken Chat Completions in token activity” and is “our recommended path to integrate with the OpenAI API today, and for the future”. That is an argument about where the platform is going, not about whether the Assistants API worked, and it is the argument every item on the calendar above rests on.

The phrase “no automated migration” is true of OpenAI and not of everyone

The line that travelled furthest ahead of this deadline was that no automated migration exists anywhere. Applied to OpenAI itself, it holds. The recommended path is the Responses API for model calls plus the Conversations API for persisting history, and OpenAI provides no tool that moves Threads across.

Applied to the wider ecosystem it is too broad, and we should say so plainly because our own coverage last week carried the same framing. Zapier’s notice states that it automatically migrates Zaps using the Conversation With Assistant (Legacy) action to its new Conversation action built on the Responses API, and that “Migrated Zaps are left turned off so you can review them first”. What Zapier does not move is everything else — Create Assistant, Find Assistant, Upload File and the assistant searches — which it says “will not be automatically migrated”.

The accurate statement is therefore narrower and considerably more useful than the one in circulation. The vendor provides no migration tooling. Some platforms built on the vendor provide partial tooling, covering their single most common action. And the objects most likely to hold state anybody cares about sit in the unmigrated group, which is the general shape of this kind of transition: the easy path is automated and the data is not.

What this means for buyers

If you have not migrated, the vendor’s own page now confirms you are calling a removed API. That is no longer a probability to plan around — verify against your own account with a single call, because a confirmed removal on OpenAI’s general record and the specific behaviour on your credentials are still two different checks.

If you have migrated, you can now retire the fallback path against a primary-source confirmation rather than a calendar date. Keep the log line, though: OpenAI has not published an error code or a description of what a call to the old endpoint now returns, so if anything depends on the exact failure mode rather than the fact of removal, that detail still is not public.

Treat the coming five months as a single platform-churn problem rather than eight unrelated tickets. If you are being made to move regardless, that is the moment to ask whether your model and platform choices should be remade rather than merely ported. The migration cost is being imposed on you either way; the only question within your control is whether you spend it moving sideways or moving somewhere you actually chose.

What would change our reading

The central question is settled: OpenAI’s own record now states the removal happened. What remains open is narrower. First, the exact failure mode — whether calls to the old endpoints return a specific error code, whether there was any tapering window, or whether it was an instantaneous cutover. OpenAI has not published that detail and we have not independently triggered it against a live account.

Second, scale. The figure we want is a first-party count: how many Assistants and Threads objects existed at the deadline, and what became of the conversation history inside them. OpenAI has not published such a number and no outlet has obtained one. Until somebody does, the practical size of this shutdown is unknown rather than small, regardless of how the migration-guide volume online might suggest otherwise.

Third, we are watching whether any of the eight forthcoming withdrawals on the same page follow a similar pattern — a notice that lags its own effective date before the record catches up. If that turns out to be routine rather than a one-off, it is worth building into how quickly we check vendor deprecation pages after a stated deadline, rather than trusting the first read.

Sources

  • OpenAI, API deprecations page, showing the Assistants API entry moved to “Past deprecations” with past-tense sunset wording, and the full forward schedule — developers.openai.com
  • OpenAI, official Assistants API beta deprecation announcement in the developer community, with the original sunset date and stated rationale — community.openai.com
  • OpenAI, service status page, checked 27 August 2026, carrying no incident or notice relating to Assistants or Threads — status.openai.com
  • Zapier, help centre notice on the ChatGPT (OpenAI) Assistants API deprecation, listing affected actions and what it does and does not migrate automatically — help.zapier.com