Claude Code limits — это ограничения на объём использования, которые зависят от вашего плана или от способа оплаты, и самый надёжный способ жить с ними состоит в планировании задач под размер окна, вместо попыток обойти его. На подписке ограничение действует как окно использования с периодическим сбросом, при оплате по токенам роль лимита играет бюджет. Конкретные цифры меняются, поэтому здесь они опущены: их смотрят в личном кабинете и документации, а команде достаточно правил, которые работают при любых значениях.
Что считается
Лимит расходуется контекстом, количество вопросов вторично: каждый запрос несёт всю историю разговора, поэтому длинные сессии, лишние инструменты и тяжёлые задачи съедают окно быстрее коротких.
По документации Claude Code, на подписке использование делится на окна со сбросом, а при выборе способа оплаты по токенам расход идёт в счёт организации. На расход влияют выбранная модель, размер кодовой базы, число параллельных сессий и автоматизация. Для оценки своего расхода предусмотрена команда /usage, а при подписке в ней видны полосы заполнения окон и разбивка по источникам. Денежная сумма в ней считается локально по прайсу и остаётся оценкой: точные суммы смотрят в консоли вендора.
Главная причина быстрого расхода — длинный контекст. Каждый запрос отправляет всю историю разговора, а каждый вызов инструмента порождает следующий запрос с результатами. Даже короткий вопрос в сессии, открытой с утра, тратит окно на весь накопленный контекст. Общий порядок работы команды описан в статье Claude Code для команды; здесь только планирование под ограничения.
Отдельно учитывайте, что при оплате по токенам расход идёт прямо в счёт организации, поэтому там лимитом служит бюджет, который задаёт администратор. На подписке окно заполняется независимо от бюджета, и уткнуться в него можно задолго до конца месяца. Эти два режима требуют разных привычек: в первом следят за суммой, во втором за скоростью заполнения окна.
- Длинный контекст: история разговора и результаты инструментов отправляются с каждым запросом.
- Промахи кэша: первое сообщение после долгой паузы обрабатывает весь контекст заново.
- Подагенты и параллельные сессии: каждый шлёт собственные запросы поверх основной.
- Фоновые задачи по расписанию: запускаются, даже когда вы отошли от компьютера.
- Подключённые серверы и плагины: их имена, описания и инструкции присутствуют в контексте постоянно, хотя определения инструментов MCP по умолчанию подгружаются по мере нужды.
Размер задачи
Планировать работу под лимиты проще всего, дробя задачи на куски, каждый из которых помещается в одну короткую сессию. Задача «перепиши модуль» превращается в цепочку: изучить, составить план, изменить часть, проверить, зафиксировать.
- Одна сессия — одна цель: когда цель достигнута, начинайте новую сессию вместо продолжения старого разговора.
- Конкретные запросы вместо расплывчатых: «добавь проверку ввода в функцию входа» тратит меньше, чем «улучши код».
- Сначала план: режим планирования показывает подход до правок и экономит дорогие переделки.
- Проверяемые шаги: тест после каждой небольшой правки ловит ошибку, пока её дёшево исправить.
- Критерий остановки: решите заранее, когда задача считается выполненной.
Тяжёлые операции вроде запуска полного набора тестов и разбора больших журналов выносите в подагентов или в хуки, которые отдают в основной разговор только краткий итог. Так основной контекст остаётся небольшим, а подробности живут в изолированном окне. Заранее сузьте область поиска: укажите каталог и файлы, с которыми предстоит работать, иначе агент прочитает половину репозитория и сам заполнит окно. Хороший запрос содержит цель, границы и способ проверки результата, и тогда лишних прочтений получается меньше.
Контекст и модель
Два рычага дают самую большую экономию: размер контекста и выбор модели. Оба доступны без сложной настройки, нужна только привычка.
| Приём | Что делает | Когда применять |
|---|---|---|
| Очистка контекста между задачами (/clear) | Начинает разговор с чистого листа | Переход к несвязанной работе |
| Сжатие истории с указанием важного (/compact) | Заменяет длинную историю кратким итогом | Задача продолжается, а контекст разросся |
| Выбор модели по задаче | Сложные рассуждения доверяют старшей модели, рутину младшей | Каждый раз при смене характера работы |
| Снижение глубины рассуждений (/effort) | Уменьшает расход на простых задачах | Правки по ясному описанию |
| Отключение лишних серверов и плагинов | Убирает постоянный груз описаний | Раз в квартал и перед тяжёлой задачей |
Перенос постоянных инструкций из общего файла правил проекта в навыки тоже помогает: общий файл загружается в каждую сессию, а навык подключается по необходимости. Как оформлять такие пакеты инструкций, разобрано в статье Skill Claude Code: повторяемые задачи для команды, а вес подключённых плагинов и способы его проверить описаны в материале Claude Code plugins: установка, права и аудит.
Прерывания
Прерывание из-за лимита рано или поздно случается у каждого, и вопрос в том, сколько работы оно уничтожит. Хорошо спланированная сессия теряет минимум: состояние записано, следующий шаг понятен.
- Прочитайте сообщение: оно показывает, какое окно исчерпано и когда произойдёт сброс.
- Решите, ждать ли сброса, переключиться ли на другую модель (это помогает лишь тогда, когда в сообщении назван лимит конкретного семейства, а общий лимит сессии или недели действует на все модели) или запросить дополнительный объём по правилам организации.
- Зафиксируйте состояние задачи в файле заметок: что сделано, что осталось, какие решения приняты.
- Если сервис предлагает продолжить после сброса автоматически, выберите этот вариант для безобидных задач и запретите для рискованных.
- Запишите прерывание в журнал: время, задача, причина, потерянное время.
- После сброса откройте новую сессию с заметкой в качестве первого сообщения.
Журнал прерываний — главный источник улучшений. Для каждой записи хватает пяти полей: дата, задача, исчерпанное окно, что успели сделать и сколько времени ушло на ожидание. Через месяц видно, какие типы задач упираются в лимит и где они дробятся плохо. Эти записи превращаются в правила команды. Для рабочих процессов с автоматикой вроде запуска из репозитория полезно настроить ограничение числа шагов и времени выполнения, как описано в статье Claude Code GitHub: от задачи к ветке и review.
Какие задачи вашей команды чаще всего упираются в лимиты?
Командный учёт
Для команды лимиты — вопрос управления и личной дисциплины. Администратору нужны сведения о расходе, а сотрудникам правила, которые позволяют работать без остановок посреди срочной задачи.
- Единый способ учёта: кто смотрит расход, как часто и в каком отчёте.
- Правила для сотрудников: очистка между задачами, выбор модели, запрет на забытые фоновые задачи.
- Резервный план: что делать, когда окно кончилось, а задача срочная, например доступ к дополнительному объёму по заявке.
- Разделение ролей: тяжёлые задачи планируются заранее, срочные правки идут по короткому пути.
- Регулярный пересмотр: раз в месяц команда разбирает журнал прерываний и правит правила.
Назначьте в команде ответственного за расход, хотя бы на время запуска. Этот человек раз в неделю смотрит отчёт, собирает записи из журнала прерываний и предлагает одно изменение правил, например перенести тяжёлую проверку на ночь или сократить число подключённых серверов. Одного изменения за раз достаточно: так видно, что именно сработало.
О распределении лимитов в команде для другого инструмента рассказывает статья лимиты Codex: как распределять в команде, принципы похожи. Если вам нужен регламент использования ИИ-инструментов разработки с учётом ограничений, мы собираем его в рамках внедрения ИИ в компании. Журнал прерываний за две недели даст материал для первых правил команды.