OpenAI Assistants API Shuts Down Today: What to Do
The Assistants API is removed on 26 August 2026. Here is the object-by-object mapping to the Responses and Conversations APIs, and what breaks in a shipped app.
The OpenAI Assistants API shuts down today, 26 August 2026, exactly one year after the deprecation notice went out. If your app still creates Assistants, Threads or Runs, those calls stop working. The replacement is the Responses API paired with the Conversations API, and it is not a drop-in rename. The mental model changes from polling an asynchronous run to a direct request and response. Below is what OpenAI says breaks, what each old object maps to, and the smallest change that gets a shipped app running again.
What shut down, and when
OpenAI notified developers on 26 August 2025 that the Assistants API would be removed from the API one year later. That year is now up. The company lists the shutdown date as 2026-08-26 on its official deprecations page, with the Responses API and Conversations API named as the replacement.
The distinction that matters for anyone running live code: this is a removal, not another warning. Deprecation notices leave the endpoint serving traffic. A shutdown date does not. Model deprecations, by contrast, run on separate clocks, and the o3 snapshots have their own later shutdown dates, so an app can be hit by this one while its model choice stays perfectly valid.
The object-by-object mapping
OpenAI publishes a direct correspondence between the four Assistants primitives and their replacements. Reading it as a rename table is the fastest way to misjudge the work, so the third column is the part worth your attention.
Assistants API | Replacement | What actually changes |
|---|---|---|
Assistants | Prompts | Configuration (model, tools, instructions) becomes a versioned object you can update without redeploying, and it is reusable across Responses and Realtime. |
Threads | Conversations | A conversation is a stream of items rather than a list of messages, so tool calls and their outputs live in the same history your messages do. |
Runs | Responses | The biggest change. You send input items and get output items back. The tool loop is yours to manage explicitly instead of being driven by run status polling. |
Run steps | Items | Generalised objects. An item can be a message, a tool call, a tool output or several other types, which makes inspection uniform. |
The polling loop is the part that has to go
Most Assistants integrations share a shape: create a thread, add a message, create a run, then poll the run until its status leaves queued or in_progress, branching into tool submission when it reports requires_action. Every one of those steps disappears.
In the Responses model you make a request and get output items back. If one of those items is a tool call, you run the tool and send the result as an input item on the next request. The loop still exists, but it is a plain loop in your own code rather than a state machine you interrogate over the network. Teams migrating this usually find the new version shorter, because the polling, backoff and status branching all collapse.
There is no automatic thread migration
This is the detail that catches people. OpenAI does not provide a tool that converts existing Threads into Conversations. The documented approach is to create Prompts in the dashboard from your existing assistant configurations, then start routing new conversations through the Responses API.
If your product shows users their chat history, that history was living in Threads, and it does not come with you. Decide now whether you are exporting it into your own database, showing a cutoff date, or accepting the loss. Doing nothing means users notice before you do, which is the worst of the three.
If you are reading this after your app broke
The fastest sequence, in order:
Grep your codebase for the endpoint paths, not the SDK helper names. Wrapper libraries hide which API they call, and a single shared client can be the only thing still on Assistants.
Recreate each assistant as a Prompt holding the same model, instructions and tool definitions. This part is genuinely close to a rename.
Replace the create-run-and-poll block with a single Responses call, then add your own loop for tool calls.
Point new sessions at Conversations and make a deliberate call on old thread history.
Re-test anything that depended on run status. Timeout handling and retry logic written against queued and in_progress has nothing to check any more.
The full mapping and code samples are in OpenAI's Assistants to Responses migration guide, which is the source for the table above.
Why this one is worth learning from
A twelve month notice is generous by the standards of this industry, and plenty of teams still got surprised, because a deprecation notice read in August 2025 lands in an inbox, not in a calendar. The habit worth building is checking the vendor's deprecation page on a schedule rather than waiting for the announcement to reach you, which is the same discipline behind keeping up with AI news without drowning in it.
If the shutdown has forced a wider rethink, the neighbouring problems are covered separately: what to do when an AI model you depend on gets deprecated, how to move an app from one model to another without regressions, and, since the tool loop is now yours to own, how tool calling actually works in AI agents. Conversation state is its own design question, covered in how AI agents remember between sessions.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
