OpenAI removes the Assistants API on 26 August 2026. They announced it on 26 August 2025, so there has been a full year of notice.
If your app still calls /v1/assistants, /v1/threads or /v1/runs, it stops working that day. There is no extension. Azure OpenAI customers are on a separate clock and have until February 2027. Everyone else is not.
This post has two parts. What actually changes, and some numbers on how often teams move when a vendor warns them a year ahead. The second part is not encouraging.
What changes
The mapping is simple to state and annoying to do:
- Assistants become Prompts
- Threads become Conversations
- Runs become Responses
- Run steps become Items
In code, the shape of it looks like this.
Before:
const thread = await openai.beta.threads.create();
await openai.beta.threads.messages.create(thread.id, { ... });
let run = await openai.beta.threads.runs.create(thread.id, {
assistant_id: "asst_..."
});
while (run.status !== "completed") {
run = await openai.beta.threads.runs.retrieve(thread.id, run.id);
}
After:
const conversation = await openai.conversations.create();
const response = await openai.responses.create({
conversation: conversation.id,
prompt: { id: "pmpt_..." },
input: "..."
});
Check the official migration guide for exact parameter names before writing anything real. The point of the snippet above is the shape, not the syntax.
Four things that make this more than a rename
1. Prompts are built in the dashboard, not in code. This is the one that catches people. If your app creates assistants dynamically at runtime, there is no equivalent path yet. It is the loudest complaint in OpenAI's own announcement thread and it does not have a clean answer.
2. There is no bulk export for threads. You move live conversations gradually as they come back, rather than running one migration script over a weekend.
3. The polling loop goes away. You send input items and get output items back. Nothing to poll. This part is genuinely nicer.
4. You have to decide where state lives. Responses is client-stateful by default. You pass previous_response_id to keep continuity, and the server holds that chain for 30 days. After that you rebuild from your own database, which means you need one.
For a small team, this is a week of work that nobody planned for.
Why most teams will miss the date
I wanted to know what actually happens when a vendor gives a year of notice. So I measured it.
I pulled one week of npm download counts for 32 widely used SDKs, grouped every download by the exact version requested, and checked how old each version was. That is 355 million installs across 7,190 distinct versions.
- 79% of downloads were for a version at least one major behind
- The median version being installed is 376 days old
- 23 of the 32 vendors have most of their traffic on an old major, not a minority of it
- For the
openaipackage specifically: 99% behind, at a median of about seven months
Two caveats, because they matter and somebody will raise them otherwise. CI runners re-download pinned versions constantly, so an unknown share of that 79% is machines rather than teams sitting on a backlog. And this is npm only, so other ecosystems are unmeasured.
Even discounted heavily, about a year of staleness is real.
The part that is nobody's fault
Upgrading a vendor SDK ships no feature, wins no customer, and appears on no roadmap. It is invisible when done and expensive when skipped, which is exactly the kind of work that slips quarter after quarter. A year of notice does not change that. It only sets the date the bill arrives.
If you are still on Assistants with two weeks left, check the dashboard-only Prompts limitation first. It is the one that can block you outright rather than just cost you time.
Full data, method, and every source: apinae.dev
If you have already migrated, I would like to know how long it took and what broke that you did not expect.
