OpenAI Assistants API отключается 26 августа 2026: чеклист миграции на Responses API

OpenAI Assistants API закрывается 26 августа 2026 года — через 56 дней. Если ваша команда использует в продакшне threads, runs, file search или code interpreter, после этой даты все вызовы начнут возвращать ошибки — без graceful fallback и без исключений. Замена — Responses API, который сейчас поддерживает полный feature-set: deep research, MCP-подключения и computer use.

Что произошло

OpenAI объявил об устаревании Assistants API beta после достижения feature parity в Responses API. Причина архитектурная: Assistants связывал выбор модели, инструкции и описание инструментов в персистентные серверные объекты (Assistants), которые также управляли состоянием выполнения (Threads, Runs). Responses API разделяет эти задачи — каждый запрос несёт собственные параметры, которыми может управлять ваш routing-слой.

Соответствие между API:

Responses API использует тот же селектор модели, что и chat completions — существующая routing-политика (fallback цепочки, latency-тиры, cost-пороги) применяется напрямую к stateful agent-сессиям.

Почему это важно для AI-инженерных команд

Выбор модели становится per-request. В Assistants API модель была зафиксирована в объекте Assistant. Смена модели требовала обновления объекта и могла инвалидировать кешированное состояние. В Responses API модель — параметр каждого запроса: routing-слой может переключать provider, понижать tier в пиковой нагрузке или выбирать модель по стоимости — без изменения конфигурационных объектов.

Версионирование Prompt заменяет статические системные инструкции. Prompt — управляемый из дашборда объект с поддержкой snapshot-версионирования. A/B-тестирование поведенческих профилей реализуется заменой prompt_id в коде — без создания или удаления объектов, без инвалидации состояния. Это паттерн, который точно ложится на gateway-level routing: Prompt ID как версионированный поведенческий контракт, выбор модели как runtime-решение.

Tool loop становится явным. Assistants абстрагировал выполнение инструментов через polling Runs. Responses API требует управлять tool loop напрямую: получать tool calls из output item-ов, выполнять их и возвращать результаты как input item-ы. Эта явность позволяет routing-прокси перехватывать, логировать и маршрутизировать выполнение инструментов так же, как обычные model-вызовы.

Conversations хранят контекст между сессиями. Threads хранили только сообщения; Conversations хранят item-ы (сообщения, tool calls, tool outputs). Для stateful agent-воркфлоу это устраняет необходимость вести параллельное состояние разговора в собственной базе данных.

Угол routing и operator

Assistants API был архитектурно враждебен routing-прокси. Выбор модели был вшит в объект Assistant, состояние выполнения жило в Threads и Runs — прокси не мог перехватить или изменить routing-решения, не взяв на себя весь жизненный цикл Assistants.

Responses API устроен иначе: параметр модели присутствует в каждом запросе, схемы инструментов берутся из версионированного Prompt, выполнение синхронное. Роутер перед API применяет ту же логику, что к chat completions: выбор provider, fallback-цепочки, retry-политики, учёт использования — без потери состояния.

Для команд с multi-provider-архитектурой это критично: параметр model в Responses API принимает любой идентификатор модели, который умеет разрешать ваш router. Можно маршрутизировать первые повороты разговора на дешёвую модель, на середине сессии поднять tier при детектировании сложности и упасть на резервный provider при недоступности основного — и всё это без того, чтобы объект Assistant владел выбором модели.

Аудит до 26 августа — что проверить:

1. Найдите все вызовы Assistants API. Ищите в кодовой базе openai.beta.threads, openai.beta.assistants, openai.beta.runs, сохранённые Assistant ID и Thread ID — любое использование Assistants beta затронуто.
2. Определите Thread-состояние, которым вы владеете. Если вы храните Thread ID и ссылаетесь на них между сессиями, спланируйте миграцию: Conversations имеют другой формат ID и структуру item-ов.
3. Проведите аудит определений инструментов. Перенесите схемы инструментов в версионированные Prompt в дашборде. Код должен ссылаться на prompt_id, а не содержать инлайновые определения инструментов.
4. Проверьте совместимость routing-прокси. Если вы проксируете вызовы OpenAI API, убедитесь, что прокси корректно обрабатывает формат запросов/ответов Responses API — он отличается как от chat completions, так и от Assistants beta endpoint.
5. Отдельно уточните timeline Azure OpenAI. Azure управляет собственным расписанием вывода из эксплуатации; дата 26 августа применима к платформе OpenAI API. Проверьте документацию Azure для получения актуальных дат.

Что стоит проверить или попробовать пользователям TheRouter

Параметр model в Responses API совместим с любым OpenAI-совместимым routing-шлюзом. Если вы используете gateway TheRouter с OpenAI в качестве backend, путь миграции для вызовов Responses API такой же, как для chat completions: обновите base URL, сохраните заголовок Authorization — и ваша текущая routing-политика (fallback модели, выбор provider, retry-логика) заработает автоматически.

Ознакомьтесь с документацией TheRouter по настройке маршрутизации через OpenAI-совместимых provider-ов. Команды, мигрирующие workload с Assistants API, должны до 26 августа протестировать end-to-end прохождение tool call flow через routing-слой — явный tool loop в Responses API делает перехват, логирование и маршрутизацию вызовов инструментов на уровне прокси простой задачей.

56 дней — достаточное окно для большинства миграций, но только при условии, что аудит начинается сейчас. Команды, которые подождут до августа, столкнутся с дедлайном в условиях жёсткого давления.