By Greg Nowak. Updated 16 September 2026.
OpenAI’s Assistants API was shut down on 26 August 2026 and is no longer available. If part of your product still depends on Assistants, Threads, Runs, or Assistant-specific streaming helpers, this is no longer a deadline-management exercise. It is service recovery.
The supported replacement is the Responses API. However, changing an endpoint will not repair the assumptions accumulated around conversation history, tool calls, streaming events, retries, and stored resource IDs. The practical goal is to restore the smallest reliable user journey first, then recover useful state and remove the remaining legacy dependencies.
Stabilise the customer experience first
Begin with the affected journey, not the API documentation. Identify what customers currently see: a failed request, an endless loading indicator, a blank conversation, or a generic error. Disable misleading controls, give support staff an accurate explanation, and route users to an unaffected workflow where one exists.
Assign one owner to the incident. That person needs authority across application code, infrastructure, product behaviour, and customer communication. A migration split between several teams without a clear decision-maker can leave each technical component “finished” while the complete journey remains broken.
| Legacy dependency | Current direction | Immediate check |
|---|---|---|
| Assistant configuration | Instructions, tools, and configuration owned in application code | Can you reconstruct the production configuration without calling the retired API? |
| Thread | Conversation or application-managed history | Do you possess the messages, or only a dead Thread ID? |
| Run | Response | Which loading, retry, cancellation, and error states must be preserved? |
| Run Step | Response items | Do logs or dashboards depend on the old event sequence? |
| Assistant stream events | Responses streaming events | Can the interface handle deltas, completion, and errors correctly? |
Find the real dependency footprint
Search beyond the request handler. Assistant and Thread IDs often appear in database records, environment variables, job payloads, browser code, support tools, analytics pipelines, and retry queues. In a typical codebase, this is a useful first pass:
rg -n "beta\.(assistants|threads)|assistant_id|thread_id|runs\.(create|retrieve)|submit_tool_outputs" .For every match, record the business journey it supports and its replacement owner. Pay particular attention to background jobs: a repaired chat screen does not help if document processing, scheduled follow-ups, or support automation still enters through a retired Run.
Old resource IDs are now evidence for the inventory, not a recovery strategy. OpenAI’s migration guide states that the API call for retrieving Thread messages no longer works. If you stored only Thread IDs, inspect your own database, logs, exports, support records, and analytics before promising that historical conversations can be restored.
Do not migrate into another approaching shutdown
OpenAI’s concept map pairs Assistants with reusable Prompts, but that path is now temporary. Reusable prompt objects and the v1/prompts API are scheduled to shut down on 30 November 2026. OpenAI’s current direction is to move reusable prompt content into application code.
For a durable implementation, keep instructions, tool schemas, output contracts, and model settings in a versioned application configuration. Review changes through the same process as code, and retain enough release metadata to identify which configuration produced an output. This avoids replacing one retired server-side object with another short-lived dependency.
Choose conversation state deliberately
Use a Conversation when a customer case, workspace, or long-running task needs a stable identity across sessions, devices, or jobs. Conversations store messages, tool calls, tool outputs, and other items. For a short interaction that only continues from the immediately preceding result, chaining with previous_response_id may be simpler.
The retention difference matters. OpenAI says Response objects are stored for 30 days by default, while Conversation objects and their items are not subject to that 30-day time-to-live. Items from Responses attached to a Conversation persist with it. Treat that as a product, privacy, and deletion-policy decision—not merely an SDK option.
When old history is available in your systems, classify it before importing anything. Active cases may need continuity; completed work may only need a read-only transcript; experiments may have no remaining value. Carrying every old message into live model context increases cost and can reintroduce obsolete instructions or sensitive data.
Rebuild tool calls and streaming as application workflows
Responses returns function-call items containing a name, encoded arguments, and a call_id. Your application executes the function and sends back a corresponding function_call_output. Test the complete loop, including invalid arguments, timeouts, duplicate submissions, multiple tool calls, and tools with side effects. A successful first model response does not prove the workflow is complete.
Streaming also has a different event contract. Common Responses events include response.created, response.output_text.delta, response.completed, and error. A small compatibility adapter can translate these into the internal events your interface already understands. That contains the migration while giving frontend and analytics consumers time to change safely.
Define “recovered” in product terms
Build a compact regression set from real, sanitised journeys: a first question, a multi-turn continuation, every tool, a failed tool, structured output, an interrupted stream, a retry, and a long conversation. Check required facts, schema validity, tool selection, final interface state, latency, and support visibility. Compare behaviour rather than exact wording.
Release behind a feature flag where possible, but do not describe the retired Assistants path as a rollback. Your rollback options now live inside the new implementation: a previous application release, a simpler Responses route, reduced tool availability, or a controlled maintenance state.
If you need one person to connect the API work with operations, customer continuity, testing, and rollout decisions, talk to Greg about a focused migration review.
Related on GrN.dk
- EU OpenAI Residency Is a Migration Project, Not a Dashboard Toggle
- The AI-built tool your team relies on needs an owner
Related on GrN.dk
- AI automations need a spend dashboard before the first runaway bill
- From Supplier PDFs to Product Data: Where AI Needs a Second Check
- OpenAI Responses API and the old assistant migration clock
Need help with this kind of work?
Review your OpenAI migration with Greg Get in touch with Greg.
