Активная подписка ChatGPT не объясняет, почему подключённое к OpenAI приложение получило ошибку 429. Этот ответ может означать как слишком интенсивные запросы, так и исчерпанные API-кредиты или достигнутый лимит расходов. В первом случае пауза может помочь; во втором повторение того же запроса не устраняет причину.
Сначала выясните, что оплачено и откуда идёт запрос
API — способ, которым приложение обращается к модели напрямую. Его расчёты и ограничения нужно проверять отдельно от статуса подписки в ChatGPT. При этом правило «подписка никогда не включает API» слишком категорично: в описанных условиях для подходящих подписок Pro и Business предусмотрены API-кредиты. Льготу нужно активировать и связать с API-организацией; у кредитов есть срок действия, а ограничения частоты запросов сохраняются. Применимость условий проверяют отдельно.
Сопоставьте настройки приложения, используемый ключ доступа, организацию и проект. Учебный пример: кредиты есть в личной организации, а приложение отправляет запросы из рабочего проекта другой организации. Положительный баланс в открытой вкладке браузера ничего не доказывает о таком запросе. Перевыпуск ключа наугад тоже не объяснит, какой бюджет используется.
Разбор ниже относится к прямому OpenAI API, а не к стороннему посреднику с похожим интерфейсом. Его основа — учебные ответы и описание документации, проверенной автором исходного туториала 31 октября 2026 года. Это не сообщение о массовом сбое или изменении тарифов.
Одного числа 429 недостаточно
До следующей попытки сохраните время с часовым поясом, статус ответа, модель, проект и идентификатор запроса x-request-id, если он пришёл. Для выбора действия нужны код причины error.code и тип ошибки error.type из тела ответа. Пригодятся и заголовки: Retry-After с указанием паузы и доступные x-ratelimit-* со сведениями об ограничениях.
Не сохраняйте весь сетевой ответ без разбора: туда могут попасть ключ доступа, cookie или пользовательский документ. Даже текст ошибки стоит проверить на чувствительные данные перед записью в общий журнал. Если разбирается владелец приложения, а не разработчик, полезно передать исполнителю именно этот список технических признаков — без секретов.
При ошибках оплаты общий тип может оставаться insufficient_quota, а более точная причина находиться в error.code. Поэтому выбирать действие только по HTTP-статусу или слову quota недостаточно.
- credit_balance_exhausted — проверьте баланс той API-организации, от имени которой пришёл запрос; автоматические повторы остановите.
- project_spend_limit_exceeded — проверьте жёсткий лимит расходов конкретного проекта.
- organization_spend_limit_exceeded — проверьте жёсткий лимит расходов организации.
- organization_usage_limit_exceeded — проверьте разрешённый OpenAI месячный объём использования. Это не то же самое, что нехватка денег на балансе.
- Подтверждённое ограничение запросов или токенов — возможен повтор с паузой. Код slow_down требует снизить скорость наращивания трафика.
- Неизвестный код или потерянное тело ошибки — сначала разберите исходный ответ и работу посредника; не назначайте причину по догадке.
Уведомление о расходах — ещё не остановка работы
У бюджета есть разные режимы. Уведомление о расходах, Spend alert, само по себе не прекращает обращения к API. Жёсткий лимит расходов, Hard spend limit, способен их остановить. Организационный лимит охватывает проекты организации, проектный — один проект. Ограничение применяется не мгновенно, поэтому учтённые расходы могут немного превысить заданное значение.
Если один проект работает, а другой нет, сравните их настройки и коды ошибок. Это повод проверить область ограничения, но не готовый диагноз: могут различаться ключи, модели и нагрузка. Повышать бюджет должен его владелец, а не автоматический обработчик ради восстановления работы любой ценой.
Когда пауза действительно уместна
Ограничение числа запросов в минуту и ограничение объёма текста в токенах за минуту — разные проверки. Токены — единицы, на которые модель разбивает текст. Нужно учитывать модель и область действия ограничения: некоторые модели делят общий лимит. А slow_down может появиться из-за резкого наращивания трафика даже без исчерпания этих минутных лимитов.
При подтверждённой временной ошибке корректный Retry-After задаёт минимальную паузу. Если такой подсказки нет, используют увеличивающиеся задержки со случайной добавкой, ограничивая число попыток и общее время ожидания. Нельзя сокращать запрошенную сервером долгую паузу до удобной короткой: если операция столько ждать не может, её откладывают.
Проверьте встроенные повторы библиотеки. Официальная Python-библиотека OpenAI по умолчанию повторяет определённые ошибки дважды; max_retries=0 отключает этот механизм. Дополнительный цикл приложения должен учитывать эти попытки, а поведение — соответствовать установленной версии. Нескольким одновременно работающим процессам также нужно общее управление нагрузкой, а не только отдельные паузы.
Как понять, что выбран правильный следующий шаг
В учебном примере два ответа имеют одинаковые 429 и Retry-After: 2. При slow_down обработчик планирует паузу, а при credit_balance_exhausted останавливает повторы и направляет к проверке баланса. Наличие заголовка с задержкой не отменяет причину ошибки в теле ответа.
После исправления выполните один контролируемый запрос в прежнем проекте и проверьте новый ответ. Если причина неизвестна, сохранённые признаки помогут обсуждать конкретный отказ с поддержкой. Эти правила относятся к полученному HTTP-отказу до выдачи результата: после частичного ответа или уже выполненного внешнего действия сначала нужно установить, что произошло, а не запускать операцию заново.
Если подключение ещё только настраивается, отдельный гайд по подключению ИИ-агента к сайту поможет разобраться с вариантами интеграции. Но для уже полученного 429 главный ориентир — конкретная причина отказа, а не значок активной подписки.
