429 Too Many Requests: что значит и когда повторять (2026)

Коротко

Status code:       HTTP 429 (Too Many Requests)
Anthropic:         error.type = rate_limit_error, plus a retry-after header
OpenAI:            rate-limit 429 and spend/credit 429 share the code; read error.code
Google Gemini:     429 RESOURCE_EXHAUSTED, no retry hint documented
OpenRouter:        429 raised by OpenRouter, or relayed from the upstream provider
First thing to do: read retry-after, wait that long, retry once
No header:         back off 1s, 2s, 4s with jitter, cap at 5 attempts
Never retry:       credit/spend-cap 429s, they do not clear on their own

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

Что означает “429 Too Many Requests”?

Это значит, что ваши учётные данные приняты, но запрос всё равно отклонён, потому что аккаунт запросил больше объёма, чем ему сейчас разрешено. Формулировки у разных поставщиков различаются (“Rate limit reached for requests”, “rate limit exceeded”, RESOURCE_EXHAUSTED), а код состояния нет.

Три вещи, которыми 429 не является:

• Не ошибка аутентификации. Плохой или отозванный ключ, это 401, а ключ без доступа к ресурсу, это 403.
• Не сбой в работе. Anthropic использует 529 overloaded_error для случая “the API is temporarily overloaded” (API временно перегружен) для всех пользователей, отдельно от ваших собственных лимитов.
• Не обязательно про ваш трафик. На роутере 429 может быть ответом вышестоящего провайдера, переданным вам.

Окно обычно составляет минуту, но это не минута по часам. Anthropic описывает свой ограничитель как token bucket: “your capacity is continuously replenished up to your maximum limit, rather than being reset at fixed intervals” (ваша ёмкость непрерывно пополняется до максимального лимита, а не сбрасывается через фиксированные интервалы).

Ошибка превышения лимита, это моя вина или провайдера?

Чаще всего ни то, ни другое. Это политика в отношении вашего аккаунта, и есть пять разных политик, которые дают один и тот же код состояния.

OpenAI формулирует это разделение прямо: Retry-After “does not mean that quota, billing, or other errors that require user action can be resolved by retrying” (не означает, что квоту, биллинг и прочие ошибки, требующие действий пользователя, можно решить повтором). Цикл повторов, который обрабатывает каждый 429 одинаково, будет сидеть и долбить исчерпанный баланс кредитов, пока не сработают алерты.

Последнюю строку чаще всего ставят неверный диагноз. Когда ограниченная запуском модель возвращает 429 независимо от вашего тарифа, никакой откат на этом маршруте не поможет, а это в точности форма проблемы OpenRouter Kimi K3 429.

Какой заголовок говорит, когда повторять?

Читайте retry-after. Это единственное значение, которое сервер сообщает вам напрямую, а все остальные заголовки, это контекст. Остальной набор заголовков различается по поставщикам, включая формат значения сброса.

Две ловушки в этой таблице:

• Значение сброса имеет разный тип у разных поставщиков. Anthropic возвращает временную метку, которую вы сравниваете с часами. OpenAI возвращает длительность в стиле Go, которую вы разбираете как интервал. Код, предполагающий одну форму, тихо выдаёт мусор на другой.
• Anthropic округляет остаточные значения токенов до ближайшей тысячи, так что если считать anthropic-ratelimit-input-tokens-remaining точным, на малых запросах будет перелёт.

Наличие заголовков тоже не гарантировано, и это особенно важно на шлюзе. При тестировании четырёх моделей через один OpenAI-совместимый эндпоинт 2026-08-10 два маршрута вернули полный набор x-ratelimit-limit-requests / -limit-tokens / -remaining-* / -reset-* (плюс нестандартный x-ratelimit-renewalperiod-requests: 60), а два не вернули заголовков лимитов вовсе. Набор заголовков принадлежит тому, кто обслуживает модель, а не эндпоинту, который вы вызвали. Пишите парсер так, чтобы отсутствующий заголовок деградировал до отката, а не бросал исключение.

Сколько ждать после 429?

Столько, сколько говорит retry-after, а если заголовка нет, то 1s, 2s, 4s с джиттером, не более пяти попыток. Фиксированные паузы, это неверный ответ, потому что все параллельные воркеры просыпаются в один и тот же момент и заново упираются в тот же лимит.

Джиттер, это та часть, которую пропускают, и именно она имеет значение, когда 20 воркеров упираются в стену одновременно.

import random, time
from openai import OpenAI, RateLimitError

client = OpenAI(base_url="https://api.ofox.ai/v1")

def call_with_backoff(**kwargs):
    for attempt in range(5):
        try:
            return client.chat.completions.create(**kwargs)
        except RateLimitError as e:
            # the SDK unwraps the envelope, so e.body is the inner "error" object
            code = e.body.get("code") if isinstance(e.body, dict) else None
            if code in {"credit_balance_exhausted", "organization_spend_limit_exceeded"}:
                raise  # a spend cap does not clear by waiting
            retry_after = e.response.headers.get("retry-after")
            delay = float(retry_after) if retry_after else random.uniform(0, 2 ** attempt)
            time.sleep(delay)
    raise RuntimeError("still rate limited after 5 attempts")

Прежде чем писать этот цикл, проверьте, не сделал ли уже это ваш SDK. Читаем установленный клиент openai 2.53.0: DEFAULT_MAX_RETRIES is 2, путь повтора сначала разбирает retry-after-ms, затем retry-after (в секундах или как HTTP-дата), учитывает заданную сервером задержку до 120 seconds и вовсе отказывается повторять, если сервер просит дольше. При отсутствии заголовка он откатывается на 0.5 * 2^n с ограничением в 8 seconds, умноженным на джиттер-фактор между 0.75 и 1.0. SDK от Anthropic тоже по умолчанию повторяют временные сбои дважды и учитывают retry-after. Так что на настройках по умолчанию 429, всплывающий в вашем коде, уже провалился three times, с промежутками всего около half a second, а затем one second, что и близко не окно длиной в минуту. Поднимайте max_tokens, извините, max_retries, или владейте циклом сами; не накладывайте второй слой повторов поверх первого.

Что на самом деле считают RPM, TPM, ITPM и OTPM?

Разные поставщики измеряют разные вещи, и от единицы измерения зависит, какая ручка поможет.

• RPM считает вызовы, а не размер. Если вы постоянно упираетесь в него, кладите больше работы в каждый вызов.
• TPM, это один общий бюджет на вход и выход. Для некоторых моделей OpenAI добавляет сверху RPD, TPD и IPM (изображений в минуту).
• ITPM и OTPM, это разделение этого бюджета у Anthropic, применяемое для класса модели, так что нагрузка с длинным контекстом и нагрузка с длинным выходом упираются в разные стены.
• Кешированные чтения, это интересное исключение. На большинстве моделей Claude cache_read_input_tokens не засчитываются в ITPM, тогда как cache_creation_input_tokens засчитываются. Собственный пример Anthropic: лимит 2,000,000 ITPM при 80% попаданий в кеш обрабатывает около 10,000,000 всего входных токенов в минуту.
• max_tokens не входит в OTPM, который оценивается по фактически произведённым токенам. Щедрый потолок ничего вам не стоит в терминах лимитов.
• Лимиты конкурентности, это отдельная история. Некоторые провайдеры ограничивают число запросов в полёте, а не поминутную частоту, и в сравнении лимитов пяти поставщиков есть цифры по тарифам.

Почему я получаю 429, хотя почти не шлю трафик?

Потому что поминутные лимиты редко применяются именно поминутно, и ведро редко бывает только вашим. Обычные подозреваемые:

• Применение внутри минуты. Документация Anthropic прямо говорит: “a rate of 60 requests per minute (RPM) might be enforced as 1 request per second. Short bursts of requests can exceed the limit and trigger rate limit errors” (частота 60 запросов в минуту может применяться как 1 запрос в секунду; короткие всплески могут превысить лимит и вызвать ошибки).
• Одно ведро на всю организацию. Лимиты стоят на уровне организации, а не ключа, так что каждый сервис, ноутбук и CI-задача черпают из общего пула, если вы не задали лимиты по рабочим пространствам.
• Веерное распространение. Параллельные агенты умножают число одновременных запросов и несут полный контекст в каждом, так что первым уходит ITPM.
• Лимиты разгона. Резкий рост использования может вызвать 429, пока вы ещё под заявленным лимитом.
• Дневные лимиты бесплатного тарифа. Дневная норма в 50 запросов уходит после одного вечера отладки.
• Биллинговый 429 под маскировкой. Нулевой трафик плюс 429 обычно означает лимит расходов или исчерпанный баланс, а не пропускную способность.

Если вы видите это внутри кодового агента, а не в собственном коде, механика та же, но ручки другие, и разбор лимитов Claude Code охватывает настройки конкурентности.

429, это то же самое, что 529 или RESOURCE_EXHAUSTED?

Нет. 429 про ваш аккаунт, 529 и 503 про провайдера, а RESOURCE_EXHAUSTED, это название 429 у Google.

Это различие стоит завести в логах. Дашборд, который считает “429 + 529” одним числом, не подскажет, покупать ли более высокий тариф или добавить запасной маршрут. Если хотите более глубокую версию случая с ёмкостью, смотрите руководство по перегрузке Claude API 529.

Как перестать получать 429?

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

• Учитывайте retry-after и добавляйте джиттер, когда его нет. Бесплатно, и это чинит ту часть, что вы создаёте себе сами.
• Ограничивайте конкурентность на клиенте. Семафор вокруг пула воркеров, это более надёжный ограничитель, чем любая политика повторов, потому что он предотвращает всплеск, а не реагирует на него.
• Кешируйте префиксы. На моделях Claude это даёт реальный запас по ITPM, а не только более дешёвый счёт, и расчёт стоимости кеширования промптов показывает, где точка окупаемости.
• Переносите несрочную работу на batch-эндпоинт. У Batch API отдельные лимиты, и они обычно вдвое дешевле.
• Переключайтесь, а не повторяйте настойчивее. Когда 429, это ёмкость вышестоящего провайдера, вторая модель на той же форме запроса восстанавливает вызов за один переход. Это практический аргумент за один эндпоинт с несколькими моделями за ним: ofox OpenAI-совместим, так что запасной вариант, это смена строки модели, а не вторая интеграция.
• Просите повышение. У Anthropic есть процесс “Request rate limit increase” в консоли, а OpenAI поднимает аккаунты по тарифам по совокупным расходам. Ни то, ни другое не мгновенно, так что это план на следующий месяц, а не на сегодняшний вечер.

Две вещи, которых делать не надо: не размазывайте одну нагрузку по нескольким API-ключам одной организации (лимит на уровне организации, так что ничего не изменится), и не понижайте max_tokens в надежде облегчить лимит вывода, если только вы действительно не генерируете столько токенов.

Источники, проверенные для этого обновления

• https://platform.claude.com/docs/en/api/rate-limits
• https://platform.claude.com/docs/en/api/errors
• https://developers.openai.com/api/docs/guides/rate-limits
• https://developers.openai.com/api/docs/guides/error-codes
• https://ai.google.dev/gemini-api/docs/rate-limits
• https://ai.google.dev/gemini-api/docs/troubleshooting
• https://openrouter.ai/docs/api-reference/limits