Лимиты и rate limits

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

Rate limit — ограничение на число запросов и токенов за период. При превышении API возвращает ошибку 429 Too Many Requests.

В каких единицах меряют лимиты

Лимит	Что ограничивает
RPM	запросов в минуту (requests per minute)
TPM	токенов в минуту (tokens per minute)
TPD	токенов в сутки (tokens per day)

Лимиты зависят от вашего тарифа/уровня (tier) у провайдера и обычно растут по мере использования и оплаты. Можно упереться в любой из них: например, не превысить число запросов, но выйти за лимит токенов из-за длинных промптов.

Ошибка 429 — это штатная ситуация

429 не означает поломку. Это сигнал «притормози». Правильная реакция — подождать и повторить запрос, а не падать. В ответе обычно есть заголовок retry-after (сколько секунд ждать) и заголовки с остатком квоты.

# Заголовки ответа (примеры имён)
retry-after: 30
anthropic-ratelimit-requests-remaining: 0
anthropic-ratelimit-tokens-remaining: 12000

Что с этим делать в коде

Официальные SDK сами повторяют запрос при 429 с экспоненциальной задержкой (по умолчанию пара попыток). Этого часто достаточно. Если строите высоконагруженный конвейер — добавляют очередь запросов, ограничение параллелизма и собственный backoff (см. урок про повторы и backoff).

import anthropic

# Настраиваем число повторов на клиенте
client = anthropic.Anthropic(max_retries=5)

# Для конкретного запроса можно переопределить
client.with_options(max_retries=8).messages.create(
    model="claude-opus-4-8",
    max_tokens=512,
    messages=[{"role": "user", "content": "..."}],
)

Почему лимиты вообще есть

Лимиты защищают инфраструктуру провайдера от перегрузки и распределяют мощности между клиентами честно. Для вас это значит: пропускную способность нельзя считать бесконечной, её надо планировать. Прикиньте заранее, сколько запросов и токенов в минуту даст ваша нагрузка в пике, и сверьте с лимитами своего тарифа. Если не хватает — повышают tier (обычно лимиты растут с объёмом оплаты) или сглаживают пики очередью.

Как не упираться в лимиты зря

Не шлите тысячи параллельных запросов разом — ограничивайте параллелизм.
Для массовой нелатентной обработки используйте batch-режим (см. раздел 5) — у него отдельные, более щедрые условия.
Сокращайте лишний контекст в промптах — это экономит TPM.
Кэшируйте повторяющийся контекст (раздел 5).

Итог

Лимиты считаются в запросах (RPM) и токенах (TPM/TPD) за период.
429 — это «подожди и повтори», а не фатальная ошибка.
SDK повторяют запросы сами; для нагрузки добавляйте очередь и контроль параллелизма.