Если OpenAI Platform API возвращает quota exceeded, insufficient_quota или 429, не увеличивайте число retry автоматически. Сначала прочитайте тело ошибки: временное давление на requests или tokens требует backoff, throttling и queue; quota, billing, project scope, model access, status incident или wrapper limit требуют другой проверки.
| Сигнал | Вероятный владелец | Первая проверка | Retry или stop |
|---|---|---|---|
rate limit reached, too many requests, remaining headers near zero | request или token rate limit | headers, Limits, model family, reset window | retry с backoff и jitter, затем throttle или queue |
You exceeded your current quota или insufficient_quota | quota, billing или spend cap | Billing, Usage, Limits, monthly spend, account state | stop до изменения account state |
| новый key падает так же или падает один project/model | project, organization, model или key scope | selected project, organization, model access | исправить scope перед traffic changes |
| много вызовов падает и Status показывает incident | platform status или capacity | OpenAI Status, timestamp, request id | wait, preserve evidence |
| ошибка из ChatGPT, Codex, Sora, Azure или wrapper | wrong surface | product surface, provider docs, route, headers | перейти к этому контракту |
Стоп-правило простое: повторять можно только когда владелец ошибки - request/token pressure и есть сигнал reset. Если тело указывает на quota, billing, wrong project, wrong model, wrong surface или status incident, повторение того же запроса не лечит проблему.
Сначала прочитайте тело 429, а потом меняйте код
Официальная документация OpenAI разделяет как минимум две семьи 429: слишком быстрый трафик и исчерпанную текущую квоту. В рабочих обсуждениях обе ситуации часто называют одной и той же ошибкой, поэтому первое решение должен принимать не заголовок, а тело ответа. До изменения retry-политики сохраните message, code, type, endpoint, model, project, organization, timestamp и request id.
Безопасная классификация должна быть консервативной. Если встречается insufficient_quota или формулировка current quota, это остановка по квоте или биллингу. Если тело говорит rate limit или too many requests, а headers показывают remaining/reset, это временное давление и его можно обрабатывать retry. Если ветка не ясна, не меняйте сразу пять переменных: держите один маршрут запроса и собирайте доказательства.
Это важно в реальной эксплуатации. Неясная 429 легко ведет к неправильному ремонту: частый retry может съесть еще больше минутного лимита, новый key скрывает тот факт, что заблокирован тот же project, а изменение billing не в той organization вообще не затрагивает production-запрос.
10-минутный маршрут восстановления
Первые десять минут нужны не для случайных экспериментов, а для определения владельца проблемы. Скопируйте исходное тело и headers, откройте Limits, Billing и Usage для того же project и organization, подтвердите model family, проверьте OpenAI Status и только потом отправьте один меньший контролируемый запрос. Такая последовательность сохраняет доказательства читаемыми.
| Время | Действие | Что это доказывает |
|---|---|---|
| 0-1 | Сохранить body и headers | ветка rate, quota, billing или unknown |
| 1-3 | Проверить Limits, Usage и Billing | есть ли capacity или проблема account state |
| 3-5 | Сравнить model и endpoint | не задействована ли более строгая или общая model family |
| 5-7 | Проверить OpenAI Status | меняет ли публичный incident стратегию |
| 7-10 | Отправить один меньший контролируемый запрос | вероятнее workload size или account state |
Если меньший запрос проходит, проверяйте concurrency, token size, image throughput или fan-out. Если он снова падает с quota wording, остановите retry. Если несвязанные endpoints падают во время объявленного incident, сохраняйте evidence и ждите, а не переносите аккаунты.
Когда retry и backoff действительно нужны
Retry и backoff правильны только при временном давлении requests или tokens. Полезные сигналы: формулировка rate limit, низкие remaining values, reset timing и паттерн трафика, превышающий текущий budget project/model. Retry не чинит аккаунт; это инструмент ритма.
Используйте exponential backoff с jitter, ограничивайте число retry и ставьте центральный limiter на project и model family. Limiter внутри каждого worker недостаточен, если workers не делят состояние. Оценивайте token size до отправки: уменьшение prompt или max output может снять TPM-давление до отказа API.
Неудачные requests тоже могут учитыватьcя в минутных лимитах. Если весь fleet повторяет запрос каждую секунду, он сам удерживает себя в окне отказа. Хорошая система замедляется, ставит задачи в queue, сбрасывает несрочную работу или использует Batch для async-нагрузки.
Когда retry только ухудшает ситуацию
Retry неверен, когда ошибка указывает на insufficient_quota, current quota, billing, monthly spend или account state. Несколько секунд ожидания не добавят квоту. Правильный путь: Billing, Usage, Limits, spend cap, organization, project и model access.
Многие случаи "credits есть, но 429 остается" оказываются проблемами scope. Credits могут быть в другой organization, запрос может идти из другого project, monthly spend cap может оставаться активным, model может быть недоступна этому project, а wrapper может применять собственный pool. Пока проверяете scope, держите один минимальный запрос неизменным.
Почему новый API key может не помочь
API key не является отдельным bucket capacity. Новый key помогает, если старый отозван, утек, ограничен или привязан к wrong project. Он не создает capacity, если organization, project, model family и billing owner остаются теми же.
| Слой scope | Что проверить | Типичный сбой |
|---|---|---|
| Organization | request использует нужную org | personal и team org имеют разные billing или limits |
| Project | key принадлежит проверенному project | Limits смотрели в одном project, traffic идет из другого |
| Model family | выбранная model имеет access и headroom | более строгий или общий family limit исчерпан |
| Team workload | другие сервисы делят capacity | batch job или другое приложение съело pool |
Если падает только одна model, отправьте небольшой запрос к model, к которой project точно имеет access. Если все models падают с quota wording, сначала смотрите account state. Если key работает в другом сервисе, проверяйте concurrency и request shape в падающем сервисе.
Используйте headers и Limits как живые доказательства
Живые доказательства находятся в двух местах: response и account. Body дает ветку. Headers могут показать limit, remaining и reset timing. Страница Limits показывает текущий контекст project, organization и model. Любая статическая таблица слабее собственных live evidence читателя.
| Доказательство | Зачем оно нужно |
|---|---|
| status и body | отделяют retryable rate pressure от quota или billing |
| request id | дает support точку поиска |
| rate-limit headers | показывают limit, remaining и reset timing |
| project и organization | подтверждают владельца request |
| model и endpoint | выявляют строгий model limit или wrong endpoint |
| Limits и Usage state | фиксируют account state во время failure |
| Status snapshot | отделяет incident от локальной проблемы аккаунта |
29 апреля 2026 года публичная проверка OpenAI Status не показывала широкого активного incident. Это не гарантия на будущее. Во время собственной аварии проверяйте Status заново: если он green, продолжайте account scope, headers и workload shape.
Как снизить риск следующей 429 в production
После немедленного восстановления перенесите урок в production controls. Приложение должно знать свой budget до того, как OpenAI отклонит запрос: project/model limiters, tenant budgets, token estimates, queue alerts, retry counters и наблюдение за reset-window.
Interactive traffic и background jobs не должны слепо конкурировать. Ставьте несрочные задачи в queue, разделяйте tenants, уменьшайте prompt size, когда это возможно, и направляйте простую работу на более дешевые или менее нагруженные models, если это одобрено продуктово. Используйте Batch, когда latency не критична и workload подходит.
Сначала исключите чужую поверхность
"OpenAI API 429" должен означать Platform API call, сделанный кодом. ChatGPT, Codex, Sora, Azure OpenAI и wrappers тоже могут показывать limit messages, но владелец и repair path будут другими.
| Surface | Не предполагайте | Проверяйте вместо этого |
|---|---|---|
| ChatGPT | consumer plan меняет API quota | ChatGPT product limits и account state |
| Codex | лимиты coding-agent равны API RPM/TPM | Codex product contract и status |
| Sora | video capacity равна text API limits | Sora route, queue, plan и video status |
| Azure OpenAI | OpenAI Platform Limits управляет deployment | Azure quota, deployment, region и subscription |
| Wrapper | OpenAI headers всегда проходят без изменений | provider dashboard, docs, route id и upstream evidence |
Если запрос не отправляется напрямую на api.openai.com, сначала определите provider boundary. Wrapper может быть переполнен, может переводить upstream 429 в локальную ошибку или применять собственный account cap.
Эскалация с доказательствами
Эскалируйте только после стабилизации ветки и удаления секретов. Компактный пакет должен включать timestamp, timezone, request id, endpoint, model, SDK version, organization, project, billing owner, безопасные body и headers, Limits/Usage state, Status state, retry count, concurrency, prompt size, queue depth и recent changes.
Не публикуйте API keys, bearer tokens, card details, private prompts или user data в публичных местах. Чистые evidence быстрее для support и безопаснее для пользователей.
Часто задаваемые вопросы
Все ли OpenAI API 429 можно повторять?
Нет. Retry нужен только при временном request/token pressure. insufficient_quota и current quota exceeded требуют Billing, Usage, Limits, project, organization и model access.
Что означает insufficient_quota?
Это quota, billing, spend cap или account state, а не короткий всплеск трафика. Проверяйте тот же project и organization, откуда ушел запрос.
Почему 429 остается после пополнения?
Возможны другой organization/project, spend cap, задержка billing state, model access, shared model-family limit или provider wrapper pool.
Новые API keys увеличивают лимит?
Нет, если они остаются в том же project и organization. Новый key чинит credential problem, но не создает новый capacity pool.
Какие headers важны?
Limit, remaining и reset для requests/tokens, когда они есть. Их нужно читать вместе с live Limits page.
Нужно ли проверять OpenAI Status?
Да. Incident меняет стратегию на ожидание и evidence; зеленый статус возвращает вас к account, headers, Limits и workload shape.
ChatGPT Plus и API quota совпадают?
Нет. Consumer subscription и Platform API billing - разные поверхности.
Что отправить в поддержку?
Timestamp, timezone, request id, endpoint, model, project, organization, безопасное error body, безопасные headers, Limits/Usage, Status, retry count, workload shape и recent changes.
Шаблон локального incident review
Записывайте каждый 429 одинаково: время, timezone, endpoint, model, project, organization, error body, headers, Limits, Usage, Billing, Status, retry count, concurrency, prompt size, queue depth и recent deploy. Такой формат превращает спор "похоже на лимит" в сравнение веток: rate pressure, quota, billing, scope, status или provider route.
На разборе задайте три вопроса. Какая ветка первой дала сильный сигнал? Не изменили ли мы key, model, project и billing до фиксации evidence? Какой production control должен сработать раньше API rejection: central limiter, tenant budget, token estimate, queue, Batch или alert по remaining/reset? Если ответ записан, следующая 429 будет короче и дешевле.
Добавьте к шаблону две строки, которые обычно отсутствуют в спешке. Первая - кто владеет исправлением: application team, billing owner, project admin, platform incident owner или provider support. Вторая - какой сигнал закроет incident: успешный controlled request, восстановление remaining headers, изменение Limits/Billing state, завершение public incident или подтверждение provider route. Без этих строк команда может "починить" retry policy, но оставить billing cap или wrong project нетронутыми.
Для production-сервисов полезно хранить этот пакет рядом с логами, а не в отдельном чате. Тогда следующий дежурный видит не только сообщение RateLimitError, но и точную ветку решения: retryable pressure, quota stop, scope mismatch, status incident или wrapper-owned limit. Это снижает риск, что новая смена снова начнет с key rotation или случайного model switch.
Если incident затронул пользователей, отделите user impact от repair path. В user impact запишите, какие функции отказали, как долго длился отказ и была ли деградация или очередь. В repair path запишите, почему выбран backoff, billing fix, project correction, model change, wait-for-status или provider escalation. Такое разделение помогает сначала защитить пользовательский путь, а уже затем менять capacity, account scope или интеграционный маршрут.
