Разбираемся в лимитах запросов Claude API

Что такое лимит запросов Claude API на самом деле

Лимиты Claude API — это потолки пропускной способности: сколько запросов и сколько токенов ваш аккаунт может пропустить за минуту. Превысите любой из них — и API ответит HTTP 429 вместо завершённой генерации. apiToken.sale не публикует фиксированную таблицу RPM: 429 там сигнализирует о ёмкости шлюза или апстрима, и надёжное решение — дисциплинированные повторы плюс меньшая параллельность, а не бóльшая цифра в конфиге.

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

Читайте также: Лучшие практики Claude API

Как читать ответ 429

Грамотно написанный клиент воспринимает 429 как данные, а не как отказ. В теле ответа — ошибка типа rate_limit_error, а сам ответ обычно несёт заголовок retry-after с числом секунд, которые сервер просит подождать.

curl -i https://router.apitoken.sale/v1/messages \
  -H "x-api-key: sk-pool-•••" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 64,
    "messages": [{"role":"user","content":"hi"}]
  }'

# when throttled:
# HTTP/2 429
# retry-after: 17
# {"type":"error","error":{"type":"rate_limit_error","message":"..."}}

retry-after — это подсказка, а не контракт, и не каждый ответ 429 его несёт. Если заголовка нет, переходите на экспоненциальный backoff с джиттером — и никогда не повторяйте 429 в плотном цикле: это лишь усиливает перегрузку, которая его вызвала.

Политика повторов, которая выживает в продакшене

1. 01Ставьте всплески в очередь, а не выпускайте разом: каждый воркер отправляет по одному запросу за раз.
2. 02Получив 429, прочитайте retry-after и подождите не меньше указанного числа секунд.
3. 03Если заголовка нет, ждите base × 2^attempt плюс случайный джиттер, с потолком около 30 секунд.
4. 04После 4–6 попыток остановитесь и громко завершите задачу с ошибкой вместо бесконечных повторов.
5. 05Логируйте модель, время ожидания и число попыток: при затяжных 429 у вас будет паттерн для поддержки.

const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

async function callClaude(body: unknown): Promise<Response> {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch("https://router.apitoken.sale/v1/messages", {
      method: "POST",
      headers: {
        "x-api-key": process.env.APITOKEN_KEY!,
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
      },
      body: JSON.stringify(body),
    });
    if (res.status !== 429 && res.status < 500) return res;
    const retryAfter = Number(res.headers.get("retry-after"));
    const wait = retryAfter > 0
      ? retryAfter * 1000
      : Math.min(1000 * 2 ** attempt, 30_000) * (0.5 + Math.random() / 2);
    await sleep(wait);
  }
  throw new Error("Claude API still rate-limited after 5 attempts");
}

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

Поскольку счётчики поминутные, реальный рычаг — параллелизм. Пятьдесят параллельных вызовов в начале минуты могут исчерпать бюджет запросов, даже если следующий час вы не отправите ничего. Счётчики токенов усиливают эффект: каждая параллельная длинная генерация продолжает расходовать бюджет выходных токенов, пока идёт, поэтому десять одновременных ответов по 4 000 токенов давят на лимит куда сильнее, чем десять быстрых.

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

Стриминг Claude API: SSE-события и та же тарификация →

Лимиты пропускной способности — не лимиты расходов

Здесь часто путают две системы. Лимит запросов — это регулятор трафика: временный, поминутный, решается ожиданием. Ограничение расходов — тормоз бюджета: оно определяет, сколько ключ вообще может потратить. В панели apiToken.sale пропускная способность запросов вообще не настраивается: доступные ограничения ключа — необязательный общий лимит расходов за всё время и дата истечения. Ошибка 429 говорит «притормозите» и ничего не сообщает о вашем балансе; пополнение её не снимет.

Как задать общий лимит расходов и дату истечения ключа →

Как снизить давление 429, не повышая лимит

• Разносите cron- и пакетные задачи случайными сдвигами, чтобы они не налетали на одну минуту.
• Ограничьте параллелизм воркеров и дайте очереди поглощать всплески.
• Сокращайте контекст, чтобы каждый запрос нёс меньше входных токенов.
• Ограничивайте max_tokens реально нужным объёмом ответа.
• Кешируйте большой стабильный контекст промпт-кешированием — это снижает тарифицируемую стоимость входа при повторах.

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

Когда 429 становится разговором о мощностях

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

Частые вопросы

Похожие гайды