Лимиты Claude Code: что сжигает окно и неделю — мои замеры за два месяца
TL;DR Со 2 октября по 10 ноября я записывал показания панели /usage в Claude Code: 90 записей, из них 76 скрипт снял сам, примерно каждые три часа. По журналу одно полностью выжженное пятичасовое окно стоит около 15% недельного лимита: неделя — это шесть-семь полных окон. Шесть коротких всплесков дали 46 пунктов недели из 99. Четырнадцать параллельных агентов на старшей модели исчерпали окно за два с половиной часа. Сессия, которую скрипт будил по таймеру, тратила 5–8 пунктов недели в сутки без моего участия. Чисел «45, 225 и 900 сообщений» из таблиц в интернете на страницах Anthropic нет. Ниже — журнал, расчёты, пять привычек, после которых я перестал упираться в лимит, и где мои замеры врут. Чтение — около восьми минут.
9 октября в 03:25 недельный лимит показал 100%. До сброса оставалось десять с половиной часов. Я Егор, десять лет в перформанс-маркетинге, кода не пишу. В Claude Code у меня идут аналитика, тексты и мелкие сервисы, часто пачками агентов. Тариф — Max с пятикратным лимитом, докупка сверх лимита выключена. К той ночи я шесть суток записывал расход примерно каждые три часа, поэтому могу показать, как сгорела неделя.
Как устроены лимиты Claude Code: окно и неделя
Простыми словами Счётчиков два. Пятичасовое окно начинается с вашего первого сообщения и обнуляется через пять часов. Недельный лимит сбрасывается в фиксированное время, назначенное аккаунту: у меня это пятница, 14:00 по Москве. Claude Code, приложение и сайт расходуют один общий лимит.
Сколько сообщений или токенов входит в окно, Anthropic не пишет. На странице тарифов есть только множители: Max даёт пять объёмов Pro за окно и за неделю. Числа «около 45 сообщений на Pro, 225 и 900 на старших тарифах» кочуют по статьям из поисковой выдачи без методики. Часть авторов сама оговаривает, что вывела их из соотношения тарифов.
Остаток видно в панели /usage: там полосы окна и недели и разбивка расхода по навыкам, помощникам и подключённым сервисам. Разбивку панель считает по истории сессий на этом компьютере, цифры в ней приблизительные.
Журнал: 90 записей и одна неделя, сгоревшая за шесть суток
Показания снимал скрипт. Он открывает панель /usage в простаивающей сессии и записывает проценты. Модель при этом не вызывается, так что сам замер лимит не тратит. С 3 по 12 октября скрипт работал примерно каждые три часа и сделал 76 записей. Остальные 14 я снял до 10 ноября вручную и вторым скриптом.
Неделя выросла с 12% вечером 2 октября до 100% в ночь на 9 октября: шесть суток с небольшим, в среднем 14 пунктов в сутки. Окно между всплесками стояло почти пустым. За эту неделю скрипт снял его 53 раза: медиана — 5%, десять раз на нуле, выше 50% — четыре раза. Максимум — 88% вечером 7 октября.
Замечание В эти дни у меня круглосуточно шла очередь больших задач, для обычной работы такая неделя нетипична. Мои проценты на свой день переносить не стоит, соотношения из следующих разделов — можно.
Одно полное окно — около 15% недели
Один пункт окна стоит 0,15 пункта недели. Чтобы это посчитать, я взял 37 интервалов, в которых окно росло, и сложил приросты: окно выросло на 444 пункта, неделя — на 68.
Значит, полностью выжженное окно — около 15% недели, а недельный лимит равен шести-семи полным окнам. Пример из журнала: 7 октября окно за шесть часов поднялось с 7% до 88%, неделя — с 64% до 76%.
| Полных окон в день | На сколько хватит недели |
|---|---|
| Половина | На все семь дней, с запасом |
| Одно | На шесть с половиной суток |
| Два | На три с небольшим дня |
| Три | На два дня |
Соотношение гуляет: на отдельных интервалах выходило от 0,10 до 0,26, то есть от десяти до четырёх окон на неделю. Снимки шли раз в три часа, проценты в панели целые, а если окно сбрасывалось внутри интервала, его прирост выходил заниженным. Поэтому «шесть-семь окон» — среднее по журналу и порядок величины для моего тарифа осенью 2026 года.
Почти половину недели съели шесть всплесков
Неделя тратится рывками. Я взял все шаги между соседними снимками не длиннее трёх часов: за весь журнал их 83, в сумме они дали 99 пунктов недели. Из них 46 пунктов пришлись на шесть шагов по шесть пунктов и больше. Ещё 26 дали десять шагов по два-пять пунктов. Оставшиеся 27 набежали мелочью: 67 шагов, в каждом пункт или ноль.
Один из тяжёлых отрезков я не могу объяснить до сих пор. В ночь на 8 октября окно сбросилось с 23% до нуля, а неделя за те же три часа выросла с 80% до 86%.
Параллельные агенты: четырнадцать штук сжигают окно за два с половиной часа
22 октября, по моим записям, 14 агентов на старшей модели Opus выжгли окно за два с половиной часа. Одновременно работали до 13. Каждый потратил 250–440 тысяч токенов и сделал 100–180 вызовов. Когда окно закончилось, семь агентов встали посреди работы.
Работа не пропала: после сброса окна я вручную продолжил прерванных агентов, и они пошли с того места, где остановились.
На следующий день пачка агентов шла уже с правилом: остановиться на 90% окна. Журнал за 23 октября показывает 68%, 83% и 87%. До упора не дошло.
Обратный пример — 10 ноября. Три агента на младшей модели Sonnet потратили на троих около 590 тысяч токенов. С моей приёмкой и скриптами это стоило около 6% окна и 1% недели. До запуска я оценивал расход в 18–20% окна и ошибся втрое.
В документации Claude Code сказано, что команды агентов тратят примерно в семь раз больше токенов, чем обычная сессия, когда участники работают в режиме планирования. Агенты-помощники расходуют тот же лимит, что и вы.
Младшая модель для помощников: их доля в расходе упала с 51% до 30%
3 ноября разбивка в /usage показала, что 51% расхода дают помощники общего назначения. Они наследовали старшую модель основной сессии. Я поставил помощникам по умолчанию Sonnet через переменную окружения CLAUDE_CODE_SUBAGENT_MODEL в настройках. Теперь старшую модель помощник получает, только если я прошу об этом явно.
Через неделю доля помощников общего назначения упала до 30% за семь дней и до 12% за последние сутки. По журналам сессий около 92% выходных токенов помощников пришлось на Sonnet, около 7% — на Haiku.
Замечание Нагрузка в эти две недели была разной, поэтому разницу между 51% и 30% нельзя целиком приписать настройке.
Фоновая утечка: лимит тратится, пока вы не работаете
9 октября я нашёл утечку: недельный лимит рос примерно на пункт за три часа, даже когда я не работал. В сутки набегало 5–8 пунктов недели.
Я посчитал по журналам сессий ответы модели в трёхчасовых отрезках за ночь и посмотрел, какая сессия отвечала, пока я спал. Виновата оказалась долгоживущая сессия: скрипт-наблюдатель будил её каждые 115 минут. Документация объясняет, почему это дорого: каждый запрос отправляет модели весь контекст сессии, а после паузы дольше срока жизни кэша этот контекст читается заново.
Для сравнения: с 10 по 12 октября я в Claude Code почти не работал. Окно не поднималось выше 3%, неделя 57 часов стояла на 4%.
Оценка по токенам завысила расход в 1,6–1,8 раза
8 октября я прикинул расход окна по выходным токенам из журналов сессий и получил 30–35%. Панель показала 19%.
Месяцем раньше я пробовал подобрать формулу расхода. На двух замерах «до и после» прирост окна сошёлся с двумя прикидками: около трёх пунктов окна на доллар стоимости по тарифу API без учёта чтения кэша и около 0,18 пункта на тысячу выходных токенов. Отсюда гипотеза: лимит тратят выход модели и запись кэша, а чтение кэша почти ничего не стоит. Это две точки на двух моделях, и октябрьская проверка формулу не подтвердила. Гипотезой она и осталась.
Как не упираться в лимиты: пять привычек
- Сверяться с панелью. Прикидка по токенам завысила расход окна в 1,6–1,8 раза, прикидка для трёх агентов — втрое.
- Тяжёлых агентов запускать очередью. Сначала то, что нужно раньше. После того срыва я держу одновременно не больше шести-семи тяжёлых агентов и задаю пачке порог остановки — 90% окна.
- Помощникам — младшую модель по умолчанию. Старшую давать явным указанием, когда задача того стоит.
- Долгие сессии будить по событию, а не по таймеру. Каждое пробуждение — запрос со всем контекстом.
- Не бояться упора. Прерванного агента можно продолжить после сброса. В интерактивной сессии Claude Code умеет и сам дождаться сброса и продолжить задачу.
Где мои замеры врут
- Один тариф и один человек. На Pro или на тарифе старше соотношение окна и недели может быть другим.
- Нетипичная нагрузка. Очередь больших задач круглые сутки и пачки агентов. Обычных рабочих дней в журнале почти нет.
- Грубая сетка. Снимки раз в три часа, проценты целые, автоматический ряд — десять дней.
- Срок годности. Замеры сделаны в сентябре — ноябре 2026 года. Anthropic меняет лимиты и оставляет за собой это право.
- Формула расхода не найдена. Сентябрьская подгонка держится на двух точках.
Откуда числа
Проценты окна и недели — из моего журнала панели /usage: 90 записей со 2 октября по 10 ноября 2026 года. Токены и число вызовов агентов — из журналов сессий Claude Code. Соотношение 0,15 и таблицу «окон в день» я посчитал по журналу сам. Правила окна и недели — со страницы поддержки Anthropic «How do usage and length limits work», множители тарифов — со страницы цен, устройство панели и расход долгих сессий — из документации Claude Code, разделы Costs и Errors. Все страницы открыты 10 ноября 2026 года.
Краткие выводы
- Одно полное пятичасовое окно — около 15% недели; неделя равна шести-семи полным окнам. Это мой тариф и моя осень, у вас цифра может быть другой.
- Почти половину недели съедают редкие тяжёлые отрезки: шесть шагов из 83 дали 46 пунктов из 99.
- Четырнадцать агентов на старшей модели сожгли окно за два с половиной часа. Три агента на младшей стоили около 6% окна.
- Лимит может уходить без вас: сессия с таймером тратила 5–8 пунктов недели в сутки.
- Расход надо сверять с панелью: мои прикидки завышали его в 1,6–1,8 раза и втрое.
Сколько пунктов недели у вас уходит на работу, которую вы не запускали?