Ошибки GPT-6 Astra API: model_not_found, 401 и ловушка max_tokens

Каждое тело ошибки ниже получено живыми запросами к эндпоинту GPT-6 Astra 6 сентября 2026 года. Без пересказов и без выдуманных текстов ошибок. И ещё один факт, который вообще не ошибка, но обойдётся вам дороже любой из них: Astra игнорирует max_tokens.

model_not_found        404 → строки модели не существует
invalid_api_key        401 → ключ неверный, отсутствует или отозван
invalid_request_error  400 → отсутствует обязательное поле
invalid_request_error  --- → значение параметра не принимается
max_tokens             ⚠️  молча игнорируется — см. ниже

Самое дорогое: max_tokens ничего не делает

Мы попросили 16 токенов, а счёт выставили за 2614. finish_reason вернулся как stop, а не length, так что ничто в ответе не сигнализирует, что ваш лимит был проигнорирован.

Измерено на openai/gpt-6-astra, запрос каждый раз одинаковый:

Между выданным и запрошенным количеством нет никакой связи. Переход на max_completion_tokens — параметр, который обычно нужен моделям OpenAI с рассуждениями, — ничего не меняет.

Это специфика Astra, а не шлюза. Тот же запрос к GPT-5.6 Sol на том же эндпоинте отрабатывает корректно:

Sol обрезает и сообщает length. Astra игнорирует и сообщает stop.

Во что это обходится. При $50 за миллион выходных токенов запрос, рассчитанный на 50 токенов ($0.0025) и вернувший 2900 ($0.145), — это 58-кратное превышение сметы. На цикле из 10 000 таких вызовов получается $25 по плану против $1450 по счёту. Если у вас есть защита от перерасхода, построенная на max_tokens, на этой модели она ничего не защищает.

Что делать вместо этого прямо сейчас:

• Ограничивайте в самом запросе. «Ответь одним предложением» действительно работает; max_tokens — нет.
• Понижайте reasoning.effort. Токены рассуждений тарифицируются по цене вывода и составляют основную часть перерасхода.
• Ставьте оповещения на usage, а не на свой запрос. Читайте completion_tokens из каждого ответа и настройте тревогу по суммарному объёму. Параметры вашего запроса здесь не являются средством контроля расходов.
• Ограничивайте на уровне шлюза или аккаунта, если провайдер это позволяет, раз рычаг на уровне отдельного запроса не работает.

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

Ошибки и их настоящие тела

model_not_found

{"error":{"message":"Model 'gpt-6' not found","type":"model_not_found","code":404}}

Такой строки в каталоге нет. Действительные идентификаторы:

• openai/gpt-6-astra
• псевдонимы gpt-6-astra и gpt-6-astra-2026-09-03

Два типичных способа сюда попасть:

Голое gpt-6. Возвращает 404. Собственный API OpenAI в некоторых случаях разрешает короткие имена через псевдонимы; шлюз не угадывает.

Суффикс уровня. gpt-6-astra-sol даёт тот же 404:

{"error":{"message":"Model 'gpt-6-astra-sol' not found","type":"model_not_found","code":404}}

GPT-5.6 вышла как Sol, Terra и Luna. У GPT-6 уровней нет — есть Astra и Astra Pro. Любой роутер или шаблон конфигурации, который собирает строку модели, дописывая уровень, на этом семействе сломается. Что ещё ломает эта смена именования, разобрано в сравнении поколений.

invalid_api_key

{"error":{"message":"Invalid or expired API key","type":"invalid_api_key","code":401}}

Ключ неверный, отозванный или от другого аккаунта. Проверьте, что Authorization выглядит как Bearer <key> и что ключ действительно загрузился из окружения, а не оказался молча пустым: пустая переменная даёт именно эту ошибку, а не сообщение об отсутствующем заголовке — поэтому люди и ищут не в том слое.

Если проблема именно в Codex CLI, а не в сыром вызове API, различия в путях аутентификации там разобраны в Codex CLI 401 Unauthorized.

invalid_request_error — отсутствует поле

{"error":{"message":"Missing required parameter: 'messages' is required. [ofox.ai]","type":"invalid_request_error","code":400}}

Отсутствует обязательное поле. Стоит заметить суффикс [ofox.ai]: он помечает ошибку, сгенерированную на шлюзе, а не переданную снизу. Когда вы разбираетесь, какой слой отклонил запрос, этот тег говорит вам, что запрос вообще не покидал шлюз.

invalid_request_error — недопустимое значение параметра

{"error":{"code":null,"message":"Unsupported value: 'reasoning_effort' does not support 'ultra' with this model. Supported values are: 'none', 'low', 'medium', 'high', and 'xhigh'.","param":null,"type":"invalid_request_error"}}

Вы отправили значение, которое модель не принимает. Это не то же самое, что отсутствующее поле: поле существует, а значение — нет.

Но списку доверять не стоит. В ошибке названы пять значений и пропущено max. Мы проверили все шесть на живом эндпоинте, и каждое вернуло успешный ответ:

То есть текст ошибки устарел или неполон, а не авторитетен. max — реальная настройка, и наш обзор объясняет, почему это редко та настройка, которая вам нужна: по сторонним измерениям она даёт один пункт индекса сверх high примерно за вдвое большие деньги.

Что ошибкой не является

Длинный ответ — не сбой. С учётом описанного выше поведения max_tokens самая частая жалоба «что-то не так» на этой модели — ответ намного длиннее ожидаемого. Так модель сейчас и работает, и счёт выставляется соответственно.

Пустой content при наличии токенов рассуждений — тоже не сбой. На моделях с рассуждениями низкий потолок может быть целиком израсходован на рассуждения до появления видимого текста, и тогда content пуст, а completion_tokens_details.reasoning_tokens заполнено. Здесь нужно поднять потолок, а не повторять запрос. Правда, на Astra потолок всё равно не соблюдается, так что если вы это увидели — сначала посмотрите usage, а потом решайте, какая из причин ваша.

Работающий запрос

curl -X POST https://api.ofox.io/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-6-astra",
    "messages": [{"role": "user", "content": "Answer in one sentence: what is quicksort?"}],
    "reasoning": {"effort": "high"}
  }'

Обратите внимание, что здесь делает работу: ограничение длины сидит в самом запросе, а не в max_tokens. Прочитайте usage.completion_tokens в ответе и сравните с ожиданиями, прежде чем разворачивать это в цикл.

Что можно вызвать и по какой цене — определяет GET https://api.ofox.io/v1/models, а не эта страница.

Читайте также

• Цены GPT-6 Astra API — во что на самом деле обходятся описанные выше токены, включая наценку за длинный контекст на 272K.
• Обзор GPT-6 Astra — картина независимых бенчмарков и кривая стоимости по уровням effort.
• GPT-6 Astra в Codex, Cursor, Cline и DSH — рабочие конфигурации для каждого агента.
• GPT-5.6 model not available — версия той же проблемы с именованием в прошлом поколении, включая случай Codex с аккаунтом ChatGPT.

Источники

• https://ofox.io/models/openai/gpt-6-astra
• https://developers.openai.com/api/docs/models/gpt-6-astra

Каждое тело ошибки на этой странице получено живыми запросами к эндпоинту Ofox /v1/chat/completions 6 сентября 2026 года. Измерения по max_tokens — это четыре запроса к openai/gpt-6-astra и один контрольный к openai/gpt-5.6-sol, с одинаковым промптом и различием только в проверяемом параметре. Это малая выборка на одном маршруте за один день, а не спецификация — проверьте на своём аккаунте, прежде чем строить на этом модель расходов. На других маршрутах, включая прямой OpenAI, текст ошибок использует другую оболочку.