OpenAI Assistants API Shuts Down August 26: Final Migration Checklist

The Assistants API hard-shuts on August 26, 2026 — 14 days from today. After that date, every openai.beta.assistants.* and openai.beta.threads.* call returns an error. No extensions have been announced (OpenAI deprecations page, retrieved 2026-08-12).

We published a conceptual migration guide in June. This post is the operational companion: a checklist you can hand to your team and work through in the 14 days remaining. Every step has a verify command or a concrete test you can run.

What happens on August 27

After the shutdown, all Assistants API endpoints return HTTP errors. Thread history stored server-side becomes inaccessible through the Assistants API. If you have not exported thread messages before the cutoff, that data is gone — OpenAI has not committed to a post-shutdown data export window (OpenAI Assistants migration guide, retrieved 2026-08-12).

The Responses API is the replacement. Chat Completions remains supported and is not affected by this shutdown (Migrate to Responses API guide, retrieved 2026-08-12).

Object map: Assistants to Responses

Before touching code, internalize the naming changes:

Source: OpenAI Assistants migration guide, retrieved 2026-08-12.

The Prompts deprecation trap

OpenAI's migration guide suggests converting Assistants into Prompts through the dashboard. However, reusable Prompt objects are also deprecated, with shutdown scheduled for November 30, 2026 (OpenAI deprecations page, retrieved 2026-08-12).

If you migrate Assistants to Prompts now, you will need to migrate again in three months. The safer path: move Assistant configuration (instructions, tool schemas, temperature, model choice) directly into your application code or a config file under version control. Skip the Prompts detour entirely.

Checklist: 14 days to cutover

Step 1 — Audit every Assistants callsite

Run a grep across your codebase:

grep -rn "openai\.beta\.\(assistants\|threads\)" \
  --include="*.py" --include="*.ts" --include="*.js" \
  app/ services/ workers/ scripts/ lib/

For each match, classify it:

• A — New-session chat. No thread history dependency. Migrate first.
• B — Long-lived thread. Needs thread export before shutdown. Schedule the backfill.
• C — Tool-heavy agent. Requires explicit tool-loop rewrite. Highest effort.
• D — File search / code interpreter. Verify Responses API tool equivalents work for your use case.

Step 2 — Export thread history now

Do not wait. Threads become inaccessible after shutdown. Export every active thread:

import json
from openai import OpenAI

client = OpenAI()

def export_thread(thread_id: str) -> list[dict]:
    messages = []
    for page in client.beta.threads.messages.list(
        thread_id=thread_id, order="asc"
    ).iter_pages():
        messages.extend(page.data)
    return [m.model_dump() for m in messages]

# Export all threads you care about
thread_ids = ["thread_abc123", "thread_def456"]
for tid in thread_ids:
    data = export_thread(tid)
    with open(f"export_{tid}.json", "w") as f:
        json.dump(data, f, indent=2)
    print(f"Exported {len(data)} messages from {tid}")

Verify: confirm each exported file contains the expected message count and content.

Step 3 — Migrate new sessions to Responses

The simplest migration path: stop creating new Assistants and Threads. New user chats go through the Responses API directly.

Before (Assistants):

thread = client.beta.threads.create()
client.beta.threads.messages.create(
    thread_id=thread.id,
    role="user",
    content="Explain API routing"
)
run = client.beta.threads.runs.create_and_poll(
    thread_id=thread.id,
    assistant_id="asst_xxx"
)
messages = client.beta.threads.messages.list(thread_id=thread.id)
answer = messages.data[0].content[0].text.value

After (Responses):

response = client.responses.create(
    model="gpt-5.5",
    instructions="You are a helpful API routing expert.",
    input="Explain API routing"
)
answer = response.output_text

For multi-turn, pass previous_response_id or use Conversations:

# First turn
resp1 = client.responses.create(
    model="gpt-5.5",
    input="What is API routing?"
)

# Second turn — chained
resp2 = client.responses.create(
    model="gpt-5.5",
    input="How does fallback work?",
    previous_response_id=resp1.id
)

Step 4 — Rewrite tool loops

Assistants ran tools server-side with a polling loop. The Responses API makes tool execution explicit: you receive tool_call items, run them yourself, and feed results back.

Before (Assistants tool loop):

run = client.beta.threads.runs.create(
    thread_id=thread.id,
    assistant_id="asst_xxx"
)
while run.status in ("queued", "in_progress"):
    time.sleep(1)
    run = client.beta.threads.runs.retrieve(
        thread_id=thread.id, run_id=run.id
    )
if run.status == "requires_action":
    tool_calls = run.required_action.submit_tool_outputs.tool_calls
    outputs = [execute_tool(tc) for tc in tool_calls]
    run = client.beta.threads.runs.submit_tool_outputs_and_poll(
        thread_id=thread.id,
        run_id=run.id,
        tool_outputs=outputs
    )

After (Responses tool loop):

response = client.responses.create(
    model="gpt-5.5",
    instructions="You are a helpful assistant.",
    input="What is the weather in Tokyo?",
    tools=[{
        "type": "function",
        "name": "get_weather",
        "description": "Get current weather",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {"type": "string"}
            },
            "required": ["location"]
        }
    }]
)

# Check for tool calls in output
for item in response.output:
    if item.type == "function_call":
        result = execute_tool(item.name, json.loads(item.arguments))
        # Feed result back
        response = client.responses.create(
            model="gpt-5.5",
            previous_response_id=response.id,
            input=[{
                "type": "function_call_output",
                "call_id": item.call_id,
                "output": json.dumps(result)
            }]
        )

Step 5 — Backfill critical thread history into Conversations

Use the export from Step 2 to populate Conversations for threads that need continuity:

import json

def backfill_thread_to_conversation(export_path: str) -> str:
    with open(export_path) as f:
        messages = json.load(f)

    items = []
    for m in messages:
        role = m["role"]
        for content_block in m["content"]:
            if content_block["type"] == "text":
                content_type = (
                    "input_text" if role == "user" else "output_text"
                )
                items.append({
                    "role": role,
                    "content": [
                        {"type": content_type, "text": content_block["text"]["value"]}
                    ]
                })

    conversation = client.conversations.create(items=items)
    return conversation.id

Script adapted from OpenAI Assistants migration guide, retrieved 2026-08-12.

Verify: after backfill, send a test message through the Conversation and confirm the model has context from the imported history.

Step 6 — Handle file search and code interpreter

Both tools exist in the Responses API, but the interface changed:

• File search: vector stores still work. The Responses API returns file_search_call items with results, and message items include annotation objects pointing to source files. You no longer poll for run steps — results arrive in the response output (OpenAI File search guide, retrieved 2026-08-12).
• Code interpreter: similarly returns code_interpreter_call items in the output. Sandbox execution happens server-side; results include text output and generated files.

Test both with a known query before production cutover.

Step 7 — Run integration tests

Write tests that cover:

1. Simple text generation (no tools)
2. Multi-turn conversation with previous_response_id
3. Tool calling with at least one function
4. File search with a known vector store
5. Streaming with SSE event handling
6. Error handling (rate limits, invalid model, malformed input)

Shadow-run both old and new paths for 24–48 hours. Compare latency, output quality, and error rates before cutting over.

Step 8 — Cut over with a feature flag

Ship the Responses migration behind a feature flag. The rollout sequence:

1. Enable for internal/staging traffic
2. Enable for 10% of production traffic, monitor for 24 hours
3. Ramp to 50%, then 100%
4. Remove Assistants API code after 1 week of clean production

Keep the Assistants code path available until August 26 as a rollback option. After that date, it cannot serve as rollback — remove it.

Azure OpenAI users

Azure OpenAI has confirmed the same August 26, 2026 shutdown date for Assistants API (Microsoft Learn, retrieved 2026-08-12). The migration path is identical: Responses API with Conversations.

Azure-specific notes:

• Deployment names stay the same; the API version changes
• Check your Azure API version supports the Responses endpoint
• Azure Content Safety filters apply to Responses the same way they applied to Assistants

Routing gateway considerations

If you route OpenAI requests through a gateway like TheRouter, test these paths specifically:

• /v1/responses endpoint — verify your gateway forwards Responses-shaped requests correctly
• Streaming — Responses SSE events have a different shape than Chat Completions chunks
• Tool calls — the function_call and function_call_output item types differ from Chat Completions tool_calls
• Fallback routing — if your gateway falls back from OpenAI to another provider, the fallback target must also support the Responses API shape or your gateway must translate it

TheRouter routes OpenAI-compatible requests through configured providers and supports provider/model routing and fallback where the live product path supports it. Test your specific model and tool combinations before production cutover.

1. Swap three values, not three SDKs. Change api_key, base_url, and model in the existing OpenAI client. Keep your request/response code unchanged.
2. Map model IDs explicitly. The target provider's model id is almost never identical to the OpenAI id. Keep a single dict of { openai_id: target_id } outside business logic.
3. Verify streaming format. SSE chunks must follow the OpenAI data: {...} + data: [DONE] contract. Test one streaming call before moving production traffic.
4. Check rate-limit headers. Some providers omit x-ratelimit-* headers. Add a wrapper that defaults safely when headers are absent.
5. Keep a rollback path. Ship the swap behind a feature flag, run both endpoints in shadow for 24 hours, then cut over.

Timeline summary

FAQ

Q: Will Chat Completions also shut down? No. Chat Completions remains supported. The Responses API is recommended for new projects, but Chat Completions is not deprecated (Migrate to Responses API guide, retrieved 2026-08-12).

Q: Can I get a deadline extension? OpenAI says developers may be able to provision dedicated capacity for continued access. Contact their sales team to explore this option (OpenAI deprecations page, retrieved 2026-08-12). No public extension has been announced.

Q: What happens to my vector stores? Vector stores remain accessible. The Responses API file search tool uses the same vector store infrastructure. You do not need to re-upload files.

Q: Should I use Conversations or manage state client-side? If your sessions are short-lived (single task, no multi-day continuity), manage state client-side with previous_response_id. If sessions span days or weeks with users returning to ongoing chats, use Conversations for server-side persistence.

Q: What about the Python/Node SDK? Both official SDKs already support client.responses.create(). Update your SDK to the latest version. The openai.beta.* namespace will stop working after August 26.

Sources

• OpenAI Assistants migration guide, retrieved 2026-08-12
• OpenAI deprecations page, retrieved 2026-08-12
• Migrate to the Responses API, retrieved 2026-08-12
• OpenAI File search guide, retrieved 2026-08-12
• Azure OpenAI Assistants API deprecation confirmation, retrieved 2026-08-12