Codex не находит GPT-5.5: как разобраться с ошибкой 404

Если Codex сообщает, что gpt-5.5 не существует или у вас нет доступа, проверьте сочетание идентификатора модели, провайдера и способа авторизации, прежде чем менять подписку. Успешный вход в ChatGPT не подтверждает доступ через API-ключ, а действующий ключ провайдера не означает, что провайдер принимает указанный в настройках идентификатор модели.

Это руководство предназначено для сессий Codex CLI с такой ошибкой:

unexpected status 404 Not Found: The model `gpt-5.5` does not exist or you do not have access to it.

Сообщение указывает запрошенную модель, но не причину сбоя. Оно не доказывает, что GPT-5.5 сняли с обслуживания. Приведённые ниже шаги основаны на официальной документации Codex по настройке и авторизации, проверенной 8 сентября 2026 года. Они не означают, что GPT-5.5 доступна всем аккаунтам или у всех провайдеров.

Начните с проверки подключения, а не с переустановки

В том же терминале, где возникает ошибка Codex, выполните:

codex --version
codex login status
codex --help

Запишите версию и способ авторизации. Также отметьте каталог, из которого запущен Codex, аргументы --model, --profile и -c, если они были, и запускалась ли сессия из IDE. Не передавайте API-ключи, токены доступа или содержимое auth.json.

codex login status показывает состояние авторизации, но не даёт полного отчёта об адресе API, выбранном через пользовательского провайдера. Сопоставьте его вывод с настройками провайдера.

OpenAI описывает разницу между доступом по подписке ChatGPT и использованием API-ключа с оплатой по факту. Не смешивайте эти способы подключения при диагностике.

Найдите настройку, которую Codex действительно использует

Частая ошибка при диагностике — редактировать пользовательский конфигурационный файл, пока команда запуска по-прежнему выбирает другую модель. Просмотрите нужные файлы локально и запишите только необходимые поля:

model
model_provider
openai_base_url
model_providers.<provider>.base_url
model_providers.<provider>.env_key
model_providers.<provider>.requires_openai_auth

Согласно текущей документации по основам настройки, приоритет убывает в таком порядке:

1. Флаги CLI и переопределения через --config.
2. Настройки доверенного проекта: приоритет имеет файл, ближайший к рабочему каталогу.
3. Файл профиля, выбранный через --profile.
4. Пользовательские настройки в ~/.codex/config.toml.
5. Системные настройки, затем встроенные значения по умолчанию.

Есть существенное ограничение: в текущей документации по расширенной настройке указано, что настройки проекта игнорируют связанные с провайдером ключи, в том числе model_provider, model_providers и openai_base_url, с предупреждением при запуске. Определения провайдеров нужно хранить в пользовательской конфигурации. При этом проект всё ещё может переопределять другие разрешённые параметры, включая модель, поэтому проверка лишь одного файла может не выявить несоответствие.

В текущей документации файлы профилей имеют вид ~/.codex/profile-name.config.toml. В старых руководствах может использоваться другая структура профилей. Прежде чем копировать любой из вариантов, проверьте установленную версию.

Исправьте настройки нужного способа подключения

Если вы хотели войти через ChatGPT

Проверьте аккаунт и рабочее пространство, затем выберите модель, которая действительно доступна в этой сессии. Удалите устаревшее переопределение модели из команды запуска или из того уровня конфигурации, где оно задано. Если модели нет в списке, проверьте её доступность для аккаунта: ручной ввод gpt-5.5 не предоставляет доступ.

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

Если вы хотели использовать API-ключ OpenAI

Убедитесь, что запрос идёт на нужный адрес API OpenAI и использует нужный API-аккаунт и проект. Сравните запрошенный идентификатор со списком моделей, доступных этому аккаунту сейчас. Прежде чем считать, что запрос отклонил OpenAI, проверьте, не осталось ли в openai_base_url старого адреса прокси.

Доступ к API и его оплата не связаны с включённым в план ChatGPT объёмом использования. Если с тем же ключом работает другая модель, это полезная информация о подключении, но не доказательство доступа к GPT-5.5.

Если вы хотели использовать стороннего провайдера

URL, идентификатор модели и ключ должны соответствовать друг другу. Провайдер может использовать идентификатор модели с пространством имён. Возьмите значение из его документации, а не добавляйте и не убирайте префикс наугад.

Ниже приведён шаблон конфигурации, а не рабочий адрес API или подтверждение доступности GPT-5.5. Замените оба заполнителя значениями вашего провайдера. Добавьте эти записи в пользовательскую конфигурацию, объединив их с существующими разделами, а не создавая дубликаты:

model = "REPLACE_WITH_PROVIDER_MODEL_ID"
model_provider = "diagnostic_provider"

[model_providers.diagnostic_provider]
name = "My provider"
base_url = "https://api.example.com/v1"
env_key = "PROVIDER_API_KEY"
requires_openai_auth = false
wire_api = "responses"

Выбранный провайдер должен поддерживать Responses API: в текущем справочнике конфигурации Codex responses указан как единственное поддерживаемое значение wire_api. Шаблон не подойдёт провайдеру, который предлагает только Chat Completions. Задайте PROVIDER_API_KEY привычным для вас способом локального хранения секретов; не вставляйте секретный ключ в общий TOML-файл.

По умолчанию requires_openai_auth равен false. Здесь он указан явно, чтобы шаблон использовал ключ провайдера. Если в существующем определении провайдера задано true, Codex использует авторизацию OpenAI и игнорирует env_key. Проверьте этот параметр, если кажется, что ключ провайдера не влияет на подключение.

Перед редактированием сохраните копию конфигурации. Не удаляйте настройки, не относящиеся к проблеме. После правок запустите новую сессию из того же каталога и отправьте небольшой запрос, который не требует от Codex редактировать файлы. Использование API может быть платным. Если изменение нарушило ранее работавшее подключение, восстановите сохранённую конфигурацию.

Более подробная инструкция есть в статье о подключении собственных провайдеров моделей в Codex. Если вы используете Ofox, перед настройкой проверьте точный идентификатор и поддерживаемый способ подключения в актуальном каталоге моделей.

Уточните причину по следующему ответу

Если сравниваете прямой API-запрос с запросом Codex, используйте те же хост, ключ, модель и эндпоинт Responses. Успешный запрос Chat Completions к другому хосту не позволяет отнести проблему к Codex. Успешный прямой запрос с совпадающими параметрами даёт повод проверить конфигурацию Codex или различия в запросах, но ещё не доказывает, какое именно различие вызвало ошибку.

Локальное предупреждение model metadata ... not found тоже отличается от HTTP 404. Сохраните окончательный ответ сервера, не предполагая, что у этих сообщений одна причина. Для других SDK и случаев с Azure воспользуйтесь общим руководством по ошибкам model not found в OpenAI.

Что передать в поддержку, если проблема осталась

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

По такому отчёту поддержка сможет отличить недоступность модели для аккаунта от устаревшего переопределения или несоответствия провайдера. Это полезнее, чем одновременно менять аккаунт, модель и адрес API и терять исходные данные для диагностики.

Источники

• Авторизация в OpenAI Codex
• Основы настройки OpenAI Codex
• Расширенная настройка OpenAI Codex
• Справочник конфигурации OpenAI Codex
• Справочник CLI OpenAI Codex