OpenAI Assistants API Deprecated: What Broke

If your error rate against /v1/assistants went vertical on Tuesday morning, your code is fine. The endpoint is gone. Is the OpenAI Assistants API deprecated? It has been since August 26, 2025, and one year later, on August 26, 2026, OpenAI switched it off for real. There was no grace period, no automatic forwarding to the replacement, and no tool that moves your data across for you.

Key Takeaways:

• The Assistants API shut down on August 26, 2026, exactly one year after the deprecation notice. /v1/assistants, /v1/threads, and /v1/runs no longer serve traffic.
• The replacement is the Responses API plus the Conversations API, and the object model changed names: Assistants became Prompts, Threads became Conversations, Runs became Responses, Run steps became Items.
• Prompts can only be created in the OpenAI dashboard. If your app created Assistants dynamically at runtime, there is no like-for-like API call to swap in.
• OpenAI's published notice periods are 6 months for generally available models, 3 months for specialized variants, and as little as 2 weeks for anything with preview in the name.
• Your existing Assistant, Thread, and Vector Store objects were not part of the shutdown announcement, so treat their status as unconfirmed rather than assuming either deletion or permanence.

Why Is the OpenAI Assistants API Deprecated, and What Took Its Place

OpenAI's own framing, posted to the developer forum by staff member edwinarbus in August 2025, is that Assistants were "our early take on how agents could be built (before reasoning models)." The company said it would retire Assistants once the Responses API reached feature parity, and it declared parity reached, folding code interpreter and persistent conversations into Responses. The announcement also went out on the OpenAI Developers account the same day.

The Assistants migration guide now carries a blunt banner: "The Assistants API was officially sunset on August 26, 2026, and is no longer available. Use the Responses API for new integrations."

That announcement thread has run to 36 replies and roughly 6,900 views, which for a deprecation notice is a lot of people arriving with the same question.

The Four Objects That Changed Names

The rename is the easy half of the job. OpenAI's guide maps the old object model onto the new one directly:

Read that table as a shape change rather than a find-and-replace. A Run was a job you started and then polled; a Response is a call that takes input items and hands back output items, with the tool-call loop managed explicitly by you instead of by OpenAI's orchestration. Anyone who built a thin wrapper around runs.create and runs.retrieve is going to rewrite that wrapper, not rename it. Budget for it the way you would a tokenizer and cost migration, where the visible change is small and the downstream accounting is not.

The polling difference is the one that tends to surprise people mid-migration. Under Assistants, you created a run and then asked OpenAI what state it was in until it came back completed or requires_action, and that second state was how tool calls reached you. Responses hands you the output items and expects your code to notice a tool call, execute it, and send the result back as a new input item. Whatever retry logic, timeout handling, and state machine you wrapped around run statuses does not carry across, because there are no statuses to poll. OpenAI's guide also notes that conversation state can be managed through a conversation object instead of threading previous_response_id through every call, which is the closest thing to a drop-in for what Threads used to do for you.

The Part That Actually Hurts: Prompts Are Dashboard-Only

Here is the line in the migration guide that generated most of the forum traffic: "Their replacement, prompts, can only be created in the dashboard, where you can version them as you develop your product."

Assistants were API objects. You could create one at runtime, per customer, per tenant, per uploaded document set. Prompts are console artifacts that you author by hand and then reference by ID.

A developer posting as Peter_Harrison put the objection plainly: "My application is dynamically creating Assistants. I'm not sure how this is 'feature parity'. Is there a API way to create Prompts?" Another, KathSeaCat, asked the question that a lot of agencies were quietly asking: "I just don't see how I can replace the Assistants API with this new API. Many of my clients are using assistants, will those assistants be removed or what?"

If you were creating one Assistant per customer, the honest migration is not a rename. You collapse to a small set of versioned prompts in the dashboard and push the per-customer variation into the request itself, as instructions and input items, or you keep your own configuration store and stop expecting OpenAI to hold that state. The second path is more work up front and it is the one that survives the next deprecation, because your configuration stops living inside somebody else's product.

That is the shape of the gap MoClaw fills: a hosted cloud AI computer where the workspace, the files, and the task definitions belong to you and outlive whichever vendor endpoint is currently in fashion. It sits alongside your existing OpenAI integration rather than replacing it.

What Happens to Your Threads and Vector Stores

This is where reporting on the shutdown has been sloppier than it should be, so here is what can and cannot be verified.

The migration guide covers Assistants, Threads, Runs, and Run steps. It says nothing about Vector Stores, and it makes no statement at all about whether your stored objects are deleted, retained, or exportable after the sunset. Claims circulating on social media in both directions, that your conversation history is already gone and that everything is retained until you delete it, are not backed by anything on the migration page as of August 28, 2026.

Treat that silence as a reason to act rather than a reason to relax. If you have thread content that matters, and you can still read it through any surviving path, export it to storage you control now and reconcile the record later. Recovering data you exported unnecessarily costs you an afternoon. The reverse costs considerably more.

There is a second reason to get your own copy, beyond the shutdown itself. Thread contents were the audit trail for a lot of support and compliance workflows, and an audit trail that lives entirely inside a vendor's beta product was always borrowing against a decision somebody else gets to make. The teams least bothered by this week already had their transcripts landing in their own storage as they were produced, because they had treated OpenAI as the model provider rather than as the system of record.

How to Tell Whether Your Code Still Calls the Retired Endpoints

Grep is faster than reading changelogs. The three retired paths are /v1/assistants, /v1/threads, and /v1/runs, and in the official SDKs they surface as client.beta.assistants, client.beta.threads, and the run helpers hanging off them:

grep -rnE "beta\.(assistants|threads)|v1/(assistants|threads|runs)|assistant_id|thread_id" \
  --include='*.py' --include='*.ts' --include='*.js' --include='*.rb' .

Check background workers, cron jobs, and retry queues as well as request handlers. A nightly summarizer that touches Threads once a day fails quietly for a week before anyone files a ticket, which is the same failure pattern that catches teams when a model ID disappears from an aggregator rather than from the vendor. We wrote up that version of the problem in No Endpoints Found for DeepSeek on OpenRouter, and the lesson carries over intact: the identifier in your config is not a version pin, it is a lease.

The Notice Periods You Are Actually Operating Under

The Assistants API got twelve months, which is generous by the standards of this industry and still caught people out. The published floors on OpenAI's deprecations page are lower:

• Generally available models: at least 6 months.
• Specialized variants of GA models, meaning chat variants such as gpt-5.1-chat-latest, Codex variants such as gpt-5.3-codex, and deep research variants: at least 3 months.
• Preview models, identified by preview in the name: as little as 2 weeks.

OpenAI's own advice on that page is worth quoting because it is more direct than most vendor documentation: "We don't recommend using preview models for business-critical production workloads unless you can migrate on short notice."

Two weeks is not enough time to schedule a rewrite through a normal sprint cadence, a squeeze we walked through when Kimi K2.5 was deprecated. It is enough time to flip a configuration value, but only if your architecture was built so that a model choice is a configuration value. That distinction is the whole game, and it is why the interesting question after a shutdown like this one is not "which endpoint do I move to" but "how much of my system assumed that endpoint would still be there." Running your recurring work on MoClaw puts the schedule, the files, and the credentials on a machine that stays up and stays yours, so swapping the model underneath a job is an edit rather than a migration project.

The same reasoning applies to timing. Deprecation deadlines land on the vendor's calendar, not yours, and they do not wait for your laptop to be open. MoClaw runs the job whether or not your machine is awake, which matters most on the week a cutover lands and someone needs to babysit a backfill overnight.

FAQ

Is the OpenAI Assistants API deprecated or fully shut down?

Both, in sequence. It was deprecated on August 26, 2025, and sunset on August 26, 2026. The migration guide states it "is no longer available," so this is a shutdown rather than a warning.

What replaces the Assistants API?

The Responses API for running work, and the Conversations API for holding conversation state. OpenAI positions Responses as its recommended integration path going forward.

Can I still create assistants programmatically?

No. Prompts, which replace Assistants, are created in the dashboard and referenced by ID. Applications that minted an Assistant per customer at runtime need a different design, either versioned prompts plus per-request instructions, or your own configuration store.

Did OpenAI provide a migration tool?

No automated tool was published. The migration guide describes manual steps: identify your assistants, recreate them as prompts in the dashboard, and convert thread messages programmatically from data you already stored.

Were my existing threads deleted on August 26?

Unconfirmed. The migration guide does not address the fate of stored Assistants, Threads, or Vector Stores. Export anything you still care about rather than relying on either assumption.

How much warning will the next deprecation give me?

Between two weeks and six months, depending on the model class. Preview models sit at the two-week floor.

Does any of this affect ChatGPT conversations?

No. The OpenAI Assistants API deprecated and retired here is a developer product. Consumer ChatGPT chat history is a separate system and was not part of this shutdown.

Where to Point Your Integration Now That Assistants Is Gone

Move new work to Responses plus Conversations, and take the rewrite of your run loop as the real cost rather than pretending the rename is the whole task. If you were creating Assistants dynamically, redesign that layer now instead of hunting for a workaround; the dashboard-only constraint on prompts is a deliberate product decision, not an oversight that a future release will quietly reverse.

Then do the boring part that pays off in eighteen months: write down every vendor identifier your system depends on, note which class of notice period it falls under, and put a calendar reminder on the ones with a preview in the name. The teams that spent Tuesday calmly flipping a config value were not luckier than everyone else. They had just already decided that a model ID belongs in configuration rather than scattered through the codebase, which is the only part of this whole episode you actually control.