AIREITERДо отключения Assistants API 26 августа 2026 года главная ошибка — считать миграцию простой заменой названий. О завершении работы API OpenAI сообщил за год, в уведомлении от 26 августа 2025 года; заменой станет Responses API. На схеме соответствия объектов всё выглядит прямолинейно, но внутренняя оркестрация меняется заметно сильнее. Даже команды, внимательно прошедшие официальную инструкцию по миграции, столкнулись с поломками в продакшене. Ниже — что именно перестанет работать, какие нюансы скрыты за формальными маппингами и как действовать при любом оставшемся запасе времени.
Что отключится 26 августа 2026 года — и что останется
После дедлайна ошибки начнут возвращать все семейства эндпоинтов Assistants. Отключение затронет /v1/assistants, /v1/threads, сообщения тредов, runs и run steps, включая запросы с заголовком OpenAI-Beta: assistants=v2. Конфигурации ассистентов и история тредов станут недоступны через API.
При этом не всё, что связано с интеграцией Assistants, исчезнет:
| Перестанет работать 26 августа 2026 года | Останется доступным |
|---|---|
CRUD-эндпоинты /v1/assistants | Векторные хранилища и загруженные файлы — их можно повторно использовать через file search в Responses |
/v1/threads и сообщения тредов | Chat Completions API — его отключение не касается |
| Runs и run steps | Responses API и Conversations API |
Сценарии с OpenAI-Beta: assistants=v2 | Realtime API |
В собственном трекере устаревающих продуктов OpenAI указывает Responses и Conversations как целевую замену:
Чем заменить объекты Assistants: два нюанса, меняющих архитектуру
В руководстве по миграции OpenAI сопоставляет четыре ключевых понятия Assistants с объектами новой модели:
| Assistants API | Замена | Что меняется на практике |
|---|---|---|
Assistants | Prompts | Конфигурация переезжает в версионируемый объект, создаваемый в дашборде |
Threads | Conversations | Хранят обобщённые items: не только сообщения, но и вызовы инструментов с результатами |
Runs | Responses | Цепочка create-run-poll-retrieve сворачивается в один вызов responses.create |
Run steps | Items | Объединённый тип для сообщений, вызовов функций и результатов |
Сокращение цикла видно в официальных примерах: завершённый run на gpt-4.1 показывает 34 prompt tokens и 130 completion tokens, а завершённый response на gpt-5.5 — 17 input tokens и 150 output tokens. Нагрузка схожая, но названия полей другие.
И это первый важный нюанс. Дашборды биллинга и парсеры payload, завязанные на старые поля usage, могут тихо перестать собирать данные:
| Поле Assistants | Поле Responses |
|---|---|
usage.prompt_tokens | usage.input_tokens |
usage.completion_tokens | usage.output_tokens |
max_completion_tokens / max_prompt_tokens | max_output_tokens |
truncation_strategy | truncation |
object: "thread.run" | object: "response" |
Второй нюанс касается архитектуры. Prompts создаются только в дашборде, а не через API. Это ломает системы, которые динамически создают отдельный Assistant для каждого клиента, рабочего пространства или набора документов. В официальном руководстве отдельно советуют проверить сроки прекращения поддержки prompts, прежде чем строить на них долгоживущую интеграцию: у переиспользуемых prompt-объектов есть собственный риск устаревания. Более устойчивый подход — хранить instructions, схемы инструментов и выбор модели в собственном исходном коде и передавать их в каждом запросе. О переносе истории тредов позиция OpenAI предельно однозначна: "We will not provide an automated tool for migrating Threads to Conversations."
Как перенести встроенные инструменты
Для каждого инструмента Assistants в Responses предусмотрен конкретный путь, но часть обязанностей переходит в ваше приложение:
| Инструмент Assistants | Как выглядит в Responses | Что теперь отвечает приложение |
|---|---|---|
| File search | Векторные хранилища сохраняются; передавайте vector_store_ids в определении инструмента для каждого запроса | Определение правильных ID хранилищ до вызова API |
| Code interpreter | Контейнер настраивается через type: "auto" | Жизненный цикл контейнера |
| Functions | Вложенный ключ function убран; name, description и parameters подняты на уровень выше | Цикл инструментов: выполнить вызов, вернуть результат с соответствующим call_id, решить, нужен ли следующий цикл |
Для мультитенантных приложений незаметнее всего, но важнее всего меняется file search. Раньше привязать по одному векторному хранилищу на тенанта можно было при настройке объекта Assistant. Теперь приложение должно до отправки запроса определить, какие ID хранилищ соответствуют владельцу входящей сессии.
На чём споткнулись команды, уже завершившие миграцию
OpenAI объясняет замену тем, что Responses достиг функционального паритета. Отчёты о миграции показывают: на уровне объектов паритет есть, но под ним скрывается полноценный рефакторинг. Владелец мультитенантного SaaS-чатбота описал на r/aiagents двухнедельный переход, и проблемы возникли даже при точном следовании официальному гайду:
Мне пришлось переделать все необязательные поля в
["type", "null"]— ощущается как обходное решение для системы типов. — u/aidenclarke_12
Строгие схемы инструментов требуют объявлять необязательные свойства nullable и одновременно включать их в required. Схемы становятся объёмнее, а каждый обработчик, считавший отсутствие поля значимым, приходится перепроверять. Тот же разработчик отметил, где находится более глубокое изменение:
изменение логики работы с vector store — вот настоящий архитектурный сдвиг. — u/aidenclarke_12
Вторая незаметная точка отказа — стриминг. Стриминг runs из Assistants нельзя просто адаптировать под Responses: его нужно переписать под типизированные server-sent events, такие как response.created, response.output_text.delta, response.completed и response.function_call_arguments.delta / .done. Появляются явные события завершения и новые форматы событий вызова инструментов; их перечень приведён в обзоре миграции. Переделка нужна и SSE-прокси, и клиентским обработчикам, включая логику переподключения.
Третья проблема относится не столько к API, сколько к отставанию экосистемы:
Responses API доступен уже давно, но многие фреймворки и SDK его всё ещё не поддерживают. — u/zhlmmc
Если ваш стек построен на агентском фреймворке, который всё ещё предполагает модель Threads/Runs, с которой столкнулся u/zhlmmc, заложите время не только на собственный связующий код, но и на этот слой.
Как хранить контекст: цепочка Responses, Conversations или ручное воспроизведение
В Responses есть три способа сохранить контекст многоходового диалога, и они не взаимозаменяемы:
| Стратегия | Подходит для | На что обратить внимание |
|---|---|---|
previous_response_id | Самой простой цепочки с минимумом изменений | Предыдущий контекст остаётся тарифицируемым входом |
| Conversations API | Ближайшего аналога Threads с серверной историей | Бэкофилл придётся реализовать самостоятельно: готового инструмента нет |
Ручное воспроизведение, store: false | ZDR и строгих требований к хранению данных | Всё состояние находится на вашей стороне; reasoning items нужно передавать дальше |
Для переноса старого треда OpenAI рекомендует следующую последовательность:
- Получите список сообщений треда в порядке возрастания.
- Преобразуйте каждое текстовое сообщение пользователя в
input_text. - Преобразуйте каждое текстовое сообщение ассистента в
output_text. - Преобразуйте контент с URL изображения в
input_image, сохранивimage_urlиdetail. - Создайте Conversation из преобразованных
items.
Ошибка в сопоставлении ролей приводит к вполне конкретному эффекту: модель воспринимает собственные прошлые ответы как новые инструкции пользователя. По умолчанию stored responses хранятся 30 дней, если не передать store: false. Conversations не подпадают под этот TTL, и на конец июля 2026 года для них не был отдельно опубликован срок хранения, как отмечается в материале, отслеживающем миграцию. Это важно, если в ваших раскрытиях данных указан срок удаления.
Как миграция повлияет на расходы на токены
Здесь важны два факта о тарификации.
Во-первых, previous_response_id — это удобство, а не скидка. В руководстве по переходу на Responses OpenAI прямо указывает, что токены предыдущего ввода в цепочке responses по-прежнему тарифицируются как input tokens. Без сокращения контекста длинные диалоги будут линейно дорожать.
Во-вторых, кэшированный ввод намного дешевле некэшированного: по состоянию на июль 2026 года — примерно десятая часть цены входных токенов во всех тарифных уровнях GPT-5.x. Во внутреннем тестировании OpenAI Responses показал на 40–80% лучшее использование кэша по сравнению с Chat Completions, согласно сводному обзору. Считайте этот диапазон данными поставщика, пока его не подтвердят ваши собственные дашборды. Важнее всего сравнить число токенов на сессию до и после переключения.
Если миграция совпадает с пересмотром стоимости нагрузки на GPT-5.x, в разборе цен GPT-5.6 есть расчёты по токенам, а OpenAI-совместимые эндпоинты, включая страницу GPT-5.6 API, позволяют напрямую сравнить аналогичные нагрузки в стиле Responses.
План миграции в зависимости от оставшегося времени
Осталось 1–6 дней. Сначала сделайте резервную копию: получите список assistants и vector stores с limit=100, скачайте файлы, сериализуйте объекты SDK через model_dump(). В материалах о резервном копировании отмечено важное ограничение: эндпоинта для вывода списка тредов нет, поэтому экспортировать получится только те ID тредов, которые уже хранило ваше приложение. Затем переключайтесь за флагом: новые сессии сразу направляйте в Responses, а старые треды переносите лениво — лишь когда пользователь снова их откроет.
Осталась неделя или больше. Прежде чем трогать остальные сценарии, полностью переведите один поток с низким риском. Пересоберите цикл инструментов и убедитесь, что результат каждой функции содержит соответствующий call_id. Замените обработку стриминга на ветвление по типам событий, затем сравните с базовой версией на Assistants поведение, задержки, расход токенов и частоту ошибок — и только после этого расширяйте трафик.
Дедлайн уже прошёл. Эндпоинты будут возвращать ошибки, а конфигурации ассистентов исчезнут с API-стороны. Восстановление возможно только по данным вашей базы и резервных копий; vector stores и файлы при этом остаются доступными через file search.
Главный компромисс здесь такой: вместо серверного жизненного цикла с polling, truncation и циклом инструментов вы получаете модель одного вызова, где оркестрация видна и поддаётся тестированию. Разработчик, выпустивший решения на обоих API, сформулировал это так:
Responses API — удачный компромисс: он берёт на себя тяжёлую работу, но остаётся достаточно гибким для собственной функциональности. — u/landongarrison
FAQ: отключение OpenAI Assistants API
Chat Completions API тоже отключат?
Нет. Chat Completions не входит в отключение 26 августа 2026 года. OpenAI предлагает переносить такие сценарии в Responses постепенно, по одному потоку, а не требует сделать это к обязательному дедлайну.
Перенесёт ли OpenAI мои существующие треды автоматически?
Нет. В официальном руководстве прямо сказано: "We will not provide an automated tool for migrating Threads to Conversations." Бэкофилл нужно реализовать в коде приложения, следуя описанной выше последовательности преобразования items.
Можно ли пользоваться Assistants API после 26 августа 2026 года?
Нет. После этой даты ошибки будут возвращать assistants, threads, messages, runs и run steps, включая сценарии с assistants=v2. Всё необходимое нужно экспортировать до дедлайна.
Истекает ли срок хранения stored responses?
Да. По умолчанию stored responses хранятся 30 дней, если не передать store: false. По данным на июль 2026 года conversations не подпадают под этот TTL.
Обязательно ли переносить конфигурацию ассистента в Prompts?
Нет, а для динамически создаваемых ассистентов этого делать не стоит. Prompts создаются только в дашборде, и официальное руководство само рекомендует проверять их на предмет будущего устаревания. Надёжнее хранить instructions и схемы инструментов в исходном коде и передавать их с каждым запросом.