Плагин cc-limit-pacer тормозит Claude Code перед лимитом

В README плагина cc-limit-pacer на GitHub есть показательная строчка: в примерном разборе за 32 дня из 2410 сессий только 41 перешагнула 500k токенов, поэтому раннее сжатие контекста почти не спасает от блокировок. Блокировки, пишет автор, приходят от объёма работы, и плагин бьёт именно по нему: понижает модель и придерживает фоновые прогоны, когда лимит Claude Code подходит к концу.

Коротко

• cc-limit-pacer ставится как плагин Claude Code, следит за пятичасовым и недельным окнами и при угрозе исчерпания запускает новые сессии ступенью ниже: Fable → Opus, Opus → Sonnet, с выключенным advisor.
• В примерном прогоне за месяц связка из сжатия на 830k токенов и пейсера дала на 28% меньше сжатий и около половины прежних часов блокировки: 38 вместо 74.
• Фоновая работа на 62 доллара в том же прогоне ждала сброса окна, а в README признают, что повтор не учитывает потерю качества от сжатий и более дешёвых моделей.

Раньше проект назывался autocompact-gate, и название подсказывает, с чего всё начиналось: с управления моментом автосжатия контекста. При первом запуске состояние из ~/.claude/state/autocompact-gate переезжает в ~/.claude/state/cc-limit-pacer. Сжатие осталось одним из рычагов, но главными стали два других, и бэктест в README объясняет почему.

Окно становится «горячим», когда израсходовано на 50% и идёт к потолку

Хук плагина следит за пятичасовым и недельным окнами. Окно считается «горячим», если оно израсходовано хотя бы на 50% и при нынешнем темпе упрётся в лимит. В этом состоянии cc-limit-pacer прописывает в настройки модель ступенью ниже (Fable → Opus, Opus → Sonnet) и advisorModel: "off", а новые сессии это подхватывают.

Второй рычаг касается автоматики. Прогоны через SDK и claude -p, а также сессии во временной директории плагин придерживает до сброса окна с сообщением вида holding automated run … retry after Mon 04:40. Интерактивные сессии он не держит никогда. Если срочной задаче нужно пройти сразу, ставится переменная LIMIT_PACER_ALLOW=1.

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

Из 2410 сессий в примере только 41 перешагнула 500k токенов

Третий рычаг работает в обратную сторону: на моделях с окном 1M сессии сжимаются около 830k токенов вместо примерно 570k. Контекста остаётся больше, сжатий меньше. Плагины сами менять autoCompactWindow не могут, поэтому команда setup прописывает autoCompactWindow=862000, предварительно сделав копию settings.json. Claude Code сжимает примерно на 32k ниже этого значения.

Почему бы тогда не сжимать раньше, экономя лимит? Ответ в примере бэктеста за 32 дня: 2410 сессий, 6 блокировок, 71 час простоя. Если бы каждая сессия сжималась на 500k, расход за эти 32 дня упал бы лишь на 3%, а раннее сжатие в горячие периоды вернуло бы около 0,5 часа. Отсюда вывод автора: блокировки дают объёмы, а не длинные контексты.

В примерном прогоне часы блокировки упали с 74 до 38

Команда simulate прогоняет последний месяц вашей истории через каждую политику. В образце из README это 41 210 событий за 4,3 недели. Строка today повторяет реальность: 18 сжатий в неделю, 4 пятичасовые и 1 недельная блокировка, 74 часа простоя. Её сверяют с настоящими блокировками из транскриптов, там 5 пятичасовых и 1 недельная.

Одно позднее сжатие на 830k даёт 11,5 сжатия в неделю, но лишний расход приближает блокировки, и простой растёт до 81 часа. Связка из 830k и пейсера даёт 13 сжатий в неделю, 2 пятичасовые блокировки, 1 недельную и 38 часов простоя. Цена: фоновая работа на 62 доллара ждала, пока окно остынет.

Команда audit считает и потери. В образце 70 автосжатий обошлись примерно в 58 долларов в API-эквиваленте (1,3% расхода), консультации advisor в 170 долларов (4%), а недельная квота Fable не использована вовсе. Эту квоту видно только в /usage, поэтому её процент передают флагом --fable-pct.

Два хука по 0,2 секунды и оценка по локальным транскриптам

Хуки SessionStart и UserPromptSubmit срабатывают при старте сессии и перед каждым запросом, каждый примерно за 0,2 секунды, и добавляют к каждой сессии около 233 токенов. Бюджет плагин узнаёт из одного показания /usage: вы вводите процент пятичасового окна, недельного и время недельного сброса, а calibrate переводит это в долларовый эквивалент API.

Представьте навигатор, который знает объём бака и считает расход по пройденному пути, но стрелку топлива сам не видит. Оценка опирается только на транскрипты этой машины: расход в claude.ai и на других компьютерах ей невиден, поэтому при расхождении с /usage калибровку повторяют. Команда report поднимает тревогу, если калибровке больше 3 дней.

Ошибка в самом плагине сессию не блокирует: исключение пишется в errors.jsonl с полным трейсбеком, а запрос уходит дальше. Смена модели в настройках действует только на новые сессии, уже идущий прогон её не замечает. Для работы нужен Python 3.9+ и только стандартная библиотека.

Главное ограничение автор называет сам: повтор не учитывает потерю качества от сжатий и более дешёвых моделей, а придержанная работа всё равно выполнится позже, так что выигрыш по блокировкам оптимистичен. Странно, на наш взгляд, что придержанный прогон claude -p возвращает сообщение об ожидании как результат и завершается с кодом 0: скрипт, который смотрит только на код выхода, примет паузу за успех. README прямо советует батч-скриптам проверять текст ответа.

Счётчик блокировок в неделю

Доказательство пользы автор предлагает копить самим: команда status показывает число блокировок в неделю за 30 дней до установки и после неё. Пока проверить это смогут немногие. Репозиторий приватный, и плагин встанет, только если git clone с вашими учётными данными GitHub проходит. Откроют ли репозиторий для всех и когда, в README не говорится.