The OpenAI Assistants API Shuts Down in Five Days. There Is No Tool to Move Your Threads.
The OpenAI Assistants API shuts down on August 26. That is five days from today, and it is exactly one year after OpenAI told developers it was coming, on August 26, 2025. A year of notice is generous by API standards, which is precisely why the people still on it are the people who filed it under "later" twelve times.
The migration coverage I have read treats this as a code problem: swap your calls from Assistants to the Responses API, ship, done. That is the easy half. The half that will actually cost you a weekend is that OpenAI has said it will not provide an automated tool to migrate Threads to Conversations. Your endpoints get a replacement. Your stored conversation history does not get a mover.
The replacement is two APIs, not one
Assistants is being replaced by the Responses API plus the Conversations API. If you built on Assistants, you used one product that held three concepts together: an assistant (the configuration), a thread (the message history), and a run (the execution). The new shape splits those. Responses handles the model call and returns output items. Conversations handles the persisted history.
That split is a better mental model, and I say that as someone who found Assistants genuinely confusing to reason about. Responses also gets things Assistants never had, including MCP support and computer use. If you were going to be on OpenAI's platform for the next two years anyway, this is the right direction.
But "better mental model" and "drop-in replacement" are different claims, and only one of them is true here. You are rebuilding your assistant configurations as Responses API calls, and you are recreating threads yourself.
The data is the part you forgot was data
Here is the failure mode I expect to see in about a week, in someone's postmortem.
You built a support bot, or a document Q&A tool, or an onboarding agent. Each customer got a Thread. That Thread accumulated the conversation. You never wrote a migration for it because you never thought of it as your database. It lived at OpenAI, it worked, and your own Postgres just stored a thread_id string next to a user row.
On August 27, that thread_id is a pointer to nothing.
If your product has any concept of "pick up where we left off," that is the feature that breaks, and it breaks silently for existing users rather than loudly at build time. Nobody's CI catches a foreign key into someone else's system.
So the first thing I would do today, before touching any application code, is enumerate every Thread ID my system references and pull the message contents down to storage I control. Export first, migrate second. Even if you decide to start every user fresh on the new API, having the transcripts on disk means the decision stays reversible and you can honor a support request three months from now.
Your Zapier steps are on the list too
This is the one I would not have guessed. Zapier has deprecated its ChatGPT steps that were built on the Assistants API, and Zaps using those steps stop working on August 26 as well.
Think about what that means for the median small operation. Your code migration has a repo, a diff, a test suite, and a person who remembers writing it. Your Zap has none of that. It was set up in a browser tab eighteen months ago by whoever needed it, it has been quietly working since, and it does not appear in any dependency graph you own. There is no grep for it.
If you run any no-code automation that talks to OpenAI, open the account and read the step list. This applies double if you use a contractor or an agency who set things up on your behalf and moved on.
What I would actually do, in order
Five days is enough time if you spend it on the right things. My order of operations:
- Inventory, do not migrate. Search your codebase for
/v1/assistants,/v1/threads, andassistant_id. Search your Zapier, Make, and n8n accounts for OpenAI steps. Write the list down. Half an hour. - Export every Thread you reference. A script that walks your
thread_idcolumn and writes messages to JSON in your own object storage. This is the irreversible one, so it goes before anything else. An afternoon. - Port the highest-traffic surface only. Pick the one path that most users hit and move it to Responses plus Conversations. Do not try to port everything at once under a deadline; that is how you ship a subtle regression in the path nobody tests.
- Stub the rest with a real error. For anything you cannot port in time, return an honest message to the user rather than a 500. "This feature is being upgraded, your history is saved" is a sentence you can only write truthfully if you did step two.
- Check your platform. If you reach OpenAI models through Azure rather than the first-party API, confirm the timeline with Microsoft separately. Azure's schedule for Assistants has been a distinct question from OpenAI's and I would not assume the dates line up. Read Azure's own deprecation notice rather than OpenAI's.
Where I might be wrong about this
Two places.
The first is scale. If your Threads are short-lived, if you spin one up per session and never resume it, then everything above is overthinking. Export nothing, port the code, move on. The data-loss argument only bites when the thread is a durable artifact your users expect to persist, and plenty of Assistants deployments were never that.
The second is that "no automated migration tool" is a statement about what OpenAI ships, not a statement about what is possible. Reading threads through the API and writing them into Conversations is a loop, not a research project. Somebody has almost certainly published a script by now. I would still read it before running it against production, but I would not write my own from scratch without looking.
The thing I am confident about is narrower: the risk here is not in the endpoint swap, it is in the state you left in somebody else's system and stopped thinking about. That pattern is not specific to OpenAI, and it will happen again with a different vendor. The habit worth building is knowing, at any moment, which of your product's durable data lives somewhere you do not control.
Author
Lukas
@lukcombinator