Claude Code падает с ошибкой rate limit: как чинить в репе
Почему Claude Code падает с ошибкой rate limit в терминале
У меня вчера на середине рефакторинга отвалилась утилита. Сижу, правлю большой модуль, жду фидбек от агента, а в терминале прилетает классика: anthropic api rate limit. Процесс обрывается, контекст теряется, настроение так себе.
Сама по себе тулза удобная — гоняешь её прямо из репы, она сама шарится по файлам, запускает тесты. Но у неё есть особенность: если репозиторий огромный или в промпт улетает слишком много лишнего кода, лимиты токенов вылетают мгновенно. Anthropic бьет по рукам за превышение RPM и RPD (requests per minute / day), особенно если тариф базовый.
Command line error log on dark screen
Как понять, что это именно claude code rate limit error
Ошибки бывают разные. Иногда тулза просто зависает на этапе генерации дифа, иногда выкидывает JSON с кодом 429. Если вы видите в логах упоминание «Too Many Requests» или «Rate limit exceeded», то гадать нечего — это оно.
У меня в репе обычно падает в двух случаях: либо я закинул в контекст огромный лог сборки, либо агент решил прочитать всю ноду из node_modules, чего делать категорически нельзя. Утилита пытается запихнуть весь этот мусор в один запрос, API говорит «стоп», и терминал захлёбывается ошибкой.
Первый способ фикса: чистим контекст и правим ignore-файлы
Самое банальное, с чего стоит начать — запретить агенту совать нос туда, куда не просят. Если Claude Code начинает сканировать сгенерированные файлы или папки сборки, лимиты закончатся через пять минут.
Я завёл привычку проверять, видит ли утилита лишние директории. Пропишите всё ненужное в `.claudeignore` так же, как делаете это для гита. Меньше мусора в контексте — меньше шансов словить лимит.
Второй способ: переключение модели и работа с флагами
Если проект требует тяжелых запросов, а лимиты на текущей модели душат, имеет смысл попробовать переключить модель через конфигурационные файлы или ключи запуска. Иногда тулза по умолчанию стучится в самую тяжёлую версию, хотя для рутинных задач хватает варианта поскромнее.
Посмотрите конфиги в домашней директории или в корне проекта. Изменение параметров запроса помогает сбить частоту ошибок, хотя полностью проблему не решает, если вы продолжаете бомбардировать API короткими запросами каждую секунду.
Третий способ: проксирование и локальный кеш запросов
Когда работаешь в команде и у всех один корпоративный ключ, rate limit упирается в общий потолок организации. Тут уже простыми ignore-файлами не обойдешься, приходится думать про разделение доступов или прокси.
Некоторые разработчики поднимают локальные прокси-серверы с троттлинг-очередями, чтобы запросы от агента уходили не пачкой, а с небольшой задержкой. Это сглаживает пики нагрузки и спасает от внезапных падений в разгар рабочего дня.
Как жить дальше и не терять прогресс при сбоях
Главный вывод, который я для себя сделал: нельзя полагаться на то, что агент будет работать вечно без пауз. Если утилита упала по лимитам, она редко умеет красиво откатывать незакоммиченные изменения обратно в исходное состояние.
Поэтому правило простое — делаем `git commit` как можно чаще, держим бэкапы локально и не даем агентам сканировать лишний хлам. И да, я не врач и не техподдержка Anthropic, так что если их облако лежит целиком — тут поможет только перекур и чашка кофе.
Гайдчеловек
Показать полностью
