OpenAI Assistants API is permanently removed on 26 August 2026: here's what you need to do

On 26 August 2025, OpenAI notified developers that the Assistants API is going away. On 26 August 2026, every endpoint under /v1/assistants and /v1/threads stops responding. There is no extension. If your code, product, or automation still calls those endpoints on that date, it will break.

This is not a model ID swap. The entire object model is changing, and you need to plan for it now.

What the Assistants API was, and why it’s being replaced

OpenAI launched the Assistants API at DevDay in November 2023 alongside GPT-4 Turbo. The pitch was compelling: build a stateful AI assistant without managing any of the conversation plumbing yourself. OpenAI handled threads, context, and tool execution on its side. Developers just called the API.

The catch, in hindsight, is that the Assistants API was always in beta and never matured out of it. It was built around a specific mental model that turned out to be harder to extend than OpenAI wanted. When the Responses API arrived in March 2025, bringing simpler primitives, built-in tools, and better economics, the direction became clear. The Assistants API’s days were numbered.

The Responses API is simpler in design: you send input items and get output items back. That simplicity also unlocks things the Assistants API never will, including Computer Use, MCP server connections, and deep research tools. Cache utilisation is reported to be 40 to 80 per cent better, which translates directly to lower bills.

The object model is changing completely

This is the part worth sitting with before you start migrating. It is not enough to swap the endpoint URLs. The concepts themselves are being renamed and restructured:

Assistants API	Responses API equivalent
Assistant	Prompt (dashboard only)
Thread	Conversation
Run	Response
Run Step	Item

The most significant shift is what happens to Assistants. There is no API-level replacement for programmatic assistant creation. If your code creates Assistants on the fly, that logic needs to move to the OpenAI dashboard as a saved Prompt, or you need to rethink the approach entirely.

Threads become Conversations, but the way you manage state between turns has also changed. With the Responses API you have three options: re-send the full conversation history with each request; chain responses using previous_response_id; or attach a Conversation object and let OpenAI store the items. The first two options re-bill earlier turns as input tokens every time, which is worth factoring into your cost modelling before you choose an approach.

File search has also changed. The Assistants API allowed querying across both assistant-level and thread-level vector stores automatically. In the Responses API, you configure vector_store_ids explicitly and tune the retrieval behaviour yourself.

Who is affected beyond custom code

The blast radius is wider than teams who wrote directly against the API. Any tool or integration platform that touched /v1/assistants or /v1/threads is in scope.

Zapier has already deprecated all ChatGPT steps that use the Assistants API. On 26 August 2026, any Zap using those steps will stop working. There is no automatic migration; affected Zaps need to be rebuilt manually using the new “Conversation (Responses API)” action. If you manage Zaps for clients or colleagues who built assistants through Zapier’s ChatGPT integration, they need to know about this.

Azure OpenAI users are also affected. The Azure OpenAI Assistants API carries the same 26 August 2026 retirement date, though Azure customers who need more time have a path to February 2027 by migrating to the Microsoft Foundry Agents service, which is built on the Responses API.

What this means for how you manage conversations

One of the original selling points of the Assistants API was that OpenAI managed conversation state for you. Threads persisted. You did not have to think about it.

That convenience is going away. The Responses API gives you more control, but it puts more work back on your side. You are now responsible for deciding how conversation history is passed between turns, what gets stored, and what gets billed. For simple use cases this is not a big burden. For complex, long-running agent workflows, it requires deliberate design.

There is also no automated tool to migrate existing Threads to Conversations. Whatever state lives in your Threads today, you will need a plan for it.

What to do now

OpenAI’s own migration guide is the right place to start. The broad steps are:

1. Audit everything that calls /v1/assistants or /v1/threads, including third-party tools and no-code integrations.
2. Map your Assistants to dashboard Prompts.
3. Decide how you will handle conversation state in the Responses API (re-send history, chain with previous_response_id, or use Conversation objects).
4. Reconfigure file search with explicit vector_store_ids.
5. Test thoroughly. The new API behaves differently, and token billing under the chaining approach in particular can produce surprises.

You have until 26 August 2026, which sounds comfortable. But if you have a large production deployment, or if you manage integrations for clients who may not know they are affected, the planning needs to start well before the deadline. OpenAI has stated there is no extension, and given the pace at which they have been retiring APIs and models in 2026, there is no reason to doubt that.

The Responses API is genuinely better. More capable, cheaper to run, and aligned with where OpenAI is taking its platform. The migration is real work, but it leads somewhere worth going.