OpenAI отключит GPT-5.1 и GPT-5.3-Codex: как подготовить миграцию API

OpenAI 1 октября 2026 года добавила в список upcoming deprecations сразу несколько моделей, которые используются в разных типах production-нагрузки. gpt-5.3-codex, gpt-5.1 и gpt-5.4-nano должны стать недоступны через API 1 апреля 2027 года. Отдельно объявлено отключение нескольких TTS-моделей 6 января 2027 года. Это не остановка OpenAI API как сервиса и не означает, что перечисленные модели перестали работать уже сейчас: между объявлением deprecation и shutdown оставлено окно для миграции.

Для production-системы это принципиальное различие. Пока модель только deprecated, можно запускать новый маршрут параллельно со старым, сравнивать результаты и сохранять быстрый rollback. После shutdown старый model ID перестаёт быть рабочей страховкой, поэтому переносить проверку на последние дни — плохая стратегия.

Что именно отключает OpenAI и в какие сроки

На 6 октября 2026 года официальная таблица OpenAI задаёт четыре ключевых направления миграции.

Текущий workload	Deprecated model	Shutdown	Официальная замена
Агентная работа с кодом	gpt-5.3-codex	01.04.2027	gpt-6-sol
Общие reasoning/agentic-задачи	gpt-5.1	01.04.2027	gpt-6-sol
Массовая классификация и другие дешёвые high-volume-задачи	gpt-5.4-nano	01.04.2027	gpt-6-luna
Озвучивание	tts-1, tts-1-hd, gpt-4o-mini-tts-2025-03-20, gpt-4o-mini-tts-2025-12-15	06.01.2027	gpt-realtime-2.1-mini

Именно deprecations page остаётся главным источником для replacement-модели. Это особенно важно для Sol: общий каталог уже показывает gpt-6.1-sol как более новую модель семейства, а карточка gpt-6-sol прямо отсылает к ней. Однако строка deprecation для gpt-5.3-codex и gpt-5.1 на дату проверки всё ещё называет replacement gpt-6-sol. Поэтому автоматическая подмена официального маршрута на «самую новую похожую модель» добавила бы ещё одно изменение, которое тоже пришлось бы отдельно оценивать.

Почему простой model swap может сломать production

Самая рискованная версия миграции выглядит безобидно: заменить строку gpt-5.3-codex на gpt-6-sol, развернуть приложение и считать задачу закрытой. Model ID действительно изменится, но поведение системы определяется не только именем модели.

Нужно повторно проверить reasoning settings, системные и developer-инструкции, structured outputs, arguments в function calling, последовательность tool calls, размер реально передаваемого контекста, объём ответа и обработку ошибок. Для agentic workload важно смотреть не только на финальный текст, но и на весь trace: правильный ли инструмент выбран, корректны ли параметры вызова, не изменилась ли последовательность действий.

Различия видны уже в спецификациях. gpt-5.3-codex имеет окно контекста 400 000 токенов, max output 128 000, поддерживает function calling и structured outputs; его базовая цена на карточке модели составляет $1,75 за 1 млн input-токенов и $14 за output. У gpt-6-sol окно контекста увеличено до 1 050 000 токенов при том же max output 128 000; стандартная цена для короткого контекста — $2 input и $10 output за 1 млн токенов. Но более дешёвый output сам по себе не доказывает снижение стоимости вашего запроса: новая модель может иначе рассуждать, использовать другой объём токенов или по-другому работать с инструментами.

Для GPT-6 OpenAI отдельно рекомендует Responses API для встроенных tools и function calling. У gpt-6-sol и gpt-6-luna function calling через Chat Completions имеет дополнительное условие: он доступен там при reasoning_effort: "none". Это именно тот тип различия, который простой поиск и замена model ID не обнаруживает.

Coding: gpt-5.3-codex → gpt-6-sol

Для анализа репозитория, исправления кода и agentic coding сначала соберите набор реальных задач: поиск регрессии, изменение нескольких файлов, работа с тестами, вызовы инструментов, анализ большого контекста. Старая и новая модель должны получить одинаковую постановку задачи и одинаковый доступ к инструментам.

Оценивайте correctness результата, успешность тестов, число лишних изменений, корректность tool calls и стоимость полного запуска. Отдельно измеряйте latency на реальном потоке: официальная документация объясняет общие факторы задержки, но не даёт универсального числа, которое можно перенести на конкретное приложение.

Такая проверка особенно важна там, где ИИ уже встроен в рабочий процесс разработчика. Практические примеры того, где автоматизация действительно даёт выигрыш, я разбирал в материале задачи WordPress-разработчика, которые нейросети реально ускоряют.

General workload: gpt-5.1 → gpt-6-sol

У gpt-5.1 также 400 000 токенов контекста и 128 000 max output, а базовая цена на карточке — $1,25 input и $10 output за 1 млн токенов. У официальной замены больше контекстное окно, но входные токены стоят дороже при стандартном коротком контексте. Поэтому для общего assistant- или agentic-workload полезнее считать не стоимость миллиона токенов в таблице, а стоимость завершённой бизнес-операции.

Например, если новый маршрут делает меньше повторных запросов или успешнее завершает инструментальную цепочку, более высокая цена input может не означать более дорогой результат. Обратная ситуация тоже возможна. Ответ даёт только ваш eval на production-подобных данных.

High-volume: gpt-5.4-nano → gpt-6-luna

Здесь профиль отличается заметнее. gpt-5.4-nano позиционировалась для classification, extraction, ranking и других задач, где особенно важны стоимость и скорость. У неё 400 000 токенов контекста, а цена на карточке — $0,20 input и $1,25 output за 1 млн токенов. gpt-6-luna получила окно 1 050 000 токенов и для короткого контекста стоит $0,10 input и $0,50 output. OpenAI описывает Luna как эффективную модель для focused high-volume tasks.

На бумаге стоимость выглядит привлекательнее, но latency всё равно нужно замерять. Для массовой классификации полезно отдельно считать accuracy по каждому значимому классу, долю невалидного structured output, токены на один объект, p50/p95 latency и фактическую стоимость тысячи или миллиона ваших операций. Если один редкий класс бизнес-критичен, усреднённая accuracy может скрыть регрессию.

TTS — отдельная миграция, а не четвёртый text model swap

У production-приложения из нашего сценария есть tts-1 для озвучивания. Его нельзя переносить по той же процедуре, что Codex или Nano.

OpenAI назначила shutdown tts-1, tts-1-hd, gpt-4o-mini-tts-2025-03-20 и gpt-4o-mini-tts-2025-12-15 на 6 января 2027 года и прямо указывает gpt-realtime-2.1-mini как recommended replacement. Документация отправляет разработчика к Realtime API guide, то есть здесь нужно проверить не только модель, но и архитектуру аудиопотока.

Цены тоже нельзя сравнивать одной строкой. tts-1 тарифицируется по $15 за 1 млн символов, tts-1-hd — $30 за 1 млн символов. Для gpt-realtime-2.1-mini используются token-based ставки: текстовый input/output и отдельно audio input/output. На дату проверки audio-тариф составляет $10 за 1 млн входных и $20 за 1 млн выходных audio tokens, а text — $0,60/$2,40. Поэтому экономику миграции следует считать на фактической длительности и структуре вашей озвучки, а не пытаться напрямую сопоставить «миллион символов» с «миллионом audio tokens».

Как вести три миграционных потока параллельно

Представим production-приложение, где Codex анализирует код, Nano классифицирует большой поток объектов, а tts-1 формирует озвучивание. Ошибка — оформлять это одним тикетом «обновить OpenAI model».

Лучше держать три независимых маршрута:

CODE_MODEL   = gpt-6-sol
BULK_MODEL   = gpt-6-luna
SPEECH_MODEL = gpt-realtime-2.1-mini

Централизация model ID нужна не только для удобства. Она позволяет переключить конкретный workload назад без отката всего релиза. Если Luna показывает регрессию в одном классе, это не должно блокировать уже успешно проверенный coding route. Аналогично изменения Realtime не должны затрагивать text generation.

Для каждого подпроекта последовательность одинаковая на уровне контроля: inventory → replacement → evaluation set → quality/cost/latency comparison → staging → canary → monitoring → rollback → удаление старого ID. Но сами метрики и тесты разные.

В coding-потоке важны корректность кода, тесты и tool calls. В classification — accuracy по классам, схема ответа, цена и throughput. В speech — качество и стабильность аудио, время до начала воспроизведения, выбранная архитектура соединения и фактическая стоимость. Один «общий AI score» эти различия скроет.

Evaluation должна ответить на вопрос «можно ли переключать трафик»

OpenAI рекомендует eval-driven подход: сначала определить критерий успеха, собрать репрезентативный dataset, затем запускать одинаковые проверки при каждом изменении. Особое значение имеют production-примеры, edge cases и случаи, где модель уже ошибалась.

Для миграции моделей стоит сравнивать как минимум пять групп показателей: качество бизнес-результата, корректность structured output, tool/function calls, latency и реальную стоимость запроса. Для agentic-процессов полезно оценивать trace целиком, поскольку правильный финальный текст ещё не означает правильную последовательность инструментальных действий.

При этом не стоит строить новую миграционную инфраструктуру вокруг старого OpenAI Evals platform: сама эта платформа находится в deprecation, должна стать read-only 31 октября 2026 года и отключиться 30 ноября 2026 года. Regression harness лучше сделать независимым от конкретного временного интерфейса оценки — например, хранить собственный versioned dataset, ожидаемые свойства результата и измеряемые метрики.

Acceptance thresholds должны исходить из вашего продукта. Универсального «новая модель должна быть на 5% лучше» OpenAI не устанавливает, поэтому выдумывать такой порог нельзя.

Staging, canary и rollback до полного переключения

После offline evaluation новая конфигурация должна пройти staging с тем же SDK, tool definitions, JSON schemas и инфраструктурными ограничениями, которые используются в production.

Следующий этап — canary. Часть реальных запросов направляется на новый маршрут, а старая модель остаётся рабочим control path. Размер сегмента выбирают по риску и объёму трафика; фиксированного процента, подходящего всем системам, нет.

На этом этапе особенно полезно вести метрики раздельно по model route: success rate, ошибки API, schema failures, tool-call failures, токены, стоимость, p50/p95 latency и выбранные продуктовые quality metrics. Если новый маршрут выходит за ваши acceptance criteria, переключатель возвращает workload на прежнюю модель без отката остального приложения.

Только после стабильного canary можно расширять rollout. Именно организационная часть — маршрутизация, наблюдаемость и возможность отменить изменение — часто важнее одной строки API-кода. Более широкий вопрос о том, где проходит граница между автоматизацией и человеческой ответственностью, отдельно разобран в материале заменят ли нейросети людей.

Когда deprecated model действительно можно удалить из проекта

Полный rollout ещё не означает, что миграция закончена. Перед shutdown нужно убедиться, что старый ID не остался в скрытом fallback, cron-задаче, worker, тестовом окружении, background queue, feature flag, конфигурации старой версии приложения или документации для аварийного восстановления.

Полезный финальный поиск выполняется не только по основному model ID, но и по его snapshots и именам переменных окружения. После удаления старого маршрута повторите smoke-тест основных сценариев уже без возможности случайно обратиться к deprecated-модели.

На дату исследования дедлайн TTS наступает первым — 6 января 2027 года. Для gpt-5.3-codex, gpt-5.1 и gpt-5.4-nano контрольная дата позже, 1 апреля 2027 года. Но эти дополнительные месяцы лучше использовать не для отсрочки, а для спокойного сравнения моделей на собственных данных.

Главная задача такой миграции — не успеть изменить строку до дедлайна. Нужно доказать до переключения production-трафика, что новый маршрут сохраняет или улучшает нужное вашему продукту качество, остаётся управляемым по стоимости и latency и имеет понятный rollback. Тогда shutdown старой модели становится плановой технической датой, а не аварийным событием.