OpenAI Assistants API Shuts Down Aug 26 — Migrate Now

OpenAI will shut down its Assistants API on August 26, 2026, affecting all endpoints including /v1/assistants, /v1/threads, and /v1/threads/runs, with no grace period or extension. The company will not provide an automated tool to migrate Threads to Conversations, so developers must export thread history before the deadline. The replacement is the stateless Responses API paired with the opt-in Conversations API, offering new capabilities such as deep research models, MCP support, and 40–80% better cache utilization.

OpenAI’s Assistants API goes dark on August 26, 2026. Every call to /v1/assistants , /v1/threads , and /v1/threads/runs returns an error after that date — no degraded mode, no grace period, no extension. The migration to the Responses API is not a drop-in swap; it’s an architectural rewrite. And OpenAI won’t move your stored thread history for you. What’s Actually Shutting Down The full endpoint list going offline: /v1/assistants , /v1/threads , /v1/threads/runs , /v1/threads/runs/steps , and the file-handling methods tied to the Assistants workflow. If your codebase uses openai.beta.assistants or client.beta.assistants , that’s your signal to start now. Azure OpenAI users aren’t exempt — the Azure OpenAI Assistants API retires on the same date. If you’re on Azure, your migration target is the Microsoft Foundry Agents service https://learn.microsoft.com/en-us/answers/questions/5790094/will-azure-openai-assistants-api-specifically-be-d . Note: Foundry Agent Service classic has a separate, later retirement date of March 31, 2027 — it is not a shelter from the August 26 deadline. The Biggest Gotcha: Your Threads Aren’t Coming With You OpenAI’s official migration guide is blunt: “We will not provide an automated tool for migrating Threads to Conversations.” That stored conversation history in your Threads — customer chat logs, support history, multi-turn sessions — becomes inaccessible the moment the API goes down. Before August 26, export any thread history your application depends on. Pull all messages from critical threads via the current API and store them externally in your own database. Once the API is gone, so is the data. The New Mental Model: Two APIs, Not One The Assistants API was a single stateful system: OpenAI stored your Threads, managed your tool calls, and handled context automatically. The replacement is two APIs working together: Responses API — stateless by design. Send input items, get output items back. One clean request-response cycle. Conversations API — opt-in persistence. Replaces Threads, but you choose when to use it. The concept mapping: Assistant becomes a Prompt managed in the dashboard , Thread becomes a Conversation, Run becomes a Response, and Run Step becomes an Item. For simple bots, chain state via previous response id . For production multi-turn systems, build a conversation store — Redis, Postgres, or whichever fits your stack. What You Actually Gain This migration isn’t all pain. The Responses API https://developers.openai.com/api/docs/guides/migrate-to-responses unlocks capabilities the Assistants API never had: Deep research — access to o3-deep-research and o4-mini-deep-research models MCP connections — remote Model Context Protocol server support Computer Use — autonomous browser and desktop control tools 40–80% better cache utilization — measurably cheaper at production scale Background mode — handles long-running async tasks without Run timeout headaches The old Run polling loop — create thread, add message, create run, poll until complete — is gone. The Responses API executes and returns. That alone simplifies a significant amount of boilerplate code. Migration Checklist Audit your codebase — search for /v1/assistants , openai.beta , client.beta.assistants Export thread history now — pull messages from production threads, store externally before Aug 26 Replace run calls — swap /v1/threads/runs for /v1/responses Own your state — build a conversation store or use previous response id chaining Move Assistant config to Prompts — recreate system instructions in the OpenAI dashboard Run old and new in parallel — test side-by-side before final cutover Azure users — follow the Microsoft Foundry Agents migration path specifically Complexity scales with your integration. A simple single-turn bot can migrate in hours. A multi-tenant production system with customer thread history, complex tool orchestration, and file handling needs two to three weeks minimum. Start the audit today — the official migration guide https://developers.openai.com/api/docs/assistants/migration and the OpenAI community thread https://community.openai.com/t/assistants-api-beta-deprecation-august-26-2026-sunset/1354666 are the two most useful resources. The full deprecations timeline https://developers.openai.com/api/docs/deprecations covers every affected endpoint. Sixteen days is enough time if you start now. It is not enough time if you start on August 25.