Codex остановился с 429: как найти причину и не зациклить повторы

Что именно означает это сообщение

Строка exceeded retry limit, last status: 429 Too Many Requests сообщает о двух событиях, но не называет первопричину. Какой-то сервис вернул HTTP 429, затем Codex или подключённый клиент несколько раз повторил запрос и прекратил попытки после исчерпания собственного лимита повторов.

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

Сначала нужно выяснить, куда фактически ушёл запрос:

• сессия Codex авторизована через аккаунт ChatGPT;
• используется API-ключ OpenAI;
• в конфигурации выбран другой model provider, прокси или API-шлюз.

Это не формальность. У этих маршрутов разные лимиты, панели состояния и службы поддержки. Одинаковый текст 429 не делает их одной и той же ошибкой. В частности, наличие действующей подписки ChatGPT и остатка лимита Codex не подтверждает наличие API-кредитов в проекте, а положительный API-баланс не объясняет ограничение сессии, авторизованной через ChatGPT.

Быстрая развилка: где искать ограничение

1. Авторизация через ChatGPT. Сначала проверьте /usage, затем /status и состояние сервиса. Полезные признаки — остаток и время сброса лимита, модель и параметры текущей сессии.
2. API-ключ OpenAI. Сохраните полный error.type и error.code, заголовок Retry-After, а также проверьте проект и организацию. Эти данные помогают отличить временный rate limit от проблем с балансом, spend limit или usage limit.
3. Внешний provider или gateway. Уточните активный provider, откройте его панель лимитов и сохраните исходный ответ upstream. Ищите собственный код провайдера, request ID, квоту или ограничение шлюза.

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

Если Codex работает через аккаунт ChatGPT

В поддерживаемых интерфейсах Codex команда /usage показывает активность и сведения о сбросе лимитов, а /status — конфигурацию сессии и расход токенов. Доступность и конкретный вывод зависят от версии и интерфейса; актуальное назначение команд описано в официальном справочнике Codex.

Совпадение ошибки с исчерпанным лимитом и указанным временем сброса — сильный практический сигнал. В этом случае разумно дождаться отображаемого сброса или уменьшить объём работы. Но «оставалось ещё много процентов» не доказывает, что сбоя на стороне сервиса нет, а один вывод /usage не объясняет каждый возможный 429.

Расход Codex нельзя надёжно пересчитать в фиксированное количество сообщений. На него влияют модель, размер и сложность задачи, контекст, reasoning, инструменты, retrieval и caching; локальные и облачные задачи могут использовать общее пятичасовое окно, а также могут действовать недельные ограничения. Условия зависят от продукта и плана, поэтому сверяйте их на странице актуальных лимитов Codex, а не по старой таблице из обсуждения.

Если запрос идёт по API-ключу OpenAI

Для API статус 429 объединяет несколько разных ситуаций. Официальный справочник ошибок API различает, в частности, временное ограничение частоты, исчерпание кредитов, лимит расходов организации или проекта и лимит использования организации. Смотрите не только HTTP-статус, но и полный безопасно сохранённый payload, особенно error.type и error.code.

• Временный rate limit требует снизить частоту или объём и выдержать паузу.
• Исчерпанный баланс требует решить вопрос с кредитами или биллингом.
• Spend limit требует проверить лимиты соответствующих проекта и организации.
• Usage limit требует действия в той системе лимитов, которая указана в ответе.

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

Если в ответе есть Retry-After, считайте его минимальным временем ожидания. Если заголовка нет и ошибка действительно временная, собственный HTTP-клиент может использовать экспоненциальную задержку с jitter — небольшой случайной добавкой, чтобы несколько клиентов не повторяли запрос одновременно. Ограничьте и число попыток, и общее время ожидания. Это правило относится к временным API rate limits, а не к оплате, квоте или сервисному инциденту (рекомендации OpenAI по повторам).

Если настроен внешний provider или шлюз

В этом случае 429 может исходить не от OpenAI. Сначала зафиксируйте активный provider и базовый адрес маршрута, затем откройте его собственную панель квот и документацию. Запрос мог быть принят шлюзом, отклонён нижестоящим сервисом или ограничен самим посредником — у каждого уровня может быть свой request ID и своя политика повторов.

Параметр model_providers.<id>.stream_max_retries в Codex управляет повторами при обрывах SSE-потока; документированное значение по умолчанию — 5 (справочник config.toml). Само наличие этой настройки не доказывает, что текущий 429 возник из-за SSE или что увеличение значения поможет. Если upstream стабильно отвергает каждый запрос, больше повторов лишь дольше скрывает неизменившуюся причину.

Соберите минимальный набор диагностики

До нового запуска сохраните данные, которые позволят сравнить попытки и при необходимости передать проблему поддержке:

1. Точное местное время ошибки с часовым поясом.
2. Способ авторизации и фактический provider без самого ключа.
3. Модель и интерфейс Codex, в котором возник сбой.
4. Полный тип и код ошибки, но без секретов и персональных данных.
5. Retry-After и другие относящиеся к лимиту заголовки, если они доступны.
6. Request ID или идентификатор потока/задачи.
7. Вывод /usage и релевантную часть /status для ChatGPT-маршрута либо проект, организацию и состояние лимитов для API-маршрута.
8. Результат одного контролируемого повтора после предписанной паузы.

Не вставляйте в публичный issue API-ключ, полный конфигурационный файл, приватный prompt, данные клиента или необработанный лог. Перед отправкой даже в поддержку проверьте, не раскрывают ли request ID, адрес шлюза и идентификаторы задачи внутреннюю инфраструктуру или данные клиента. Оставьте структуру события и временные метки, а чувствительные значения замените понятными метками вроде [REDACTED_API_KEY]; исходные идентификаторы передавайте только через подходящий закрытый канал, если они нужны для расследования.

Ценность этого набора — не в объёме. Он позволяет отличить устойчивую ошибку конкретного аккаунта или проекта от краткого инцидента и увидеть, действительно ли последующие ответы совпадают с первым.

Когда повторять, ждать или остановиться

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

Остановите автоматические повторы, если:

• payload указывает на баланс, billing, spend limit или исчерпанную квоту;
• /usage показывает достигнутый лимит с будущим временем сброса;
• внешний provider стабильно возвращает одну и ту же ошибку до обработки запроса;
• каждый ответ после корректной паузы совпадает, а новых диагностических сигналов нет;
• повтор увеличивает расходы или может продублировать действие с побочным эффектом.

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

Не используйте VPN, смену IP или очистку кэша как универсальное лечение. Эти действия не следуют из сообщения и могут усложнить сравнение попыток. Меняйте только один фактор за раз и записывайте результат.

Как распознать временный сервисный инцидент

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

В январе 2026 года сотрудники OpenAI действительно отнесли один случай с таким сообщением Codex к сервисной проблеме. После устранения они отдельно предупредили, что новое появление того же симптома может иметь другую причину и требует повторной диагностики (комментарий в openai/codex). Это полезный пример неоднозначности, но не основание объявлять любой сегодняшний 429 сбоем OpenAI.

Если локальные данные не объясняют ошибку, передайте обезличенный набор диагностики через доступный канал поддержки. В Codex команда /feedback предназначена для отправки диагностических данных сопровождающим продукта; её доступность зависит от интерфейса. Кратко укажите маршрут, время, request ID, уже проверенные лимиты и результат контролируемого повтора. Такой отчёт полезнее серии новых попыток без изменившихся условий.

Критерий восстановления

Считать проблему решённой стоит не после исчезновения красного сообщения, а после успешного контролируемого запроса по тому же маршруту и понимания, что изменилось: сбросился лимит, восстановился сервис, пополнен баланс, исправлен проект или снято ограничение внешнего провайдера.

Если причина всё ещё неизвестна, безопасный результат диагностики — не очередной retry, а зафиксированная граница: какой маршрут использовался, какие классы причин исключены наблюдаемыми данными и кому переданы оставшиеся идентификаторы. Это предотвращает бесконечный цикл и сохраняет информацию, необходимую для реального исправления.