The Assistants API is gone. Your app may not have told you yet.

The Assistants API sunset on 26 August 2026 and is no longer available. If you are reading this because something stopped working, that is the reason, and the date has already passed.

The failure is easy to miss. Assistants-based features are usually background work: a support summariser, a document processor, an onboarding agent. They fail into a queue rather than into a user's face, so the first symptom is often a metric drifting rather than an error page. If you are not certain whether you still call it, grep for the endpoints before you read further. It is faster than reasoning about it.

The Assistants API managed a lot on your behalf: threads, runs, the tool attachment lifecycle, and the polling and orchestration around them. You created a thread, added messages, started a run, and waited.

The Responses API does not do that. Calls are stateless. There is no server-side thread lifecycle, which means your application now owns memory, retries, orchestration, and state. That is more code than a find-and-replace, and it is the part teams underestimate.

The vocabulary changed too, in a way that matters. A thread was a collection of messages, and it could only hold messages. A conversation holds items, and an item can be a message, a tool call, a tool output, or other data. If your code assumed everything in the history was a message, that assumption no longer holds.

You have three options for carrying history, and the differences between them are not cosmetic.

The one to be careful with is previous_response_id. It is the closest thing to the old behaviour and therefore the one most people reach for, but it does not carry over the previous response's top-level instructions. If your system prompt lived in instructions and you assumed chaining responses would preserve it, your model is now running without it.

Nothing errors. The call succeeds, you get a plausible-looking response, and your assistant has quietly lost its persona, its constraints, and whatever safety rules you wrote into that field. This is the single most expensive detail in the migration, because it degrades quality silently rather than failing loudly. Resend stable instructions on every request.

Owning your own context window is a billing decision as much as an architectural one. When the platform managed the thread, context growth was somebody else's problem. Now every token of history you replay is a token you pay for on every turn.

That cuts both ways. Teams that migrate carelessly replay the entire history each call and watch their bill climb with conversation length. Teams that use the migration as a reason to trim aggressively often end up cheaper than they were before, because they finally have a place to make that decision.