Диагностика GPT-5.6 в Codex

Запуск GPT-5.6 в Codex завершился ошибкой, но сама ошибка не показывает, что именно нужно исправить. У ключа может не быть доступа к модели, базовый путь /v1 может быть указан неверно, а прямой запрос к Responses может выполняться успешно, хотя провайдер отклоняет метаданные, которые добавляет Codex. Повтор той же команды обычно лишь воспроизводит ошибку и сам по себе не показывает, на каком уровне произошёл сбой.

Этот бесплатный набор последовательно проверяет каждый уровень. Он сверяет точные ID моделей и базовый ответ Responses; в SSE требует точного текстового маркера и завершающего события response.completed; при проверке функции — вызова указанной функции с точными JSON-аргументами. Затем набор запускает Codex с временными настройками провайдера в пустом рабочем каталоге и формирует единый очищенный JSON-отчёт. Прямые проверки отправляют только фиксированные маркеры, а smoke-тест не меняет существующую конфигурацию Codex. Набор проверяет совместимость, но не сравнивает качество моделей.

Что именно доказывает проверка

Тесты намеренно разделены на уровни:

1. GET /v1/models подтверждает, что ключ видит каждый точный ID модели.
2. Минимальный нестриминговый запрос к Responses проверяет базовую генерацию и совпадение ID модели в ответе.
3. SSE-проверка требует точного текстового маркера и завершающего события response.completed.
4. Строгая проверка функции требует вызова функции с заданным именем и точных аргументов JSON.
5. Изолированный запуск codex exec проверяет установленный Codex CLI через того же провайдера.

Успех на одном уровне ничего не гарантирует на следующем. Именно в этом и состоит польза раздельной диагностики: если прямые API-проверки проходят, а сбой есть только в codex_cli_smoke, замена API-ключа или ID модели вряд ли устранит настоящую причину.

Запуск без изменений текущей конфигурации

Положите check.mjs и скрипт запуска для своей оболочки в один каталог. В Bash или Zsh считайте ключ без вывода его значения и без записи самого ключа в историю команд:

chmod +x run.sh
printf 'OmniaKey API key: ' >&2
IFS= read -r -s OMNIAKEY_API_KEY
printf '\n' >&2
export OMNIAKEY_API_KEY
./run.sh
unset OMNIAKEY_API_KEY

В Windows PowerShell:

$secureKey = Read-Host 'OmniaKey API key' -AsSecureString
$env:OMNIAKEY_API_KEY = [System.Net.NetworkCredential]::new('', $secureKey).Password
.\run.ps1
Remove-Item Env:OMNIAKEY_API_KEY
$secureKey = $null

По умолчанию набор проверяет базовый вывод Responses на Sol, Terra и Luna, а затем стриминг, формирование вызова функции и полный путь через Codex на Sol. Это пять фиксированных прямых генераций и один изолированный сеанс Codex, если Codex установлен. Сам набор бесплатный, но использование API может тарифицироваться.

Флаг --full повторяет углублённые проверки на всех трёх моделях: девять прямых генераций и три сеанса Codex. Число повторов для прямых API-запросов и оба лимита повторов провайдера Codex выставлены в ноль; набор не пытается искусственно вызвать 429. Если модель проигнорирует фиксированное указание не использовать инструменты и запустит цикл работы с ними, в рамках одного сеанса Codex может уйти ещё один запрос к модели, а отчёт отметит проверку как неудачную:

./run.sh --full

Чтобы проверить одну модель без запуска Codex:

./run.sh --model gpt-5.6-terra --skip-codex

Ключ принимается только через переменную окружения и никогда не передаётся аргументом командной строки. Приведённые выше команды скрытого ввода не записывают его буквальное значение в историю оболочки; однако, как и любую переменную окружения процесса, ключ могут прочитать локальные процессы с достаточными правами, пока он задан. Перед записью отчёта скрипт удаляет точное значение ключа, а также распространённые формы Bearer и sk-... из всех строковых полей, содержимое которых контролирует провайдер.

Что попадает в отчёт

В каждом отчёте указаны версия набора, временная метка UTC, origin и базовый путь эндпоинта, операционная система, архитектура, версии Node и Codex, выбранные модели, оба таймаута и явные нулевые лимиты повторов. В зависимости от уровня и результата применимые поля проверки могут включать:

• запрошенный и возвращённый ID модели;
• статус pass, fail или skip;
• HTTP-статус и разрешённые заголовки ответа с ID запроса и данными об ограничениях частоты запросов и токенов;
• ID ответа и расход токенов, если эндпоинт их возвращает;
• длительность и точное невыполненное условие контракта либо причина пропуска;
• нормализованная категория ошибки без API-ключа и исходного тела ответа.

На POSIX-системах файл создаётся с правами доступа только для владельца. ID запросов не являются учётными данными, но перед публикацией отчёт всё равно нужно просмотреть: по ним провайдер может найти конкретный запрос.

Код выхода 0 означает, что прошли все выполненные проверки. 1 — что хотя бы одна выполненная проверка завершилась ошибкой. 2 — что неверны аргументы, переменная окружения с ключом, URL или другое предварительное условие. Отсутствующий Codex получает статус skip, а не маскируется под ошибку API.

Проверенные факты о GPT-5.6

Сейчас OpenAI документирует следующие точные API ID и назначения:

Алиас gpt-5.6 сейчас направляет запросы на gpt-5.6-sol. Для диагностики используйте явные ID: алиас добавляет вопрос о маршрутизации, который проверке совместимости ни к чему.

На страницах всех трёх моделей сейчас указаны контекстное окно API на 1,050,000 токенов, максимум 922,000 входных и 128,000 выходных токенов, а также knowledge cutoff 2026-02-16. Там же заявлена поддержка Responses, Chat Completions и Batch, а также стриминга, structured outputs и function calling. Первичные источники: страницы Sol, Terra и Luna.

Это ограничения API-моделей, а не обещание, что любая конфигурация клиента Codex откроет всё окно целиком. У Codex есть собственный каталог моделей, параметр model_context_window и автоматическая компактизация. Набор не отправляет промпт на миллион токенов и не выводит эффективное окно Codex из указанного для API максимума.

Минимальная конфигурация провайдера для Codex

Текущая конфигурация Codex хранит кастомные провайдеры в файле ~/.codex/config.toml на уровне пользователя. В актуальном справочнике конфигурации единственным поддерживаемым значением wire_api указан responses. Минимальный пример для OmniaKey:

model = "gpt-5.6-sol"
model_provider = "omniakey"

[model_providers.omniakey]
name = "OmniaKey"
base_url = "https://api.omniakey.com/v1"
env_key = "OMNIAKEY_API_KEY"
wire_api = "responses"

env_key и requires_openai_auth — альтернативные способы аутентификации. В актуальной документации Codex по аутентификации указано: при requires_openai_auth = true значение env_key игнорируется. Не добавляйте этот параметр в данный блок провайдера.

Перед редактированием настоящей конфигурации сделайте резервную копию:

cp ~/.codex/config.toml ~/.codex/config.toml.before-gpt56

Эквивалент для PowerShell:

Copy-Item "$HOME\.codex\config.toml" "$HOME\.codex\config.toml.before-gpt56"

Набор не требует редактировать этот файл или использовать заданные в нём настройки провайдера. Smoke-тест Codex игнорирует пользовательскую конфигурацию, создаёт временный CODEX_HOME, передаёт настройки провайдера только этому процессу, использует пустой рабочий каталог и read-only sandbox, а затем удаляет временный каталог. Процесс получает только ключ и разрешённый набор переменных окружения для среды выполнения, локали, временного каталога, прокси и TLS; в отчёт попадают их имена, но никогда не значения.

Песочница в режиме read-only запрещает запись, но не исключает всех возможных операций чтения. Фиксированный промпт с запретом на использование инструментов проверяется, однако строгой границей безопасности не является. Используйте --skip-codex либо запускайте набор в изолированном контейнере или виртуальной машине, если на компьютере есть файлы, которые процесс Codex не должен иметь возможности прочитать.

Перед постоянными изменениями сверьтесь со справочником конфигурации Codex и руководством OmniaKey по программным агентам.

Читайте ошибки по уровням, а не по догадкам

Не сводите 401 и 403 к одному диагнозу. Обычно 401 указывает на аутентификацию, а 403 может означать, что распознанной учётной записи не хватает прав. Аналогично, 404 может появиться и из-за неверного базового пути /v1, и при корректном пути, если модель недоступна.

Руководство OpenAI по ошибкам советует при bad request проверять форму запроса, при rate limit снижать темп вызовов, а при серверных ошибках делать краткий повтор. Этот набор намеренно оставляет повторы вам, чтобы первый сбой оставался виден.

Актуальная ловушка кастомных провайдеров

Два открытых отчёта Codex — #31870 и #31882 — описывают сбои GPT-5.6 через Azure и кастомные провайдеры в Codex 0.144.x. В приведённых случаях прямые запросы Responses проходили, а запросы Codex возвращали 400 с упоминанием X-OpenAI-Internal-Codex-Responses-Lite или зарезервированного пространства имён collaboration.

Это полевые отчёты, а не доказательство того, что ломается каждый кастомный провайдер. Именно поэтому набор разносит прямые проверки и проверки через Codex по разным уровням.

Если отчёт показывает такое расхождение:

1. Сохраните codex_version, точную категорию ошибки и ID запроса.
2. Обновитесь до последнего стабильного выпуска Codex и повторите запуск той же версии набора.
3. Проверьте, остаются ли оба issue открытыми и опубликовал ли maintainer исправление.
4. Если сбой сохраняется, отправьте очищенный отчёт своему провайдеру или в поддержку Codex.

В отчёте об ошибке #31882 описана конфигурация, которая полностью переопределяет каталог моделей и отключает Responses-Lite и метаданные для многоагентного режима. Это хрупкое решение: переопределение заменяет метаданные каталога, может устареть после обновления и отключить нужное вам поведение. Версия 1.0.0 этого набора распознаёт описанные признаки сбоя, но намеренно не изменяет Codex и не предлагает незаметно откатываться на предыдущую версию.

Что этот набор не измеряет

Это проверка совместимости, а не бенчмарк качества моделей. Она не сравнивает точность программирования, работу с длинным контекстом, долю попаданий в кэш, задержку в production, время прогрессивной отправки SSE-событий, фактически списанную стоимость, ввод изображений, hosted tools, multi-agent-сценарии или полный цикл продолжения запроса после вызова функции. Зелёный отчёт означает лишь, что проверенные контракты один раз сработали с записанными версиями и эндпоинтом. Он не гарантирует одинакового результата для всех видов нагрузки и не обеспечивает изоляцию файловой системы на уровне процесса.

Для воспроизводимости сохраните созданный отчёт и точные файлы набора. Проверяйте загрузки по SHA256SUMS, повторяйте запуск после изменения Codex или провайдера и сравнивайте отдельные проверки, а не только итоговый статус.

Проверенные источники

• Using GPT-5.6
• GPT-5.6 models in Codex
• Страница модели GPT-5.6 Sol
• Страница модели GPT-5.6 Terra
• Страница модели GPT-5.6 Luna
• Справочник конфигурации Codex
• Аутентификация Codex с альтернативными провайдерами
• Руководство OpenAI по ошибкам API
• Issue Codex #31870 и #31882 — на момент проверки оба были открыты