OpenAI's Assistants API Died Right on Schedule. Yours Might Be Next.

On August 26, OpenAI turned off the Assistants API.

Every request to /v1/assistants, /v1/threads, and /v1/runs now fails. Not degraded, not rate-limited. Gone. Exactly one year after OpenAI told everyone it was coming, to the day.

A year of warning. And the OpenAI developer forum thread announcing the sunset still has more than 40 replies of people asking what happens to their production app now.

The Warning Nobody Acted On

OpenAI posted the deprecation notice on August 26, 2025. Assistants API beta deprecation, sunset date stamped right in the title. Twelve months on the calendar. A published migration guide. A newer, better-documented replacement — the Responses API — sitting there the entire time.

None of that mattered to the apps that shipped on Assistants and never touched the code again.

That's not a hypothetical. Go read the thread. People asking if their threads data is recoverable. People asking why their support bot stopped responding in production. People who built a real business on an endpoint marked "beta" and treated it like it was permanent infrastructure.

A year is a long runway. It's also exactly long enough for a working feature to stop being anyone's priority.

That's the trap. Nobody schedules "migrate off the API that still works fine" on a Tuesday. It gets a ticket, the ticket gets a "Q3" label, and Q3 becomes the week the endpoint actually goes dark.

It Wasn't Just OpenAI's Deadline

Azure OpenAI ran the same Assistants API under license, and Microsoft retired it on the identical date. Azure customers got pointed at Microsoft Foundry Agents — a different service, built on the same Responses-style model, with its own migration checklist and its own set of edge cases nobody had tested until the deadline forced them to.

Two clouds, one shared beta feature, one shared expiration date. If your app called Assistants through Azure instead of OpenAI directly, you didn't get a grace period for being on "the enterprise cloud." You got the same August 26 cutoff, filtered through an extra layer of documentation to figure that out.

That's worth sitting with. The size of the vendor didn't buy anyone more runway. Only the architecture did.

What Actually Broke

Here's the part that matters more than the calendar date.

The Assistants API wasn't just an endpoint — it was a stateful abstraction. You created a thread, OpenAI stored the conversation server-side, and your app just held onto a thread_id and kept appending messages. OpenAI managed the memory. You managed almost nothing.

That felt great in 2024. Less code, less to think about, ship the chatbot in an afternoon.

It's also exactly why the sunset hurt. Your app's conversation history, your users' in-progress sessions, your business logic tied to "does this thread still exist" — none of it lived in your database. It lived in OpenAI's. When the endpoint died, so did the only copy of that state most teams had.

The Responses API fixes the technical problem. It's a stateless, input-items-in/output-items-out model, closer to how Claude's Messages API already works, and it adds native support for MCP, computer use, and deep research on top. Migration is real and well-documented. That's not the interesting part of this story.

The interesting part is that this exact pattern — vendor offers to hold your state, then reserves the right to stop holding it — isn't new, and it isn't going away. Assistants API is just the most recent, most public example. It ran for roughly two years as the recommended way to build a stateful chatbot on OpenAI's stack, onboarded a huge share of the early "AI wrapper" wave, and then it was gone in a single day once the clock ran out.

The Uncomfortable Part

Everyone in that thread is migrating the code. Almost nobody is migrating the lesson.

The lesson isn't "use the Responses API instead of Assistants." The lesson is: any vendor API that offers to hold your state for you is offering you a dependency you don't control the lifecycle of. Beta or not. It doesn't matter how good the docs are or how many companies are using it. If the memory of your product lives on someone else's server under someone else's deprecation policy, you don't own that product. You're renting it, and the lease can end on a date you didn't pick.

This isn't unique to OpenAI. It's the default shape of every "managed state" product any AI vendor ships, because managed state is what makes the demo look effortless. Anthropic's Agent SDK, Vercel's v0 API, every agent framework with a hosted memory layer — they're all making the same trade for you unless you actively opt out of it.

I'm not saying don't use hosted state. I'm saying know exactly what you're agreeing to when you do.

How I Build Around This

I don't let a vendor own the only copy of anything that matters.

When I built AgentTape, it was for the same reason, just a different failure mode. Claude Code sessions were ephemeral — once the terminal closed, the run was gone, nothing to replay or diff. I didn't wait for Anthropic to ship persistence. I wrote the sessions to a structured JSONL file on disk, on my machine, in a format I control.

Same instinct applies to any assistant-style product I ship now. Conversation history goes in Postgres, not a vendor's thread object. The model call is a stateless function: I hand it the full context I need it to have, it hands back output, and I'm the one who decides what gets persisted and for how long. If the provider changes tomorrow — new model, new API shape, new vendor entirely — the data survives because it was never theirs to sunset.

That's the same reasoning behind why tools like OpenCode refuse model allegiance instead of betting a whole product on one vendor's roadmap. Portability isn't paranoia. It's just refusing to hand a company a veto over your own product's memory.

// stateless call — I own persistence, the API owns nothing
const response = await client.responses.create({
  model: "gpt-5.6",
  input: buildContextFromMyDatabase(userId, sessionId),
});

await db.messages.insert({ userId, sessionId, response });

Seven lines. No thread object living on a server I don't control. Every migration this pattern has ever needed was a config change, not a rewrite.

What This Actually Costs You

Building it this way is more work up front. You write your own persistence layer instead of calling threads.create() and moving on. For a weekend project, that overhead isn't worth it — use the managed thread, ship the demo, don't overthink it.

For anything you plan to still be running in a year, the math flips. The few hours you spend owning your own state layer now is cheaper than the week you'll spend migrating a production app off a dead endpoint later, reading a 40-reply forum thread trying to figure out if your data is even still there.

There's a simple test I run before I let any product depend on a vendor's hosted state: if this endpoint disappeared tomorrow with no warning, what would I lose that I can't rebuild from my own data? If the honest answer is "the entire conversation history of every user," that's not a dependency, that's a liability with a really good demo attached.

OpenAI did everything right here, by the standard anyone should expect from a vendor. Full year of notice, a dated announcement, clear docs, a genuinely better replacement API waiting the whole time. And people still got burned, because the warning was about the endpoint, not about the architecture decision that made the endpoint load-bearing in the first place. You can't migration-guide your way out of a design choice you made two years before the deprecation notice even existed.

Read the deprecation notice. Then go check what you're trusting a vendor to remember for you.

Own your state. Rent the model.