Два параметра API, утроившие производительность агента — и что они означают для вашего routing-слоя

На этой неделе OpenAI опубликовали инженерный пост, который начинается как головоломка с benchmark, а заканчивается чётким требованием к операторам: если ваш routing-слой отбрасывает reasoning-токены или откатывается к rolling truncation при управлении контекстом — он незаметно снижает качество каждого вызова агента GPT-5.6.

Ключевой результат — retained reasoning и compaction подняли результат GPT-5.6 Sol на ARC-AGI-3 с 13,3% до 38,3%, сократив выходные токены в 6 раз — важен не как цифра benchmark, а как сигнал: Responses API и Chat Completions семантически различаются, и эти различия напрямую влияют на решения по маршрутизации агентных рабочих нагрузок.

Что делает каждый из двух параметров

Retained reasoning сохраняется при передаче previous_response_id в запросах Responses API. Без него приватные reasoning-токены GPT-5.6 Sol отбрасываются после каждого хода. Модель видит историю действий, но не рассуждения, которые к ним привели, и вынуждена заново реконструировать понимание задачи на каждом шаге. С retained reasoning модель тратит меньше вычислений на каждое действие и выстраивает связные многоходовые стратегии.

Compaction заменяет rolling truncation. Когда контекст Chat Completions достигает лимита, стандартный подход отбрасывает старые сообщения. Compaction сжимает диалог в компактное представление, сохраняя то, что модель узнала в начале сессии. OpenAI использует лимит в 175 000 токенов и сжимает контекст вместо усечения.

Конкретное изменение API:

// До: Chat Completions, reasoning отбрасывается каждый ход
POST /v1/chat/completions
{ "model": "gpt-5.6-sol", "messages": [...history...] }

// После: Responses API, reasoning сохраняется через previous_response_id
POST /v1/responses
{
  "model": "gpt-5.6-sol",
  "previous_response_id": "<id предыдущего ответа>",
  "input": "<следующий пользовательский ввод>"
}

При цепочке вызовов Responses API через previous_response_id compaction активируется автоматически — реализовывать шаг суммаризации вручную не нужно.

Почему это решение для routing-слоя, а не просто выбор модели

Если ваш gateway пересылает запросы GPT-5.6 на Chat Completions endpoint, вы запускаете не ту конфигурацию, которую OpenAI использует в ChatGPT и Codex, — а ту, которую OpenAI прямо назвал причиной троекратного падения производительности агентов.

Для routing-команд это имеет три конкретных последствия:

Маршрутизация по endpoint: Chat Completions (/v1/chat/completions) и Responses API (/v1/responses) — разные endpoints с разной семантикой управления контекстом. Правило маршрутизации, трактующее их как взаимозаменяемые, при неверном fallback тихо отправит рабочие нагрузки, оптимизированные под Responses API, на неверный endpoint.

Пересылка состояния: Responses API использует previous_response_id для связывания ходов. Если ваш proxy или gateway обрезает или не пересылает это поле — reasoning-цепочка прерывается. Если middleware нормализует запросы в stateless-формат, каждый многоходовой агентный вызов GPT-5.6 деградирует.

Модель учёта токенов: Reasoning-токены в Responses API попадают в статистику использования, но снижают вычислительные затраты последующих ходов. Модель стоимости, трактующая reasoning-токены как «лишний расход», и правило маршрутизации, минимизирующее их, работают прямо противоположно ожидаемому.

Сравнение провайдеров, которое нужно сделать операторам

Эта конфигурационная пропасть специфична для OpenAI, поскольку архитектура GPT-5.6 разделяет приватные reasoning-токены и выходные токены, а их сохранение между ходами требует явной поддержки со стороны API.

В Anthropic extended thinking работает иначе: reasoning-токены выдаются в виде блоков thinking внутри той же структуры сообщений и возвращаются обратно через обычные ходы assistant — без отдельного response-chain ID.

DeepSeek V4 Pro и V4 Flash поддерживают thinking mode, но не имеют эквивалента Responses API с автоматическим compaction — операторы управляют контекстом самостоятельно.

Session API Gemini (Gemini Agent Platform) устроен иначе: управление памятью идёт через сессии, а не через цепочку response-идентификаторов.

Вывод для routing-слоя: если вы предоставляете downstream-клиентам единый Chat Completions интерфейс, нужна явная политика — какие функции эмулируются, какие теряются и для каких рабочих нагрузок клиент обязан использовать нативный endpoint напрямую.

Что на самом деле измерял benchmark

OpenAI пишут прямо: «Benchmark почти никогда не измеряет модель в изоляции. Он также измеряет менее заметные решения: параметры API, дизайн тестового окружения и промпты».

ARC-AGI-3 использовал rolling truncation и отбрасывал reasoning — так устроено большинство сторонних eval-фреймворков по умолчанию. Результат — 13,3%, далеко ниже реальных возможностей модели. Та же модель в конфигурации, соответствующей production, набрала 38,3% — почти на уровне оценочного базового результата человека в 48%.

Это важная корректировка данных для принятия решений по routing-тиру. Если вы выбираете между провайдерами на основе публичных benchmark-результатов, а те используют дефолтные настройки Chat Completions, — вы можете сравнивать провайдера A в оптимальной конфигурации с провайдером B в деградированной.

Что операторам нужно проверить прямо сейчас

Для команд, маршрутизирующих многошаговые или long-horizon агентные рабочие нагрузки на GPT-5.6:

• Проверка endpoint: Ваша routing-конфигурация отправляет агентные нагрузки на /v1/responses или на /v1/chat/completions? Это различие прямо влияет на сохранение reasoning.
• Пересылка состояния: Ваш gateway пересылает previous_response_id между ходами или перестраивает stateless-запросы из локального буфера контекста?
• Поведение при fallback: Если Responses API возвращает ошибку и gateway откатывается на Chat Completions — состояние reasoning при этом сохраняется или теряется?
• Модель стоимости: Reasoning-токены в Responses API отражают отложенную экономию вычислений в последующих ходах. Оптимизация исключительно по стоимости токенов на один вызов не учитывает реальную эффективность retained-reasoning нагрузок.

Рекомендация OpenAI для API-разработчиков: использовать Responses API (не Chat Completions), сохранять reasoning через previous_response_id и включать compaction. Это теперь эталонные production-настройки для агентных рабочих нагрузок GPT-5.6.