The OpenAI Assistants API Shutdown Lands August 26: What Breaks and What to Move To

The assistants api shutdown arrives on August 26, 2026, twelve months to the day after OpenAI posted the deprecation notice. Applications still calling /v1/assistants and /v1/threads stop working. This is not a soft deprecation with a grace period attached, and it is not a model retirement where an alias quietly points somewhere else. It is the removal of an object model that a large number of production retrieval and agent applications were built on top of between late 2023 and early 2025.

The short version: the replacement is the Responses API paired with a Conversations object, the concept mapping is clean on paper, and the migration is more work than the mapping table suggests. OpenAI has said plainly that it will not ship an automated tool for moving your existing threads. And the migration path the documentation walks you through routes your configuration into an object type that is itself scheduled to shut down ninety six days later. This piece covers what actually stops working, what replaces it, where the documented path has a trap in it, what to do instead, and how this fits into a deprecation calendar that does not stop in August. For background on the object model this replaces, see our guide to what AI agents are.

What the Assistants API shutdown actually removes

The deprecation entry on OpenAI’s own deprecations page is unambiguous about both ends of the timeline. It carries an announcement date of August 26, 2025 and a shutdown date of August 26, 2026, and it points at the Responses API and the Conversations API as the recommended replacement. The notice explains the reasoning in a single sentence: "When we released the Responses API in March 2025, we announced plans to bring all Assistants API features to the easier to use Responses API, with a sunset date in 2026."

What that means operationally is that four endpoint families go away together. Assistants, the configuration objects that held your instructions, model choice, and tool list. Threads, the server-side conversation containers. Runs, the execution objects you polled or streamed. And run steps, the itemized record of what a run actually did. If your application creates any of these, your application has a hard dependency on an API that is being switched off this week.

The one thing the documentation does not say explicitly is what happens to the stored data behind those objects after the date. The migration guide covers how to read your thread history out and write it somewhere else, which is a strong hint that reading it out beforehand is the safe assumption rather than a nice-to-have.

The replacement is two objects, not one

The migration guide lays out a four-row mapping that is worth reproducing because it is the clearest statement of the design change.

The genuine improvement here is the collapse of the run lifecycle. Under the Assistants API you created a thread, added a message, created a run, then polled that run until it reached a terminal state, handling tool calls as interrupts along the way. Under Responses you send input items and get output items back. The state machine that a lot of teams wrote wrappers around simply is not there anymore.

OpenAI’s stated position is that the swap happens from a position of parity rather than ahead of it. The guide says: "After achieving feature parity in the Responses API, we’ve deprecated the Assistants API." The newer surface also carries capabilities the Assistants API never had, including deep research, hosted Model Context Protocol connections, and computer use.

There is no automated path for your existing threads

This is the sentence that should drive your planning, and it appears in the migration guide without hedging: "We will not provide an automated tool for migrating Threads to Conversations."

The recommended sequence is to point new user conversations at Conversations and Responses first, then backfill older threads as needed using the code examples provided. That is a reasonable engineering recommendation and a poor fit for anyone who assumed a one-click dashboard import was coming. If your product surfaces conversation history to users, the backfill is not optional work you can defer, because a user who opens an old conversation and finds it empty will read that as data loss regardless of what the API changelog says.

Teams running retrieval-heavy applications should also budget separately for the file and vector store side of the move rather than folding it into the same estimate. Our guide to retrieval-augmented generation covers why the retrieval layer tends to be where the surprises live.

The documented migration path has a second deprecation inside it

Here is the part that has gone almost entirely unreported, and it is the reason this is worth reading rather than skimming.

The migration guide’s opening steps are specific. Identify the most important assistant objects in your application. Find these in the dashboard and click Create prompt. This will create a prompt object out of each existing assistant object. Follow those three steps and your configuration now lives in a reusable prompt object.

Reusable prompt objects are on the same deprecations page as the Assistants API. Announced June 3, 2026, shutdown November 30, 2026. The entry states that the v1/prompts API and reusable prompt objects are scheduled to shut down, and the recommended replacement is to move reusable prompt content into your application code.

To OpenAI’s credit, the migration guide is not hiding this. It carries an explicit warning that reusable prompt objects are also being deprecated and points readers at the prompts timeline before adopting them in long-lived integrations. But the warning sits alongside a numbered walkthrough whose first concrete action is to create exactly those objects, and the code examples use them throughout. A team working quickly this week, under a deadline that lands tomorrow, will follow the steps and land on a second migration before the end of November.

What to do instead of the dashboard walkthrough

The recommendation is straightforward and it is the same one OpenAI gives for the prompts deprecation itself: keep the configuration in your own code.

An assistant object was, functionally, a stored bundle of instructions, a model name, a tool list, and some parameters. All four of those can be passed on a Responses call directly. Putting them in a versioned file in your repository gives you the same versioning benefit the mapping table credits to prompt objects, with the added properties that it survives November 30, it diffs in code review, it deploys with your application rather than out of band, and it does not require a dashboard round trip to change.

Concretely, that means a three-step plan rather than the documented one. Export the instructions, model, and tool definitions from each assistant object into your repository before Wednesday. Move new conversations onto Responses with that configuration passed inline, using a Conversation object only where you actually need server-side state. Then backfill historical threads on your own schedule, having already read the history out.

The one case for creating prompt objects anyway is if you have non-engineering staff editing agent instructions through the dashboard today and no near-term path to changing that workflow. Even then, the ninety six day window is short enough that the migration off prompts should be scheduled at the same time, not later.

The calendar does not stop in August

The Assistants API is the nearest deadline, not the only one. The same deprecations page lists a cluster of shutdowns that anyone maintaining an OpenAI integration should be reading as a single roadmap rather than as isolated notices.

The two November 30 replacements OpenAI names are external to its own API surface: the Agents SDK, which the documentation describes as using "the Responses API by default for OpenAI models," and Promptfoo for evals. Existing evals go read-only a month early, on October 31, 2026. The November 30 grouping is the one to note, because Evals, Agent Builder, and reusable prompts were all announced on the same day and all point away from OpenAI-hosted configuration and toward code you own. Read together with the Assistants retirement, the direction is consistent: OpenAI is narrowing the set of stateful objects it hosts on your behalf.

Who this actually hits

The applications most exposed are the ones that adopted the Assistants API early precisely because it did the most for them. A team that used threads as its only conversation store, file search as its only retrieval layer, and the dashboard as its only configuration surface has three migrations rather than one, and no local copy of any of it. The pattern is familiar from other retirements this year, including OpenAI’s decision to retire the Atlas browser.

Teams that wrapped the Assistants API behind their own interface are in far better shape, which is the general argument for that pattern rather than a point about this specific shutdown. The same holds for anyone who routes through a framework layer. Our 2026 AI agent framework landscape covers which of those layers have already absorbed the change.

The broader lesson is about hosted convenience objects generally. Threads, assistants, stored prompts, and hosted eval runs all removed work at adoption time and added coupling that only becomes visible at a sunset date. That trade can be worth making. It is worth making with an export path already written.

Frequently Asked Questions