DeadAI Dev Tools

OpenAI Assistants API (beta)

by OpenAI

Announced

2025-08-26

Complete

2026-08-26

Refund window closes

—

Refund status

No refund applicable

The Assistants API was OpenAI's first stateful, server-side agent primitive. It shipped in beta at DevDay in November 2023 and gave developers hosted Threads, Runs, and Assistant objects, so conversation state, tool wiring and file search lived on OpenAI's servers instead of in your own database. OpenAI announced its deprecation on August 26, 2025 and shut it down one year later, on August 26, 2026. It never left beta. The replacement is split across two newer endpoints: the Responses API for model calls and tool use, and the Conversations API for the persistent state that Threads used to hold.

Refund flow

1
Not applicable. The OpenAI API is pay-as-you-go and billed per token, so there was no pre-paid credit balance tied specifically to the Assistants endpoints.
2
If you were billed for Assistants calls after the August 26, 2026 sunset, that is a billing error rather than a refund category. Open a ticket at help.openai.com with the invoice line and the request IDs.

Migration path

Recommended successor

Responses API (model calls + tools) plus Conversations API (persistent state)

Why this is the closest fit

These two endpoints are the direct successors OpenAI names in its own migration guide. Between them they cover what the Assistants API did: the Responses API handles the model call, tool use and file search, and the Conversations API holds the multi-turn state that Threads used to own.

What differs from the original

The object model changes, so this is not a drop-in base-URL swap. There is no Assistant object to create and no Run object to poll for status. A Thread becomes a Conversation, and instead of creating a run against a thread you send input items to the Responses API and read output items back. Assistant-level configuration that used to be stored server-side once (model, instructions, tool list) moves into the request, or into your own config. Anything that polled run status, or read run steps to trace tool calls, has to be rewritten rather than remapped.

Alternatives by use case

Straight port of an existing Assistants integration

Responses API plus Conversations API, the path OpenAI documents and the only one that keeps hosted state

You only ever used single-turn calls and ignored Threads

Chat Completions, still supported and a smaller rewrite than adopting Conversations

You want conversation state in your own database

Responses API with state stored locally, which removes the hosted-state dependency that made this deprecation painful

What this tool meant

The Assistants API was OpenAI's bet that agent state belonged on the provider's servers. Threads, Runs and hosted file search meant a developer could ship a stateful assistant without running a database or a retrieval stack. That convenience was also the trap: teams that leaned hardest on hosted Threads had the most to rewrite when the endpoint went away, because the state they depended on lived somewhere they did not control and could not export into a like-for-like replacement. It stayed in beta for its entire life, from November 2023 to August 2026, which in hindsight was the clearest available signal about how much to build on it. The lesson generalises past OpenAI. When a provider offers to hold your application state, the migration cost of that convenience is real and it lands on a date the provider picks.