OpenAI Assistants API Down: Migrate to Responses API

Daniel Reyes Principal Engineer (AI/ML), YuSMP Group · LLM systems, agents and AI tooling for US and EU products

What happened

What breaks and who is affected

The Assistants API was the standard OpenAI surface for building stateful AI features: chatbots with persistent memory, document Q&A systems using file search, step-by-step agentic workflows using the code interpreter, and multi-turn virtual assistants that remembered context across sessions. Teams that built any of these on /v1/assistants and /v1/threads are looking at live production breakage as of yesterday morning.

The failure mode is unambiguous: HTTP error responses on every call. There is no degraded fallback; the Assistants API does not return cached or last-known state. Applications that have not migrated are returning errors to users right now, not slower or incomplete responses.

The class of products most at risk: SaaS products that embedded an OpenAI-powered assistant as a support or onboarding feature; internal enterprise tools built on Assistants for document search across internal knowledge bases; and AI agent workflows that used the Run-and-Thread model to coordinate multi-step tasks. All three categories need a migration before normal service resumes.

Azure OpenAI: not affected

Teams running on Azure OpenAI Service are in a different situation. Microsoft confirmed in its developer Q&A that Azure OpenAI is a separate product that does not use OpenAI's Assistants API endpoints. Azure OpenAI maintains its own assistant and agent surfaces; no changes have been announced, and no migration is required for Azure-hosted workloads at this time.

This distinction matters for enterprise teams in regulated industries who specifically chose Azure OpenAI for data-residency, compliance, and RBAC reasons. Their integrations are unaffected and continue to operate normally. Any future changes to Azure OpenAI's assistant features will come with Microsoft's own notice timeline.

The architectural shift: Responses API

The Assistants API was built around a persistent Thread-and-Run model: an Assistant object held instructions and tools; a Thread held the conversation history; a Run executed against a Thread. State lived server-side and persisted until explicitly deleted. This was convenient but created architectural coupling: every call depended on the server knowing the full prior state of that Thread.

The Responses API inverts this. By default, calls are stateless — context is passed in the request rather than retrieved from server-side Thread storage. Persistent sessions are handled through the separate Conversations API. Key differences that affect application architecture:

• Conversation persistence: Conversation objects in the new Conversations API have no 30-day TTL — they persist indefinitely. Response objects (individual call outputs) are stored for 30 days by default.
• Reasoning token continuity: With GPT-5, reasoning tokens are preserved across turns in a conversation session, something that was not possible under the Assistants Run model.
• Tool availability: The Responses API surfaces code interpreter, deep research, MCP tool integration, and computer use natively. Teams that used file search in the Assistants API will want to evaluate the equivalent retrieval capabilities in the new stack.
• Prompt management: The Assistants API allowed Assistant objects (with their system prompt and tool config) to be created and updated programmatically via API. The Responses API moves prompt versioning to the OpenAI dashboard. For teams with automated assistant deployment pipelines, this is a workflow change, not just an API change.

Migration steps for dev teams

OpenAI has published an Assistants-to-Conversations migration guide in its developer documentation. The practical sequence for teams migrating under time pressure:

1. Audit existing Assistants API usage. Find every call to /v1/assistants, /v1/threads, and /v1/threads/{id}/runs in your codebase. These are the callsites that are now returning errors.
2. Map your Assistant objects to Responses API calls. An Assistant object (system prompt + tools + model config) maps to a Responses API request with a system message and tools array. If you were managing multiple Assistant objects by API, you will need to create those equivalents in the OpenAI dashboard or encode them as request parameters in your application.
3. Rebuild Thread persistence via Conversations API. There is no automated migration for Thread content. Existing Thread history cannot be transferred. For products where conversation history is critical — support bots, user-facing assistants — you will need to decide whether to start fresh sessions or export and re-import Thread content before rebuilding the Conversation object on the new API.
4. Test tool behaviour. If your Assistants integration used code interpreter or file search, validate that the equivalent Responses API tool call produces the same output format. Breaking changes in tool output schema can cause silent downstream failures even after the API migration is technically complete.
5. Update error handling. The Responses API has a different error model and retry behaviour than the Assistants API. Update your error handling and rate-limit logic to match the new surface.

What it means for US & EU software teams

The Assistants API shutdown is the most disruptive OpenAI platform event since the GPT-3.5 to GPT-4 transition, and the first one that causes immediate hard failures rather than degraded performance. Three things to factor in when triaging and planning:

The immediate problem is not the API change — it is the no-automated-migration policy on Threads. Switching the API surface from Assistants to Responses is a meaningful engineering task but a tractable one. The harder problem is that any Thread history your application accumulated — user conversations, document Q&A sessions, multi-turn agent runs — has no automated transfer path. For consumer-facing products, this means user context is lost. Deciding what to preserve and how to re-establish it is as much a product decision as a technical one.

The gap in prompt management via API is a real operational concern for teams with deployment pipelines. If your CI/CD pipeline programmatically created or updated Assistant objects as part of a deploy, that step is broken. OpenAI’s migration path for this is to move prompt management into the dashboard, which breaks automated workflows. Teams that need to maintain programmatic prompt versioning will need to build their own layer on top of the Responses API or evaluate third-party tools that manage this abstraction.

For teams evaluating whether to stay on the OpenAI stack or move to a multi-provider approach, this is a decision point. The Responses API is a better architecture overall — more flexible, more capable, better aligned with how modern AI-native products are built. But the migration cost and the shift in operational model (dashboard-managed prompts, new error handling, Thread history loss) are real. Teams that have invested heavily in the Assistants API are making a migration decision under time pressure rather than on their own roadmap. That is a reasonable moment to evaluate whether the OpenAI platform lock-in is still acceptable, or whether an abstraction layer or multi-provider strategy reduces this class of risk in future.

Frequently asked questions

Sources

OpenAI — API Deprecations (official documentation)
OpenAI Developer Community — Assistants API Beta Deprecation: August 26, 2026 Sunset
Microsoft Learn Q&A — OpenAI Assistants API Deprecation Impact on Azure OpenAI