OpenAI Responses API: что это и когда он нужен

16 августа protocols.responses впервые перешёл из review в available — у модели grok-4-20-multi-agent. До этого третий маршрут API был закрыт у всего текстового каталога без исключений. Одна модель из тридцати шести — цифра скромная, но событие показательное: это третий и последний протокол, который до сегодняшнего дня существовал только как поле в выдаче. Chat Completions остаётся основным маршрутом с 28 открытыми моделями, Anthropic Messages работает у восьми моделей Claude. Разбираем, что такое Responses, чем он отличается от привычного, и почему подавляющему большинству читателей переходить на него не нужно.

Три протокола каталога

Сначала карта, потому что путаница здесь стоит времени на отладку.

Статус живёт на уровне протокола, а не модели. Одна и та же модель может быть открыта по одному маршруту и закрыта по другому — это нормальное состояние, а не сбой.

Закрытый протокол отклоняет запрос кодом model_under_review до резервирования баланса и до обращения к сервису модели. Денег такой отказ не стоит.

Чем Responses отличается

Объясним разницу по существу, а не по названиям полей.

Chat Completions устроен просто: вы отправляете список сообщений, получаете ответ. Сервер ничего не помнит — всю историю диалога вы держите у себя и переотправляете при каждом обращении. Именно отсюда берётся рост расхода входных токенов по мере длины разговора, о чём мы писали в разборе служебного контекста маршрута.

Responses спроектирован под другой сценарий: модель делает несколько шагов подряд, вызывает инструменты, накапливает промежуточные результаты. Состояние между шагами ведёт платформа, а не ваш код.

Практическая разница проявляется в агентских задачах. В Chat Completions цикл «модель попросила инструмент — вы его вызвали — вернули результат — модель продолжила» вы собираете руками, храня всю цепочку. В Responses эта механика встроена.

Что важно: на качество ответа выбор маршрута не влияет. Одна и та же модель по любому протоколу отвечает одинаково. Разница в том, кто ведёт учёт состояния.

Почему открылась именно эта модель

Совпадение не случайное, и оно объясняет логику.

grok-4-20-multi-agent — модель, у которой многошаговая работа заявлена прямо в названии. Протокол, спроектированный под многошаговые сценарии, подходит ей больше, чем однократный обмен репликами.

Ставка у неё 20 ₽ за миллион входных и выходных токенов. Для сравнения, grok-4-20 и grok-4-3 стоят по 10 ₽, grok-4-5 — 20 ₽, а grok-4-6 — 20 ₽. Обзор семейства мы делали, когда Grok 4.6 приехал в каталог.

Почему протоколов вообще три

Полезно понимать, откуда взялась эта конструкция, — тогда выбор перестаёт быть гаданием.

Chat Completions появился первым и стал фактическим стандартом отрасли. Его формат поддерживают почти все: библиотеки, фреймворки, инструменты мониторинга. Именно поэтому он открыт у наибольшего числа моделей и остаётся у нас основным.

Anthropic Messages — родной формат одного вендора. Он существует не потому, что лучше, а потому что модели Claude отдают то, для чего в OpenAI-совместимой схеме просто нет места: блоки рассуждений, свою структуру вызова инструментов, поле stop_reason с отказом классификатора, приходящим успешным HTTP 200.

Responses — попытка OpenAI заменить собственный же стандарт чем-то более подходящим для агентов. Тот случай, когда вендор конкурирует со своим прошлым решением.

Отсюда практическое правило: протокол выбирается не по свежести, а по тому, что требует ваш инструмент. Claude Code ходит только в Messages. Библиотека, написанная под OpenAI SDK, ждёт Chat Completions. Новый агентский фреймворк может требовать Responses. Ни один из трёх не «правильнее» остальных.

Нужно ли вам переходить

Короткий ответ: почти наверняка нет. Развёрнутый — ниже.

Оставайтесь на Chat Completions, если ваш код написан под OpenAI SDK и работает. Маршрут открыт у 28 моделей против одной, покрывает все семейства каталога, и переписывать интеграцию ради нового формата смысла нет.

Присмотритесь к Responses, если вы строите агента с длинными цепочками вызовов инструментов и уже устали вести состояние руками. Но и тогда стоит дождаться, пока протокол откроется у большего числа моделей — сейчас выбор ограничен одной.

Возьмите Anthropic Messages, если вам нужен родной формат Claude: блоки рассуждений, stop_reason без переводчика, совместимость с инструментами, которые ходят только туда. Подробности — в разборе, как открылся родной протокол Anthropic.

Как читать статус в коде

Три правила, которые стоит зашить один раз.

1. Фильтруйте по тому протоколу, который реально зовёте. Для /v1/chat/completions — protocols.chat_completions, для /v1/messages — protocols.anthropic_messages, для Responses — protocols.responses.
2. Не полагайтесь на верхнее поле availability. Оно про модель в целом; решает судьбу запроса именно протокол. В середине августа эти поля расходились у трёх моделей одновременно.
3. Не кэшируйте статус надолго. За неделю каталог вырос с 25 позиций до 40, и статусы внутри него двигались ещё быстрее.

Что означает состояние на стороне платформы

Раз это главное отличие Responses, стоит разобрать, что вы выигрываете и что теряете.

Выигрываете объём кода. Цепочку вызовов инструментов не нужно собирать и хранить самому: платформа помнит, на каком шаге остановились, и продолжает. Для агента из двадцати шагов разница в коде существенная.

Теряете контроль и переносимость. История разговора живёт не у вас, а значит вы не можете её произвольно отредактировать, обрезать по своему правилу или перенести на другую модель другого вендора. Логика, которая в Chat Completions решается одной строкой — «выкинуть из истории всё старше десяти сообщений», — здесь зависит от того, что предусмотрел провайдер.

Есть и третье соображение, менее очевидное. Когда историю ведёте вы, вам точно известно, что уходит в модель при каждом запросе. Когда её ведёт платформа, состав контекста становится вопросом доверия к реализации. Для задач, где важно контролировать, какие данные вообще попадают в модель, это может оказаться решающим — особенно после того, как выяснилось, что блоки рассуждений переносимы между моделями.

Вывод простой: Responses экономит код там, где вам не нужен точный контроль над контекстом. Если нужен — Chat Completions остаётся более честным инструментом.

Чего мы не утверждаем

Не обещаем, что протокол откроется у остальных. На 16 августа responses в review у 35 текстовых моделей из 36, и сроков мы не называем.

Не проверяли возможности внутри маршрута. Всё семейство полей responses_* в capabilities у большинства моделей помечено unknown — это «не проверено», а не «не работает». Разница существенная: строить на непроверенном поле можно, закладывать его в обязательства перед своим клиентом — нет.

Не утверждаем, что Responses лучше. Это другой способ обращения к той же модели, а не улучшенный.

Кэш промптов не поддерживается ни на одном маршруте. У всех 36 текстовых моделей prompt_cache стоит unsupported, и выбор протокола на это не влияет.

Ставка от маршрута не зависит. Модель стоит одинаково, каким бы протоколом вы её ни вызывали.

Что держать в голове

Третий протокол каталога впервые открылся — пока у одной модели из тридцати шести. Chat Completions остаётся основным маршрутом и покрывает 28 позиций.

Практический вывод не про переход, а про привычку: выбирайте маршрут по тому, чего требует ваш инструмент, и проверяйте его статус в живой выдаче перед запросом. Это одна строка кода, которая экономит разбор непонятных отказов.

И стоит запомнить главное свойство этой конструкции: три протокола — это три независимых состояния у каждой модели, а не три уровня доступа. Открытый Chat Completions ничего не говорит о том, открыт ли Responses, и наоборот. Проверять надо ровно тот, в который вы стучитесь.

Как мы проверяем факты и почему у каждого стоит дата — на странице о проекте. Один ключ на все три маршрута и весь каталог: keydealer.ru/login.