Migrating off the OpenAI Assistants API before it shuts off (Aug 26, 2026)

On August 26, 2026 OpenAI turns off the Assistants API. /v1/assistants, /v1/threads, and /v1/threads/runs start returning errors that day. There's no grace period and no degraded mode, and OpenAI has said it won't ship a migration tool. Threads don't move over automatically either, so any conversation state you kept server-side is something you have to plan around, not port with a flag.

If your code still calls openai.beta.assistants or openai.beta.threads, this is the migration. Here's the mapping, the code changes, and how to make sure you didn't miss a call-site.

The concept swap

The new surface is the Responses API plus Conversations. Four things get renamed and, in one case, genuinely rethought:

The one that isn't just a rename is Run to Response. Runs were asynchronous: you created one, then polled runs.retrieve until the status left queued/in_progress. Responses give you the result in a single synchronous call. The polling loop goes away entirely.

Before and after

Python, the classic create-thread / add-message / poll-run shape:

# Before — Assistants

assistant = client.beta.assistants.create(model="gpt-4o", instructions="...")

thread = client.beta.threads.create()

client.beta.threads.messages.create(

    thread_id=thread.id, role="user", content="Summarize this ticket."

)

run = client.beta.threads.runs.create(

    thread_id=thread.id, assistant_id=assistant.id

)

while run.status in ("queued", "in_progress"):

    run = client.beta.threads.runs.retrieve(thread_id=thread.id, run_id=run.id)

# ...then read messages back off the thread

# After — Responses

response = client.responses.create(

    model="gpt-4o",

    instructions="...",

    input=[{"role": "user", "content": "Summarize this ticket."}],

)

print(response.output_text)

To keep multi-turn history, create a Conversation and pass its id instead of rebuilding the thread each time:

conversation = client.conversations.create()

response = client.responses.create(

    model="gpt-4o",

    conversation=conversation.id,

    input=[{"role": "user", "content": "And what changed since last week?"}],

)

The JS/TS SDK moves the same way: client.beta.threads.runs.create(...) becomes client.responses.create(...), and client.beta.threads.create() becomes client.conversations.create().

The parts that actually bite

A rename table makes this look mechanical. Three things aren't:

1. Existing Threads don't auto-migrate. If you stored thread_ids and treated them as durable conversation pointers, there's no endpoint that turns an old Thread into a Conversation. You decide what history matters, and either replay it into a new Conversation or drop it. Do this before the date, not on it.




2. Assistant config moves out of code. An assistant_id you created via the API maps to a Prompt object with its own versioning. That's a change to how config is stored and referenced, not a find-and-replace.




3. Tool wiring changes shape. Tool calls and their outputs are now Items in the response stream rather than steps hung off a Run. Anything that read run_steps to inspect tool activity needs rewriting against the items model.

None of these have a codemod. The migration guide is the source of truth for the exact request shapes: ) that does exactly the inventory-plus-CI-gate described above for JS/TS and Python; the migration itself is still hand-work.