GPT-6 Astra отключает вызов инструментов через Chat Completions: что операторы должны изменить до направления трафика

GPT-6 Astra вышла 3 сентября 2026 года, и маркетинговые тексты OpenAI — это простая часть. Для операторов важнее то, что трудно найти в объявлении о запуске: модель вводит набор ограничений на уровне API, которые сломают существующие интеграции — молчаливо или явно — в зависимости от того, где в стеке используются инструменты.

Три вещи ломаются так, что слой маршрутизации может не отловить это автоматически. Одна вещь — новый мониторинг рассогласования — меняет контракт по задержке даже для интеграций, которые не ломаются. И два новых кода ошибок (добавленные днём раньше, 2 сентября) означают, что логику повторных запросов нужно обновить независимо от того, используете ли вы Astra.

Вызов инструментов больше не работает через Chat Completions

Наиболее существенное изменение: если передать инструменты через v1/chat/completions для gpt-6-astra, вызов завершится ошибкой. В changelog OpenAI сформулировано прямо — «вызов инструментов требует Responses API». Это не пробел в возможностях — это жёсткое архитектурное решение.

Практическое влияние зависит от того, как подключён ваш стек. Если вы используете LiteLLM, LangChain или любой шлюз, проксирующий вызовы инструментов через путь Chat Completions — а большинство так и делает для совместимых с OpenAI провайдеров — эти интеграции падают на Astra. Если вы используете собственный клиент OpenAI и указываете model="gpt-6-astra" в вызове chat.completions.create с аргументом tools=, вызов завершится ошибкой.

Responses API уже доступен и хорошо задокументирован. Поле модели становится model="gpt-6-astra", массив tools переходит в формат Responses API, а messages становится input. Но каждый компонент в цепочке, генерирующий тело запроса, должен нативно поддерживать Responses API, либо нужен адаптер перед Astra.

Для операторов с прозрачным проксированием Chat Completions (паттерн «просто переслать в OpenAI») это требует маршрутизации с учётом модели: Astra необходимо обрабатывать иначе, чем GPT-5.x и GPT-4.x. Если ваш слой маршрутизации выбирает Astra динамически или как запасной вариант, нужен либо адаптер Responses API, либо явное исключение Astra из маршрутов с вызовами инструментов до его появления.

Блокировка параметров: temperature, top_p и logprobs исчезли

GPT-6 Astra не принимает пользовательские значения temperature или top_p, и log probabilities (logprobs) недоступны.

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

На практике: если слой маршрутизации внедряет temperature или top_p из конфигурации по умолчанию, добавьте gpt-6-astra в список исключений для этих инъекций. Если temperature выставлен как пользовательски настраиваемое поле и доходит до модели, нужна либо система переопределений на уровне модели, либо защита на уровне UI. Модель не выдаст явную ошибку, что делает это легко упускаемым при тестировании.

Исчезновение logprobs — более жёсткий разрыв для команд, занимающихся оценкой уверенности, валидацией вывода или калиброванной выборкой из распределений токенов. В Responses API нет эквивалентного механизма, возвращающего сырые log probabilities от Astra — эта возможность попросту отсутствует для данной модели.

Мониторинг рассогласования меняет контракт по задержке

Astra — первая модель OpenAI с обязательным асинхронным мониторингом рассогласования. Система в фоне проверяет рассуждения и действия модели на предмет потенциального рассогласования в контекстах с существенными последствиями — доступ к чувствительным данным, передача данных, деструктивные изменения — и может остановить разговор при обнаружении проблемы.

Асинхронная архитектура означает, что большинство вызовов не затронуто — мониторинг работает параллельно и в штатной ситуации не добавляет задержку. Но поведение остановки важно: если мониторинг срабатывает, он может прервать текущий разговор в Responses API, а не просто поставить метку. Для запросов с персистентным рассуждением, WebSocket или compaction от OpenAI система может заблокировать продолжение.

Запросы через Chat Completions явно не охвачены этим мониторингом. Это полезно при оценке операторами, стоит ли направлять чувствительные или высокорисковые нагрузки через Responses API: мониторинг работает там, не в Chat Completions. Для одних организаций это плюс в части комплаенса (автоматизированный надзор за безопасностью). Для других это меняет SLA — остановленный разговор является неудачной транзакцией.

Для операторов шлюзов, ведущих длинные многоходовые сессии с Astra, обработка webhook-оповещений misalignment_monitoring теперь входит в операционную поверхность. Документация OpenAI описывает доставку через webhook для случаев, когда система не может остановить сессию автоматически — это новая категория внеполосных событий, которую должен покрыть ваш мониторинг.

Асинхронный вызов инструментов: что получает слой маршрутизации

Новый режим асинхронного вызова инструментов (async: true в определении функции или пользовательского инструмента) позволяет Astra продолжать рассуждения и обработку, пока приложение выполняет инструмент, возвращая результат по исходному call_id когда тот готов. Модель не ждёт.

Это меняет цикл запрос-ответ так, что прокси-маршрутизаторы должны это понимать. Обычный вызов инструмента — синхронная блокировка: модель останавливается, приложение выполняет инструмент, модель возобновляет работу. Асинхронный вызов означает, что модель продолжает генерировать вывод между отправкой вызова инструмента и получением результата — то есть потоковый вывод от Astra приходит, пока в полёте ваш запрос к базе данных или внешнему API.

Для операторов, строящих агентные рабочие процессы с медленными зависимостями инструментов (поисковые индексы, внешние API, запросы к БД), это реальный выигрыш по задержке: модель может рассуждать о независимых частях запроса, ожидая медленный инструмент, вместо блокирующего ожидания. Для операторов шлюзов, буферизирующих или преобразующих потоковый вывод, нужно понимать, что вывод вызовов инструментов и продолжение вывода модели теперь могут перемежаться в потоке.

Управление на ходу (через WebSocket, через Responses API) позволяет вводить коррективы или обновлённые инструкции, пока Astra работает. В сочетании с изменением усилия рассуждения по запросу (входные элементы configuration_update), это даёт операторам больше управления во время выполнения длинных задач — но всё это в Responses API, дополнительно подкрепляя то, что Chat Completions не является путём для рабочих процессов на основе Astra.

Новые коды ошибок, затрагивающие все модели OpenAI

2 сентября, за день до выпуска Astra, OpenAI разделил ошибки перегрузки 429 на два типа. Это применяется ко всем моделям:

• 429 с кодом slow_down: ваш трафик нарастает слишком быстро. Снизьте темп и наращивайте постепеннее.
• 503 с кодом server_is_overloaded: модель временно перегружена. Повторите после ожидания.

Оба могут содержать заголовок Retry-After. При его наличии — соблюдать; при отсутствии — использовать экспоненциальный откат. Прежде оба случая возвращались как неразличимые 429 — ваша логика повторных запросов, вероятно, обрабатывала их одинаково. Теперь можно различить «замедли нарастание трафика» от «подожди и повтори» и действовать по-разному: агрессивное ограничение на входе для slow_down, обычный экспоненциальный откат для server_is_overloaded.

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

Как выглядит миграция на Responses API на практике

Запрос, ранее использовавший Chat Completions с инструментами:

# Раньше — Chat Completions (не работает для gpt-6-astra с инструментами)
response = client.chat.completions.create(
    model="gpt-6-astra",
    messages=[{"role": "user", "content": "Найди последние новости о X"}],
    tools=[{
        "type": "function",
        "function": {
            "name": "web_search",
            "description": "Поиск в сети",
            "parameters": {...}
        }
    }],
    temperature=0.2  # также убран — игнорируется или вызывает ошибку
)

# После — Responses API (обязателен для вызовов инструментов gpt-6-astra)
response = client.responses.create(
    model="gpt-6-astra",
    input="Найди последние новости о X",
    tools=[{
        "type": "function",
        "name": "web_search",
        "description": "Поиск в сети",
        "parameters": {...}
    }]
    # Без temperature — параметр не принимается
)

Структурные различия: messages становится input (или списком входных элементов), chat.completions.create становится responses.create, определения инструментов мигрируют в формат Responses API. call_id, возвращённый при вызове инструмента — это то, что передаётся обратно при отправке результата инструмента.

В многоходовых разговорах Responses API использует store: true и идентификаторы предыдущих ответов, а не историю сообщений. Это существенное архитектурное различие — состояние разговора на стороне сервера, а не управляется клиентом.

Codex от OpenAI может применить миграцию автоматически через skill OpenAI docs: $openai-docs migrate this project to GPT-6 Astra. Для команд на сторонних шлюзах или LiteLLM — убедитесь, что адаптер Responses API вашего провайдера готов к продакшену, прежде чем направлять трафик Astra с инструментами.

Уровни усилия рассуждения

Astra поддерживает пять уровней усилия рассуждения: low, medium, high, xhigh и max. Уровень none явно не поддерживается. Если слой маршрутизации передаёт reasoning_effort: "none" для обхода рассуждений с целью снижения задержки — паттерн, который некоторые команды используют для простых подзадач — на Astra это вызовет ошибку. Маршрутизируйте запросы с нулевым усилием на модель GPT-5.x или скорректируйте значение по умолчанию.

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