Skip to main content
Кратко: в моделях GPT-5.4 и более поздних моделях отправка tools вместе с явным reasoning_effort (любым значением, кроме none) в /v1/chat/completions может быть отклонена на upstream с ошибкой 400: Function tools with reasoning_effort are not supported ....Есть два решения: перенести запросы с инструментами в /v1/responses (сохраняет и рассуждение, и инструменты — рекомендуется) или явно задать reasoning_effort="none" (сохраняет эндпоинт, но отключает рассуждение). Запросы без tools не затрагиваются.

​
Сначала убедитесь, что столкнулись именно с этой проблемой

Она проявляется тремя способами. Второй проще всего неправильно интерпретировать.

​
Симптом 1: явная ошибка 400

В ответе содержится param: reasoning_effort. Это официальное ограничение OpenAI, а не проблема шлюза APIYI — тот же запрос, отправленный напрямую в OpenAI, ведёт себя идентично.

​
Симптом 2: иногда работает, а иногда завершается ошибкой

Одна модель может обслуживаться несколькими маршрутами вышестоящих систем, и это ограничение применяется не на каждом маршруте. Наши собственные измерения от 2026-09-02, группа по умолчанию, тот же ключ, тот же временной интервал, по шесть вызовов для каждой комбинации: Ранее в тот же день клиент действительно получил ошибку 400 для gpt-5.6-sol.
«Только что у меня это сработало» не доказывает, что вы в безопасности. Та же модель и тот же код могут начать возвращать 400 в другое время или в другой группе. Перейдите на Responses API или явно задайте reasoning_effort="none" — оба варианта стабильны на каждом маршруте.

​
Симптом 3: ошибки нет, но инструмент никогда не вызывается

Если модель должна была вызвать инструмент, но вместо этого отвечает праздной беседой (finish_reason — stop, tool_calls пуст), не начинайте переписывать промпт. Повторно отправьте запрос один раз, явно задав reasoning_effort равным none: если после этого инструмент будет вызван корректно, проблема заключается в комбинации параметров, а не в вашем промпте.

​
Что охватывает ограничение

Ограничение срабатывает только при явной отправке уровня усилий, отличного от none. В наших тестах все четыре значения — low, medium, high и xhigh — вызывают его.
Пропуск reasoning_effort не вызывает ограничение. На маршруте gpt-5.6-luna, где ошибка 400 воспроизводится детерминированно, все четыре уровня усилий возвращали 400, а при пропуске параметра значение tool_calls корректно возвращалось в 6 случаях из 6. Поэтому минимальное экстренное исправление имеет две формы: явно задать none или полностью удалить параметр.

​
Какой вариант выбрать

Для сложных задач с использованием tools отключение рассуждения заметно ухудшает работу модели — она теряет этап, на котором определяет, какой tool вызвать и в каком порядке. Рассматривайте none как временное решение, а не как конечный вариант.

​
Дело не только в обходе ошибки

Даже если вы никогда не столкнётесь с ограничением, Responses — это эндпоинт, который OpenAI рекомендует для новых проектов. Согласно официальным данным, одна и та же модель рассуждения показывает более высокие результаты в SWE-bench при использовании Responses, использование кэша значительно эффективнее, чем в Chat Completions, а встроенные инструменты, такие как веб-поиск и интерпретатор кода, доступны только здесь. Числовые показатели и подробности приведены в разделе Нативные вызовы. Именно кэширование отражается в вашем счёте: многошаговые агенты больше всего выигрывают от попаданий в кэш, а многошаговые агенты — это как раз тот тип нагрузки, который с наибольшей вероятностью сталкивается с указанным выше ограничением. О том, как тарифицируется кэширование и как интерпретировать показатели попаданий: Кэширование промптов.

​
В какой вы группе

​
Что изменяется в вашем коде

Полное сопоставление полей приведено в разделе Нативные вызовы. Ниже перечислены только четыре различия, имеющие значение для вызова инструментов, поскольку именно этому посвящена данная страница:
Два формата инструментов нельзя смешивать. Отправка вложенного определения function: {...} в стиле Chat Completions в /v1/responses (или наоборот) — наиболее распространённая причина ошибки «недопустимый параметр» от SDK. Подробнее см. в разделе Вызов функций.
Один и тот же цикл работы инструмента погоды до и после изменений:
Оба фрагмента выполнялись с группой APIYI по умолчанию: первый стабильно воспроизводит ошибку 400, а второй полностью выполняет цикл вызова, возврата результата и формирования финального ответа.
Не пропускайте history += resp.output. Помимо function_call, вывод может содержать элемент reasoning — его дословная передача обратно позволяет модели продолжить предыдущую цепочку рассуждений и является именно той причиной, по которой Responses лучше справляется с многоэтапными задачами с использованием инструментов.

​
Ловушки, с которыми сталкиваются при миграции

output — это массив элементов, который может одновременно содержать записи reasoning, message и function_call, причём их порядок и количество не гарантируются. Используйте resp.output_text для текста и выполняйте итерацию с фильтрацией по type == "function_call" для вызовов инструментов. Никогда не задавайте индекс жёстко.
max_tokens (или max_completion_tokens) становится max_output_tokens; response_format становится text.format; системный prompt можно переместить из messages в корневой уровень instructions. Отдельно следует отметить, что модели рассуждения gpt-5 не поддерживают temperature или top_p ни на одном из эндпоинтов — удалите их и управляйте моделью с помощью reasoning.effort.
usage.prompt_tokens становится usage.input_tokens, completion_tokens становится output_tokens, а попадания в кэш находятся в usage.input_tokens_details.cached_tokens. Одновременно обновите учёт usage, иначе в нём незаметно будут записываться нулевые значения.
Самый надёжный подход — самостоятельно поддерживать массив input, дословно добавляя в него output каждого хода. Это работает в любой группе и с любой моделью, именно так поступает приведённый выше пример.Цепочка запросов с previous_response_id работала в группе по умолчанию 2026-09-02 — gpt-5.6-sol, terra, luna и gpt-5.4 восстанавливали предыдущий ход, store по умолчанию имеет значение true, а отправка store: false с последующим созданием цепочки корректно сообщает, что предыдущий ответ не найден. Получение истории с помощью GET /v1/responses/{id} по-прежнему недоступно. Проверьте это в собственной группе, прежде чем полагаться на такую возможность. Дополнительная информация: Многоходовые диалоги.
Chat Completions передаёт последовательность приращений delta; Responses передаёт типизированные события, такие как response.output_text.delta и response.function_call_arguments.delta. Парсер потоковой передачи необходимо переписать, а не повторно использовать. См. раздел Нативные вызовы.

​
Проверка миграции

Не ограничивайтесь кодом HTTP 200. Выполните эти четыре проверки:
1

Убедитесь, что результат действительно содержит function_call

Выведите [i.type for i in resp.output] — вы должны увидеть function_call, которому на более высоких уровнях усилий предшествует reasoning. Только message означает, что инструмент так и не был вызван.
2

Убедитесь, что поля использования по-прежнему содержат значения

Проверьте, что usage.input_tokens и output_tokens не равны нулю, а output_tokens_details.reasoning_tokens изменяется вместе с уровнем усилий.
3

Убедитесь, что начинают появляться попадания в кэш

Выполните несколько запросов и следите, чтобы usage.input_tokens_details.cached_tokens превысил ноль. Это самое непосредственное преимущество тарификации Responses перед режимом совместимости.
4

Повторно отправьте запрос, который раньше возвращал ошибку 400

Та же комбинация tools и reasoning_effort теперь должна стабильно выполняться. Сохраните её как регрессионный тест, чтобы будущая замена модели сразу выявила проблему.

​
Когда не следует переходить

Это не решение по принципу «всё или ничего». Оставаться в режиме совместимости вполне разумно, если:
  • Вы не используете вызов инструментов — ограничение не применяется, и вы можете отправлять любые reasoning_effort
  • Вы вызываете несколько поставщиков через один путь кода — здесь Claude и Gemini предлагают только /v1/chat/completions, и разветвление кода только ради OpenAI может не окупиться
  • Ваш фреймворк или клиент фиксирует эндпоинт — оставайтесь на reasoning_effort="none", пока он не будет обновлён
  • Вы используете gpt-5.2 или более раннюю версию — она находится за пределами затронутого диапазона
Полный перечень ограничений возможностей режима совместимости приведён в разделе Режим совместимости.

​
Часто задаваемые вопросы

Модель перестаёт явно выполнять рассуждение и отвечает напрямую. В одноступенчатых задачах с очевидным выбором инструмента изменения минимальны; многошаговая оркестрация, требующая от модели определить порядок вызовов, заметно ухудшается. Это промежуточный этап, а не конечное решение.
Да, это распространённый поэтапный подход: оставить обычный чат на /v1/chat/completions, а на /v1/responses перевести только путь с инструментами. Оба эндпоинта используют один и тот же ключ и один и тот же базовый URL, а тарификация идентична.
Нет. Тарифы на входные и выходные данные для конкретной модели одинаковы на обоих эндпоинтах, как и модель тарификации. См. Модели и тарификация. Единственное различие заключается в частоте попаданий в кэш, которая обычно выше в Responses, поэтому итоговый счёт, как правило, уменьшается.
Нет. Это ограничение OpenAI для собственных моделей GPT-5.4 и новее. Claude через /v1/messages или режим совместимости, а также Gemini через нативный режим или режим совместимости могут одновременно использовать вызов инструментов и рассуждение.
На практике gpt-5.4-pro и gpt-5.5-pro можно использовать только через /v1/responses, и для них требуется группа SVIP. Они выполняются долго и рассчитаны на работу в фоновом режиме, который режим совместимости не поддерживает. См. Нативные вызовы.
Нет. Эндпоинт, закрытие которого запланировала OpenAI, — это Assistants API, а не Chat Completions. Оба эндпоинта будут поддерживаться в долгосрочной перспективе; новые функции просто сначала появляются в Responses.

​
Связанные страницы

Нативные вызовы

Полное описание эндпоинта Responses: параметры, структура ответа, встроенные tools и матрица поддержки клиентов

Режим совместимости

Принцип работы Chat Completions, границы его возможностей и настройка SDK для каждого языка

Вызов функций

Полные примеры вызова tools и сборка потоковой передачи для обоих эндпоинтов