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

It shut down on 26 August 2026. The replacement is not a drop-in, and the most common migration mistake changes your model's behaviour without throwing an error.

What actually broke

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.

Why this is not a rename

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.

The gotcha that does not throw

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.

previous_response_id, where OpenAI manages prior context, but you must resend instructions each time

Pass prior output items back in yourself, which gives full control, and the option if you need to trim context to manage cost

Conversations API, for when you genuinely need a persistent conversation object

What this changes about cost

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.

What to do

Grep the codebase for the Assistants endpoints and for previous_response_id. Check background jobs and cron tasks, not just request handlers.

If you are already on the Responses API, confirm your instructions are being sent on every call rather than assumed to carry over.

Decide deliberately which of the three history strategies each feature uses, rather than defaulting to previous_response_id everywhere.

Before you migrate, write down what a conversation costs at turn 5 and at turn 50. If those numbers are far apart, trim context as part of the migration rather than afterwards.

Add a synthetic check that exercises one real assistant flow end to end, so the next deprecation surfaces as an alert rather than a drifting metric.