On August 26, 2026, OpenAI removes the Assistants API. Calls to /v1/assistants
, /v1/threads
, and /v1/threads/runs
start returning errors. That date has been on developer calendars for a year, and it's the easy part: a hard cutoff fails loudly, in your face, on a day you can plan around.
The part that actually costs people is the migration to the Responses API — and that one doesn't wait for August 26, and it doesn't fail loudly.
When you port an Assistants-based app to Responses, the endpoints answer with 200 OK
. Nothing throws. But three things the Assistants API used to manage for you are now your job, and if you wire any of them wrong, the failure shows up as degraded behavior, not an error: a model that forgets context, grounding that quietly drops, a stream that renders blank. You ship it, it looks fine in a smoke test, and it's wrong in production.
The Assistants API was stateful and opinionated. A Thread persisted conversation history, truncated it to fit the context window, and orchestrated tool runs — implicitly, with no code on your side. The Responses API is deliberately simpler: you send input items, you get output items back. Almost everything the Thread did for you is now an explicit decision.
That inversion is the trap. A "shallow" migration — swap the endpoint, keep the shape of your code — compiles, runs, and returns 200
. The regressions are in the gap between what the Thread used to do automatically and what you now have to do on purpose. None of that gap raises an exception. It just makes the output worse, on a delay, in ways your tests probably don't assert on.
Here are the three places it bites.
In the Assistants API, you appended a message to a Thread and the Thread was the state. History and truncation were handled for you.
In Responses, persistent conversation state is explicit. You either chain turns by passing previous_response_id
from the last response into the next request, or you use the Conversations API to hold history. Two things go wrong here, both silently:
200
. There's no error to catch; the model just behaves like it has amnesia.previous_response_id
The Assistants version of this code couldn't have this bug, because the Thread never let state fall on the floor. The Responses version can, and it won't tell you.
Assistants file_search
was forgiving: a run could search across both assistant-level and thread-level vector stores, and the run flow wired retrieval in for you. You attached files, asked a question, and got grounded answers.
In Responses, file search is configured explicitly on the tool — you pass the vector_store_ids
you want searched, and retrieval behavior is yours to tune. The failure mode is obvious in hindsight and invisible at runtime: miss a vector store in the list, and that knowledge silently disappears from grounding. The request succeeds. The model still answers — it just answers from less context, or from none, and falls back on its parametric memory.
A retrieval miss doesn't look like a 404
. It looks like a slightly worse answer, or a confidently wrong one, for the subset of questions that depended on the store you dropped. Nobody gets paged. Your eval suite — if you have one — catches it. Your 200
-checking integration test does not.
If you stream responses, this is the one most likely to ship broken to real users.
The Assistants API emitted run-centric server-sent events — deltas tied to runs, run steps, and messages (thread.run.step.delta
, thread.message.delta
, and friends). Downstream consumers were written to pattern-match those event types and assemble the output from them.
The Responses API emits a different event taxonomy — response-centric events like response.output_text.delta
and response.completed
. A consumer still listening for the old thread.*
events does something worse than crash: it connects, the stream opens, events flow, the stream completes — and none of them match the handlers it's looking for. The result is an empty or truncated render on a connection that, by every status check, succeeded. 200
, clean SSE, blank UI.
This is exactly the kind of break that passes review (the request works!) and gets discovered by a user, because the failure lives in event-name strings, not in HTTP status.
Built-in tools moved too. In Responses, hosted tools like web search and file search carry per-call fees that didn't exist under the Assistants API. Migrate a high-traffic assistant that leaned on those tools and your functionality is identical, your error rate is zero, and your invoice drifts up with no code change to point at. Silent cost regression is still a regression.
And there's no shortcut waiting to save you: OpenAI has stated it will not ship an automated tool to migrate existing Threads into Conversations. The recommended path is to start new sessions on the new model and backfill old history yourself. Anyone counting on a one-click migration in August is going to find out, in August, that it isn't coming.
previous_response_id
vector_store_ids
you pass in Responses. Then run a retrieval eval, not just a 200
check — a request that returns successfully with empty grounding is the failure you're looking for.response.*
events, not thread.*
ones.200
. The only way to catch a state drop, a grounding miss, or an unhandled event is to inspect what's actually in the response — not whether the call succeeded.The shutdown date is the loud, well-advertised part, and it's the part you're least likely to get wrong. The migration is the quiet part — and a 200
that's missing your context, your grounding, or your output is far harder to notice than an honest error on August 26.
FlareCanary watches your API responses for exactly this: a field that changes type, a value that goes null, an event shape that drifts, a contract that quietly stops meaning what it used to. Migrations like Assistants → Responses are where response shapes change silently — and a 200
with the wrong shape is the failure that reaches your users before it reaches your logs. If the contract you depend on changes, you hear it from us first.