OpenAI Evals Platform: read-only 31 октября 2026, shutdown 30 ноября — API, graders, миграция

3 июня 2026 г. OpenAI добавил в официальный трекер устаревания три позиции на уровне платформы, все с единой датой отключения — 30 ноября 2026 г.: Evals Platform, Agent Builder и Reusable Prompts (API v1/prompts). В отличие от устаревания model ID — которое, как правило, требует изменения одной строки в конфиге, — здесь речь идёт о выводе из эксплуатации инфраструктурных компонентов, влияющих на централизованное управление промптами, масштабную оценку выходных данных моделей и создание агентов Responses API без написания кода на SDK. Разберём каждое изменение и выясним, что переходит на routing- и gateway-слой после прекращения хостинга со стороны OpenAI.

Что OpenAI признал устаревшим 3 июня 2026 г.

Устаревание openai evals platform затрагивает три отдельных продукта:

Evals Platform: хостируемый OpenAI runner для eval — создание, запуск и оценка наборов тестов LLM через Dashboard или Evals API. С 31 октября переходит в режим read-only; с 30 ноября все запуски eval прекращаются.

Agent Builder: low-code / no-code интерфейс Dashboard для создания агентов Responses API (настройка инструментов, редактирование инструкций, тестирование). Сам Responses API (POST /v1/responses) не признаётся устаревшим — только UI Builder и сохранённые в нём объекты агентов.

Reusable Prompts (v1/prompts): эндпоинт POST /v1/prompts, позволявший командам хранить и версионировать шаблоны промптов на инфраструктуре OpenAI. Любое приложение, вызывающее /v1/prompts для получения сохранённого шаблона во время инференса, перестанет работать после 30 ноября.

Почему устаревание openai evals platform важно для операторов routing

Каждое из трёх изменений по-своему перекладывает ответственность на operator-слой.

Удаление v1/prompts API и управление промптами на стороне gateway

API Reusable Prompts предоставлял простейшую абстракцию: обратиться к OpenAI, получить сохранённый промпт, вставить в запрос. После отключения командам, полагавшимся на него для централизованного версионирования промптов — особенно в многокомандных сценариях с общей библиотекой промптов — потребуется другое место для хранения и подачи шаблонов во время инференса.

Естественным решением становится routing- и gateway-слой. AI gateway, перехватывающий исходящие запросы до их отправки, может инжектировать шаблоны промптов из версионированного хранилища. Это делает промпт-ресурсы переносимыми: один и тот же шаблон работает вне зависимости от того, какая модель стоит в конце цепочки — OpenAI, Anthropic или отечественный provider вроде DashScope. Для команд, уже использующих multi-provider routing для fallback или оптимизации стоимости, добавление инжекции промптов на gateway не создаёт лишнего сетевого скачка и повышает переносимость.

Дополнительный эффект: версионирование промптов в собственной инфраструктуре поддаётся аудиту. Хостируемое хранилище промптов OpenAI было «чёрным ящиком» для задач соответствия требованиям; хранилище на gateway-слое — полноценный артефакт в CI/CD-пайплайне.

Отключение Evals Platform и наблюдаемость на routing-слое

Evals Platform выполняла двойную функцию: автоматизированное бенчмаркирование перед деплоем и непрерывный мониторинг качества в продакшене. Её отключение не устраняет потребность — оно меняет владельца.

Наиболее значимое следствие для routing — покрытие онлайн-eval. Команды, использовавшие Evals для выявления регрессий при смене версий моделей, должны перенести этот сигнал в другое место. Два подхода органично встраиваются в routing-слой:

1. Routing сравнения моделей с теневым трафиком: направить настраиваемую долю live-трафика на модель-кандидат в теневом режиме, сравнивать выходные данные с эталонной моделью и логировать расхождения — без какой-либо хостируемой инфраструктуры eval от OpenAI.
2. Структурированные eval-пайплайны через Promptfoo и аналоги: запускать наборы eval напрямую против эндпоинта /v1/chat/completions TheRouter, охватывая полные цепочки fallback и логику выбора provider, а не оценивая единственную модель.

Долгосрочная цель — миграция routing-слоя при отключении openai evals platform и agent builder в ноябре 2026 г. — сводится к двум действиям: перевести выполнение eval на open-source фреймворк, а маршрутизацию eval (какое семейство моделей оценивать?) передать gateway.

Закрытие Agent Builder и разработка агентов на основе SDK

Agent Builder был инструментом повышения продуктивности, а не runtime-зависимостью. Командам, использовавшим его для прототипирования цепочек вызовов инструментов, наборов инструкций и логики передачи управления, потребуется перенести эти конфигурации непосредственно в SDK Responses API. Базовый Responses API (POST /v1/responses) не затронут.

Из трёх изменений это наименее разрушительное для команд, уже пишущих продакшен-агенты в коде. Для команд, активно использовавших UI Builder для настройки агентов нетехническими сотрудниками, закрытие вынуждает перестроить процессы: конфигурация агентов переходит в версионируемый код, а не остаётся в Dashboard.

С точки зрения routing это повышает переносимость агентов по умолчанию. Агент, определённый в SDK-коде с явными model ID и списками fallback, одинаково работает через любой OpenAI-совместимый gateway; агент, существовавший только как объект, сохранённый в Builder, был неявно привязан к инфраструктуре OpenAI.

Чеклист миграции до 30 ноября 2026 г.

Используйте этот чеклист для оценки и расстановки приоритетов до даты перехода Evals в read-only 31 октября:

1. Проверьте использование v1/prompts. Найдите в кодовой базе и логах API вызовы /v1/prompts. Для каждого: определите prompt ID, экспортируйте сохранённый шаблон и выберите замену (инжекция на gateway-стороне, secrets manager или специализированный реестр промптов).

2. Экспортируйте конфигурации Evals до 31 октября. Evals Platform переходит в read-only 31 октября 2026 г. До этой даты экспортируйте все определения eval, grader'ы и данные исторических запусков. После 31 октября — только чтение; после 30 ноября — полный запрет доступа.

3. Проведите инвентаризацию агентов Agent Builder. Перечислите всех агентов, созданных в Agent Builder, скачайте их инструкции и конфигурации инструментов, конвертируйте в вызовы SDK Responses API. Убедитесь, что каждый агент работает end-to-end до 30 ноября.

4. Выберите замену для eval-фреймворка. Promptfoo, LangSmith и Braintrust нативно поддерживают OpenAI-совместимые эндпоинты. Если в routing-конфигурации используются multi-provider fallback, направьте eval-фреймворк на эндпоинт gateway, а не напрямую к OpenAI — чтобы eval охватывал полный routing-путь.

5. Установите внутренний дедлайн 15 октября. Отключение 30 ноября совпадает с периодом заморозки изменений в конце Q4 у многих организаций. Внутренние политики заморозки в октябре–ноябре сокращают фактическое окно миграции. Целевой срок завершения — первая половина октября.

6. Для v1/prompts: протестируйте инжекцию промптов на стороне gateway. Если хранилище промптов перемещается на gateway-слой, убедитесь, что содержимое инжектируемых промптов стабильно для разных локалей и семейств моделей — особенно для команд, маршрутизирующих запросы к non-OpenAI provider'ам, где соглашения о форматировании system prompt могут незначительно различаться.

Примечание: миграция openai v1 prompts API на gateway

Путь openai v1 prompts api migration gateway стоит рассматривать как архитектурное решение, а не просто поиск замены. Централизация промптов в хостируемом хранилище OpenAI, как правило, была обусловлена необходимостью единого источника истины для множества сервисов. Воссоздание этой возможности на gateway-слое — вместо возврата промпт-строк в отдельные кодовые базы приложений — сохраняет исходный замысел при устранении зависимости от OpenAI.

Хранилище промптов на gateway-стороне также органично сочетается с multi-provider routing: при деградации качества или сбое у одного provider fallback-цепочка переключается на другую модель, но шаблон промпта остаётся неизменным и больше не привязан к инфраструктуре конкретного provider.

Временна́я шкала

Пять месяцев до отключения — достаточный срок для чистой миграции при условии, что аудит начат сейчас. Переход Evals в read-only 31 октября — ключевой триггер: именно его стоит рассматривать как внутренний мягкий дедлайн, а не 30 ноября.