OpenAI has officially set August 26, 2026 as the shutdown date for its Assistants API. If your software uses this API, you will need to migrate your code before that deadline to avoid broken features. The notice first appeared in the OpenAI API deprecations list on August 20, 2025, though OpenAI has not shared the exact hour of the final cutoff.
How the new structure works
To replace the old system, OpenAI points developers to the Responses API and Conversations API. The official Assistants migration guide details how the old pieces translate:
- Assistants become prompts.
- Threads turn into
Conversations. - Runs become
Responses. - Run steps turn into general items.
A response can use direct input items or a conversation object. This shift adds work to your backend. Your own application code must now handle orchestration, including history pruning, request retries, and tool-call loops.
Two traps to watch out for
First, OpenAI provides no automated tool to convert old Threads into new Conversations. You have to do this yourself. The guide suggests routing new chats through the new API first, then copying older conversation history only when needed.
Second, the prompt migration has its own deadline. The guide mentions prompt objects, but OpenAI warns that reusable prompt objects are also being deprecated. You should check that timeline before you finalize your architecture.
What the documentation does not prove
OpenAI documents confirm the shutdown date and new structure, but they do not guarantee matching speed or pricing. Nobody outside the company has verified latency, token costs, or output quality between the two systems. The docs also do not establish a universal live outage across all accounts or regions.
How to test your migration
Start your migration early. Do not wait for a last-minute scramble.
Begin by listing every assistant, thread, run, custom tool, and file path in your codebase. Next, build one test flow using the Responses API and Conversations API. Replay saved conversations and multi-step tool calls through both systems. Compare output quality, token usage, latency, and error recovery side by side. Keep both paths observable until you are certain your new application works reliably.