OpenAI Fast Mode и снижение цен на GPT-5.6: что должны изменить команды маршрутизации

30 июля OpenAI внёс три взаимосвязанных изменения в API, которые большинство команд заметят в разных местах: Priority Processing переименован в Fast mode, GPT-5.6 Luna подешевел на 80%, а Terra — на 20%. Что не очевидно из анонса: все три изменения взаимодействуют между собой — и для команд, работающих с routing-слоями или мультипроектными API-конфигурациями, неправильная настройка теперь означает либо переплату, либо незаметное падение до стандартной скорости в самый неподходящий момент.

Что изменилось 30 июля

Priority Processing переименован в Fast mode. Старый параметр service_tier: "priority" получил псевдоним: service_tier: "fast". Оба значения принимаются в Responses API и Chat Completions API и дают одинаковый результат. В response-объекте поле service_tier по-прежнему возвращает priority, даже если вы отправили fast — для GPT-5.6 и более ранних моделей. Изменение обратно совместимо: код ломать не нужно. Но теперь перед вами стоит семантический выбор в конфигурации маршрутизации.

GPT-5.6 Luna: снижение цены на 80%. Luna и прежде была самым дешёвым уровнем в семействе GPT-5.6. После этого снижения она становится наиболее экономичным вариантом из всех, что OpenAI когда-либо предлагал для модели frontier-поколения. Ключевой вопрос для routing-команд — подходит ли потолок возможностей Luna для вашей задачи, а не только насколько она дешевле.

GPT-5.6 Terra: снижение цены на 20%. Terra позиционировалась как балансовый уровень между пропускной способностью Luna и возможностями Sol. Снижение на 20% делает её более сильным вариантом по умолчанию для нагрузок, которые раньше были вынуждены использовать Sol из-за ограничений по стоимости.

GPT-5.6 Sol с Fast mode: до 2.5x быстрее стандартной обработки. Fast mode для Sol теперь обеспечивает примерно 2.5x скорости стандартной обработки при 2x цене за токен. Для latency-sensitive пайплайнов, которые уже платили по тарифам Sol, это соотношение (2x стоимость за 2.5x скорость) выгодно.

Лимит скорости роста трафика, который операторы пропустят

Fast mode вводит ramp rate limit, которого нет в стандартной обработке. Если ваш проект отправляет не менее 1 миллиона токенов в минуту и увеличивает этот показатель более чем на 50% за 15 минут, OpenAI может понизить затронутые Fast mode запросы до стандартной скорости — и выставить счёт по стандартным тарифам.

Когда это происходит, поле service_tier в response возвращает "default", а не "priority". Если вы не логируете и не проверяете service_tier в ответах, у вас не будет никаких признаков деградации до тех пор, пока вы не заметите всплеск задержек или не проверите стоимость постфактум.

Конкретные сценарии отказов:

• Незаметная деградация производительности при всплесках трафика. Agent swarm, который разворачивается одновременно, batch-пайплайн, запускающийся сразу, или нагрузочный тест с резким ростом — любой из этих сценариев может вызвать деградацию. Если ваш routing-слой предполагает, что Fast mode всегда быстрый, downstream SLA становятся ненадёжными.
• ETL и batch-задачи не должны использовать Fast mode. Документация OpenAI прямо об этом говорит. Запускать extraction или transformation пайплайны в Fast mode при больших масштабах — это и напрасная трата надбавки, и тип нагрузки, наиболее склонный к срабатыванию ramp limit.
• Переходите на Fast mode поэтапно. При включении Fast mode на уровне проекта переводите трафик постепенно — часами, а не моментально.

Взгляд оператора маршрутизации

Fast mode на уровне проекта или на уровне запроса. Fast mode можно настроить на уровне запроса (service_tier: "fast" для каждого вызова) или на уровне проекта через панель управления платформой. Уровень проекта удобен — запросы без указания tier по умолчанию используют Fast — но лишает детализации на уровне вызова. Для команд, маршрутизирующих несколько типов нагрузок через один проект, это ловушка конфигурации: batch-задачи, фоновое индексирование и пользовательские real-time вызовы требуют разных политик service tier.

Правильная конфигурация маршрутизации после этих изменений:

1. Пользовательские, latency-sensitive вызовы (chat completion, agent turn, code completion): явно устанавливайте service_tier: "fast" на уровне запроса.
2. Фоновые, batch и ETL нагрузки: явно устанавливайте service_tier: "default". Никогда не запускайте их в Fast mode при высоком throughput.
3. Routing-селектор оценивает модель и тип нагрузки, затем инжектирует service_tier перед отправкой в OpenAI.

Переоценка модели после снижения цен. Снижение цены Luna на 80% существенно расширяет ценовой разброс внутри семейства GPT-5.6. Для нагрузок, которые остановились на Terra как компромиссе между качеством Sol и бюджетом Luna, стоит перегнать evals против Luna. Разрыв в возможностях между Luna и Terra может больше не оправдывать разницу в стоимости.

Межпровайдерный контекст: три разных подхода к одной проблеме пропускной способности. Ramp rate limit OpenAI основан на скорости изменения: вы можете бесконечно долго работать на высоком throughput, но не можете увеличить трафик более чем на 50% за 15 минут. Пиковое ценообразование DeepSeek основано на времени суток: стоимость растёт в пиковые часы вне зависимости от того, был ли всплеск трафика. Fast mode Anthropic был полностью удалён, потому что создавал два сценария отказа для операторов. Каждый провайдер решает одну и ту же проблему управления пропускной способностью по-своему — ваша routing-политика должна кодировать правильное правило для каждого upstream, а не предполагать одинаковое поведение.

Добавьте service_tier в логирование ответов. Обратно совместимое переименование с priority на fast — хороший повод проверить парсинг ответов. Если ваш logging-слой не захватывает service_tier из ответов, вы не сможете обнаружить деградацию из-за ramp rate limit. Сигнал для мониторинга: "default" в ответах, где вы отправляли "fast" или "priority".

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

Немедленный чеклист аудита:

• Проверьте, установлен ли Project Service Tier в Fast на уровне проекта в каких-либо ваших OpenAI-проектах. Если да, убедитесь, что через эти проекты не проходят batch или ETL пайплайны.
• Добавьте service_tier в захват полей ответа и настройте алерт на "default", когда вы ожидали "fast".
• Перезапустите capability evals для Luna на ваших текущих Terra-нагрузках. Ценовой разрыв в 80% достаточно большой, чтобы оправдать свежий прогон benchmark.
• Для Sol с Fast mode на пользовательских нагрузках измерьте улучшение задержки в вашем production-распределении, прежде чем фиксировать 2x ценовую надбавку.

Конфигурация маршрутизации TheRouter поддерживает добавление service_tier как параметра к каждому назначению модели. Рекомендуемый паттерн после этих изменений: Sol с service_tier: fast для синхронных пользовательских маршрутов; Luna или Terra с service_tier: default для любого batch-пути, который может превысить 1 млн TPM.