OpenAI Assistants API is deprecated. Here is what does not survive the migration.

Baran Yalçın — Mon, 17 Aug 2026 13:03:06 +0000

The OpenAI Assistants API shuts down on 26 August 2026. After that, /v1/assistants, /v1/threads and /v1/threads/runs return errors. No grace period, no read-only mode.

There are already good guides on the mechanical side: how Assistant becomes a prompt, Thread becomes a conversation, Run becomes a response. This is the other half, the part the guides leave out. What you actually lose.

I build Glytos, which imports OpenAI assistants, so I had to map the Assistant object field by field and decide, for every one, where it goes or whether it goes at all. This is what came out of that.

What transfers cleanly

Pure configuration. Whatever you move to, these come with you:

instructions
model, temperature, top_p
response_format, including a strict json_schema
your function tool definitions: name, description, parameters

If your assistant is a prompt plus a model plus a schema, you are in the easy case and you can stop reading.

What does not

1. The endpoint behind every function tool

The one people underestimate, because the schema does transfer and that feels like success.

A function tool is two things. The schema, which tells the model the tool exists and what arguments it takes. And the implementation: the URL you call, the auth header, the timeout, the retry policy, the error mapping. Only the first lives in the Assistant object. The second has always lived in your code.

So after the migration you have an agent that knows it can call lookup_order and no idea how. Every tool gets rewired by hand. Fifteen tools is fifteen small integration jobs, and none of them appear on any migration checklist.

2. Your file_search content

Worth being precise, because it depends where you are going.

Vector stores are account-level objects. Move to the Responses API and they survive: you stop attaching them through tool_resources and start passing vector_store_ids to the file_search tool yourself. Annoying, not fatal.

Move anywhere else and you re-upload and re-chunk. That is not a byte-shuffling job. Different chunking, different embedding model, different retrieval defaults mean your agent gets different context for the same question. The files move. The answers may not.

3. code_interpreter, conditionally

Stay on the Responses API and it survives. It runs in a container, created automatically with "container": {"type": "auto"} or explicitly through the v1/containers endpoint.

Go anywhere else and there is no equivalent unless that platform runs its own sandbox. That is a rewrite, not a migration.

The part that actually costs you time

Not the state management everyone argues about in the threads.

The configuration moves and the behaviour does not. You can lift an assistant across in a minute, then spend two weeks working out why it answers differently, because retrieval shifted underneath it and nothing told you.

If you have an evaluation set, run it before and after. If you do not, write down five questions your agent gets right today and check them by hand on the other side. Five is enough to catch the ugly surprises.

Do this part today

Whatever you decide, get your definitions out while the API still answers. That configuration exists in exactly one place, and after the 26th there is nothing left to read it from.

from openai import OpenAI
import json

client = OpenAI()

# The SDK paginates automatically as you iterate.
assistants = [a.model_dump() for a in client.beta.assistants.list(limit=100)]

with open("assistants.json", "w") as f:
    json.dump(assistants, f, indent=2, default=str)

print(f"saved {len(assistants)} assistants")

Run it, commit the JSON, decide where it goes later. Retrieving them has a deadline. Choosing a destination does not.

Where this comes from

Disclosure, since it is why I did this mapping at all: Glytos is a platform for voice and chat agents, and importing OpenAI assistants is one of the things it does.

The flow is: connect your OpenAI key, pick which assistants to bring, read the report. The key authorises the single request that lists your assistants and is never written to our database.

Each assistant becomes an agent with its instructions, model settings and response format intact, strict json_schema included. Its function tools arrive as HTTP stubs, schema preserved, waiting for you to point each one at an endpoint.

The report is the part that matters. It is essentially this article generated against your own account: which tools still need a URL, which assistants had files you will have to re-upload, which had a code_interpreter that did not come across.

Two things it does not do. It does not bring your files, for the chunking reasons above. And the one-click path reads through OpenAI's API, so it stops working on the 26th along with everything else. After that it takes the JSON from the script above, which is the other reason to run that script today.

None of this is required for the migration itself. The export script is four lines, and that is the part with a deadline.

DEV Community: Baran Yalçın