429 rate_limit_error в Claude Fable 5

Какой лимит вы действительно превысили

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

• Лимиты ускорения из-за всплеска трафика

  Резкий рост использования в вашей организации может возвращать 429 из-за лимитов ускорения, даже если вы не превышаете опубликованные показатели тарифа. Наращивайте трафик постепенно и поддерживайте стабильный профиль использования вместо запуска новой нагрузки сразу на полной мощности.

• Входные токены в минуту

  Этот лимит пользователи Fable 5 превышают чаще всего: на Start доступно 500,000 ITPM против 2,000,000 у Opus 5, а контекстное окно Fable 5 на 1M токенов располагает к очень большим промптам. Учитывается только некешированный ввод: input_tokens плюс cache_creation_input_tokens. Чтения из кеша не учитываются.

• Выходные токены в минуту

  Fable 5 допускает 100,000 OTPM на Start, 300,000 на Build и 800,000 на Scale. OTPM оценивается в реальном времени по фактически сгенерированным токенам, поэтому max_tokens не влияет на расчёт. Долгие автономные запуски Fable 5 с высоким effort исчерпывают этот лимит быстрее, чем более короткие обращения к другим моделям.

• Запросы в минуту

  Fable 5 допускает 1,000 RPM на тарифе Start, 2,000 на Build и 4,000 на Scale. Ограничитель использует token bucket с непрерывным пополнением, а не сбрасывается по фиксированному времени: всплеск может исчерпать минутный запас за секунду и вызвать 429, даже если средняя скорость намного ниже лимита.

• Запрос отправлен с неверными учётными данными

  Лимиты применяются на уровне организации, при этом для рабочего пространства могут быть заданы более низкие ограничения. Случайный ANTHROPIC_API_KEY в окружении может направить трафик через ключ низкого тарифа вместо ожидаемого аккаунта, и тогда вы упрётесь в лимит этого ключа, а не своего аккаунта.

Исправляйте в таком порядке

Сначала изучите ответ, затем снизьте нагрузку и только потом просите больше мощности. Запрос на повышение лимита до настройки кеширования обычно даёт меньший эффект, чем само кеширование.

1. 1

   3. Кешируйте повторяющуюся часть промпта

   Для большинства моделей cache_read_input_tokens не учитываются в ITPM. При лимите 2,000,000 ITPM и доле попаданий в кеш 80 процентов вы можете обрабатывать 10,000,000 входных токенов в минуту. Кешируйте системные инструкции, определения инструментов, большие документы и историю диалога.

2. 2

   4. Снизьте параллелизм у источника

   В своём клиенте ограничьте число запросов в обработке и ставьте остальные в очередь вместо веерной отправки. В Claude Code уменьшите CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY, который по умолчанию равен 10, не запускайте много параллельных субагентов и для высоконагруженных скриптовых запусков переключитесь на меньшую модель через /model.

3. 3

   2. Определите ограничивающий параметр по заголовкам ответа

   Проверьте anthropic-ratelimit-requests-remaining, anthropic-ratelimit-input-tokens-remaining и anthropic-ratelimit-output-tokens-remaining, а также соответствующие им заголовки limit и reset. Оптимизация не того параметра — самая частая напрасная трата усилий в этой ситуации.

4. 4

   1. Ждите ровно столько, сколько указано в retry-after

   Заголовок retry-after содержит число секунд до следующей попытки. Повторные запросы раньше этого срока по определению завершатся неудачей, поэтому считайте это значение нижней границей, а для парка воркеров добавляйте к нему случайную задержку.

5. 5

   5. Запросите более высокий лимит с реальными цифрами

   На странице Limits в Claude Console используйте Request rate limit increase. Укажите пиковое число входных и выходных токенов в минуту для каждой модели и примерную долю закешированного или повторяющегося контекста: именно по этим данным оценивается форма запроса.

Связанные материалы