The Assistants API shuts down August 26. Port it now.

OpenAI's Assistants API stops working on August 26, 2026. That is six days from today. After that date, calls to /v1/assistants, /v1/threads and /v1/threads/runs return an error, according to OpenAI's deprecations page. There is no degraded mode and no grace period.

The replacement is two APIs, not one. Most migration guides stop there. They skip the part that actually breaks a shipped product: your stored conversation history does not come with you.

What is the Assistants API, and what replaces it

The Assistants API is OpenAI's older stateful agent API. It stored your agent config, its chat threads, and its tool runs on OpenAI's servers. You created a run, then polled it until it finished.

The Responses API is the replacement for the run itself. You send input items and get output items back. There is no polling loop.

The Conversations API is the replacement for stored chat history. It holds a stream of items rather than a flat list of messages.

You need both. A lot of write-ups say "move to Responses" and stop, which leaves out where the history lives.

What each Assistants object maps to now

The official migration guide gives a direct object mapping. Here it is in one table.

Assistants API (old)	Replacement (new)	What changed
Assistant	Prompt	Holds model, tools and instructions. Dashboard-managed.
Thread	Conversation	Stores items, not just messages.
Run	Response	One call. No polling.
Run step	Item	Generic object: a message, a tool call, or an output.

The code shrinks. The old pattern created a run, then slept and retrieved it in a loop:

run = openai.beta.threads.runs.create(assistant_id=..., thread_id=...)
while run.status in ("queued", "in_progress"):
    await asyncio.sleep(1)
    run = openai.beta.threads.runs.retrieve(...)

The new pattern is one call:

response = openai.responses.create(
    prompt={"id": os.environ["OPENAI_PROMPT_ID"]},
    input=[{"role": "user", "content": message.content}],
    conversation=conversation_id,
)

For a single-turn bot, that is an afternoon of work. The pain is elsewhere.

The thread data trap

OpenAI states plainly that it will not provide an automated tool for migrating Threads to Conversations. That one sentence is the whole migration risk.

Think about what a Thread holds. It is every message a customer ever sent your bot. If your product shows chat history, that history is user-visible data. It lives on OpenAI's servers today. On August 26, 2026 the endpoint that reads it stops answering.

So you have three choices, and only one of them is free:

1. Export now, backfill later. Pull your threads down before the cutoff and store the raw JSON yourself. Do this even if you have not picked a target format, such as a plain S3 dump. Exported data can wait; deleted data cannot.
2. Transform on demand. OpenAI's migration guide ships Python and Ruby scripts that turn message content into item format. Run them per user, lazily, the first time someone opens an old chat.
3. Drop the history. Fine for a stateless widget, for example a docs search box. Not fine if a customer paid for the transcript.

Option one is the only one with a deadline attached. Do it this week, whatever else you decide.

MCP went stateless. Your server still has state. The same split applies here: the protocol got simpler, and the state you were leaning on became yours to hold.

What happens to your vector stores and files

Vector stores and uploaded files survive. They are not part of the shutdown.

A vector store is a hosted index of your uploaded documents. Under the Assistants API you attached one to an assistant. Under the Responses API you pass vector_store_ids into the file search tool config instead, as described in the Assistants file search documentation.

That is a config change, not a re-upload. You do not pay to re-embed anything. This is the cheapest part of the port, so do not budget much time for it.

One trap sits here, though. Vector stores created through a thread, such as the ones made automatically from message attachments, expire seven days after they were last used. That default exists to cap storage cost. If your migration script reads old threads and expects their attachment stores to still be there, plenty of them will already be gone.

What about Azure OpenAI?

Azure lands on the same date but a different destination. Microsoft's own documentation for Azure Assistants file search states that the Assistants API is deprecated and will be retired on August 26, 2026, and points users to the Microsoft Foundry Agents service.

That matters, because the two clouds do not share a replacement. On OpenAI you rewrite against Responses plus Conversations. On Azure you migrate classic agents to Foundry Agents. Copying an OpenAI migration guide onto an Azure deployment will send you to the wrong API.

Developers have been asking about the overlap on a Microsoft Q&A thread. Check your own resource notice before you assume anything either way.

Should you port now, or park on a compatible layer?

Port now if your integration is small. Consider the common case: a single assistant, one tool, no visible history. That is a day of work, and waiting buys you nothing.

Park if you have several assistants, custom tool routing, and real transcripts. Some third-party services offer a wire-compatible implementation of the old endpoints, self-hosted or managed. You point your base URL at one of those, keep shipping, and rewrite on your own schedule.

The trade is honest. A compatibility layer means a new vendor or a new service to run, plus latency you did not have. But it turns a hard deadline into a soft one, and that is worth real money in a week where you have other work.

One caution on cost. The cheapest AI API is not the cheapest to run, and the same holds for the layer in front of it. Price the hosting and the on-call, not only the per-token rate.

The decision, in one line

If your app touches /v1/threads in production, export your thread data before August 26, 2026. Then port to Responses plus Conversations, or park behind a compatible endpoint. Doing nothing means a hard failure on a known date.