Перед долгой задачей в Claude Code: когда делать compact и как контролировать субагентов и расход

Прежде чем поручать Claude Code долго читать код, вносить изменения и запускать тесты, не спешите очищать контекст. Но и сохранять все прежние обсуждения только ради того, чтобы «использовать весь 1M», тоже не нужно.

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

19 сентября ZryMiller рассказал, как изменил свой подход. Раньше он часто сжимал контекст, затем вернулся к окну 1M, которое назвал стандартным. По его ощущениям, работать стало заметно лучше; он также сообщил, что готовится выпустить своё первое приложение. Но в посте нет сопоставимых задач, показателей расхода до и после или подтверждения, что приложение в итоге вышло. Это полезный личный отзыв, но не доказательство того, что «без сжатия любая долгая задача выполняется лучше».

Вместо выбора между «сжимать почаще» и «никогда не сжимать» привяжите решение к завершению конкретного этапа работы.

Сначала проверьте, чем именно вы пользуетесь

Выполните в терминале claude --version и запишите версию клиента. Внутри сессии проверьте аккаунт и текущую модель через /status, доступные модели и связанные настройки — через /model, заполнение контекста — через /context. Для просмотра расхода используйте /usage. Эти команды показывают разные вещи, а не один и тот же показатель в разных видах. Официальный справочник команд · Документация по расходу

Официальное название модели, о которой идёт речь в обсуждении, — Claude Fable 5.1. Её ID в Claude API — claude-fable-5-1, а в официальной спецификации указано контекстное окно на 1M токенов. Модель, версия Claude Code и настройка effort — разные параметры. Записи «использовал Fable» или «работал на Ultra» недостаточно. Официальная спецификация модели

Поддержка 1M у модели не означает, что условия доступа автоматически одинаковы для всех аккаунтов, моделей и способов подключения. Например, официальная документация различает включённый в Max, Team и Enterprise доступ к 1M у Opus и доступ через usage credits на Pro. Для окна 1M у Sonnet 4.6 на подписках тоже нужны usage credits. Не переносите эти правила на другие модели. Также необходимо проверить конфигурацию клиента, сопоставление моделей и поддержку со стороны шлюза: добавление [1m] в выборе модели само по себе не расширит возможности модели на сервере. Условия доступа к 1M и настройки моделей

Важно различать и три показателя, которые легко перепутать. Заполнение контекста показывает, сколько содержимого нужно вместить текущему запросу. Накопленный расход токенов отражает объём входных, выходных и кэшированных данных, обработанных запросами. Лимиты подписки ограничивают использование аккаунта в соответствующих временных окнах. Пять часов или неделя — это окно учёта лимита, а не обещание, что задача сможет непрерывно работать пять часов или неделю. Данные, попавшие в кэш, по-прежнему занимают место в контексте, хотя в API для них могут действовать отдельные тарифы. Поэтому «контекст заполнен на 30%» нельзя пересчитать в «потрачено 30% пятичасового лимита», а 1M — не запас токенов, который можно бесплатно обрабатывать снова и снова. Контекст и кэширование · Структура тарифов API

Перед compact определите, от каких деталей зависит следующий шаг

Допустим, вы разбираете ошибку, которая затрагивает фронтенд, API и базу данных. Только что прочитанные фрагменты кода, неудачный запрос и обнаруженный граничный случай пока не сложились в проверяемые выводы. Если сжать контекст лишь потому, что «чат уже длинный», можно потерять именно те детали, которые нужно сопоставить дальше.

Иная ситуация — когда причина уже установлена, нужные файлы и расположение доказательств записаны, а дальше остаётся внести небольшое изменение по согласованному плану. Тогда значительную часть поисков необязательно держать в текущем окне.

Подходящий момент для сжатия определяется не универсальным процентом заполнения, а тем, завершён ли этап и можно ли продолжить по надёжным записям. Это рекомендация по организации работы, а не фиксированный порог модели.

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

Затем можно вызвать встроенную команду /compact, уточнив, что сохранить: Как работает сжатие контекста

/compact Сохрани текущую цель, подтверждённые выводы и расположение доказательств, изменённые файлы, выполненные проверки и их реальные результаты, нерешённые вопросы и следующий шаг. Убери повторные поиски и обсуждения уже исключённых вариантов.

Это требования к сводке, а не гарантия отсутствия потерь. До следующих изменений попросите Claude объяснить дальнейший шаг по сжатому контексту, а затем сверьте ключевые ограничения с реальными файлами и записью о задаче. Если пропал граничный случай, верните его сразу, а не после того, как реализация уйдёт в сторону и потребует переделки.

Если дальше начинается другая, не связанная с предыдущей задача, обычно проще сохранить результаты и сведения для продолжения, а затем открыть новую сессию через /clear. Вернуться к исходному разговору можно через /resume. Очистка сессии не возвращает уже потраченный объём и не сбрасывает лимит подписки. Команды управления сессиями · Что сбрасывается в отображении расхода

В Claude Code уже есть автоматическое сжатие, поэтому для такого подхода не требуется устанавливать плагин. В версиях v2.1.221 и новее доступна и команда /autocompact: без аргументов она показывает текущее окно автоматического сжатия, а /autocompact auto возвращает настройку окна, подобранную для модели. Последняя команда сохраняет настройку, а не просто сообщает модели ваше пожелание. Максимальное контекстное окно модели и окно автоматического сжатия — не одно и то же. Команда автоматического сжатия

HKTECH_AI предположил, что одно сжатие может расходовать около 15% пятичасового лимита. В посте нет ни счёта, ни метода расчёта, поэтому использовать этот процент как правило не стоит. Сравнивать нужно другое: стало ли после сжатия меньше данных, повторно передаваемых в следующих запросах, и не потребовались ли из-за него повторное чтение, объяснения и исправления.

Субагенты помогают разделить работу, но «по одному» можно обеспечить разными способами

SHCH описал своё распределение ролей: Fable планирует и принимает решения, Scout на Sonnet занимается поиском, а Builder на Opus выполняет чётко поставленные задачи. Отдельно автор советует вызывать только одного субагента за раз.

На опубликованном им скриншоте Builder предлагается следовать готовому плану, остановиться и сообщить о проблеме, если план неверен, не запускать других субагентов и указать результаты проверок. Польза этих инструкций — в понятных границах ответственности. Но фраза «не запускай других субагентов» на картинке остаётся ограничением в промпте, а не программно установленным пределом. Автор также упоминает несколько одновременно работающих основных сессий и не публикует проверяемый расход до и после. Поэтому описанную схему нельзя трактовать как «один агент на весь аккаунт», а тем более обещать фиксированный процент экономии.

Обычный субагент начинает с отдельного контекста, получая поручение и соответствующую конфигурацию. Вся история основного разговора ему автоматически не передаётся; существующий разговор наследует субагент fork. Если вынести объёмный поиск в субагента, в основной сессии может остаться меньше промежуточных подробностей. Но запросы субагента тоже обрабатывают токены, а его итоговый ответ попадёт в основную сессию. Границы контекста субагентов

Поэтому сначала спросите: «Стоит ли вообще делегировать эту задачу?» — и лишь потом: «Сколько субагентов запускать одновременно?» Для простого поиска не нужна полная цепочка из планировщика, исследователя и исполнителя. Две задачи, которые будут постоянно менять один файл, тоже не всегда стоит выполнять параллельно. Для параллельного сравнения лучше подходят действительно независимые исследования с понятным результатом.

Рабочие инструкции можно сформулировать конкретнее, например так:

Цель: Выполнить согласованные изменения и пройти непосредственно связанные с ними проверки.
Допустимая область изменений: Реализация и соответствующие тесты, затронутые этим запросом.
Порядок работы: Простой поиск выполняй напрямую. Если делегирование действительно нужно, передавай только необходимый подзадаче контекст и требования к результату; назначай одного субагента за раз. Во время ожидания не запрашивай один и тот же статус повторно.
Условия завершения: Выполни критерии приёмки и остановись после прохождения нужных проверок. Если работа заблокирована, сообщи, что уже сделано и в чём причина; не запускай ту же задачу заново.

Это по-прежнему требования к поведению. Чтобы действительно ограничить создание встроенных субагентов, используйте настройки клиента. Claude Code v2.1.217 и новее поддерживает ограничение параллелизма и глубины делегирования. Следующий пример запуска в Bash/Zsh для macOS и Linux — осторожная отправная точка для поиска ненужной параллельной работы: Справочник переменных окружения

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

Первая переменная задаёт проверку параллелизма внутри одной сессии при создании новых субагентов через инструмент Agent. Вторая ограничивает субагентов одним уровнем и не даёт им делегировать работу дальше по цепочке. Это не промпты; настройки не меняют задним числом другие уже запущенные сессии. Справочник переменных окружения

Однако это не глобальная блокировка, гарантирующая «не больше одного агента всегда и везде». В официальной документации перечислены исключения: сессии ultracode не применяют это ограничение параллелизма; ручной /subtask и возобновление уже завершённых субагентов не блокируются той же проверкой создания; у рабочих процессов и agent teams собственные ограничения. Несколько основных сессий и процессы, запущенные извне, тоже нельзя вместе ограничить одной этой настройкой. Ограничения параллелизма и исключения

Если вашему планировщику нужен настоящий глобальный предел, запуск, возобновление и повторные попытки должны проходить через общую очередь или блокировку параллелизма. Одной фразы «по одному» в промпте недостаточно. Это часть вашей реализации планировщика, а не ещё одна неописанная настройка Claude Code.

Ждать результат — не значит заставлять модель постоянно спрашивать о прогрессе

LeeLeepenkman жаловался не просто на «использование субагентов». По его словам, Fable 5.1 отправлял muse большой промпт, а затем опрашивал состояние примерно каждые пять секунд, из-за чего контекст быстро рос. В исходном посте нет описания реализации muse, журнала запросов или результата после исправления. Поэтому пять секунд нельзя выдавать за постоянный интервал опроса Claude Code.

У встроенных фоновых субагентов сейчас есть уведомления о завершении, а результаты поступают в основную сессию на следующих ходах. Проверить текущую работу можно через /tasks. Это не то же самое, что снова и снова поручать модели отправлять запрос «Уже готово?». Фоновые субагенты и уведомления о результате

При разборе проблемы раскройте записи вызовов инструментов и проследите за одной задачей. Приносят ли повторные проверки новые сведения? Не запускается ли заново уже завершённая работа? Вызывает ли проверка статуса новый запрос к модели? Ctrl+O открывает более подробный вид разговора, но число обновлений интерфейса нельзя напрямую считать числом запросов к модели. Для расхода по отдельным запросам сверяйтесь также с записями провайдера, через которого вы действительно подключены. Режим взаимодействия и просмотр сессии

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

После восстановления лимита сначала проверьте, что осталось сделать

intwerpret описал более резкий случай. Достигнув лимита, он выбрал ожидание с автоматическим продолжением, после чего, по его словам, появились 39 агентов и снова исчерпали доступный объём. В итоге он вернулся к Codex. В материалах нет версии клиента, содержания задачи, полной конфигурации или указания на источник механизма возобновления. Неизвестно и то, была ли задача в итоге завершена.

Этот отзыв — повод проверить процесс возобновления, но не доказательство того, что «автоматическое продолжение Claude Code обязательно запускает 39 агентов». Упомянутого автором слова «Ultra» также недостаточно, чтобы утверждать, будто он использовал описанный выше режим ultracode.

При этом считать любое автоматическое продолжение работой стороннего скрипта уже нельзя. Официальная документация интерактивного режима описывает встроенное продолжение после восстановления лимита: начиная с v2.1.234, подходящие интерактивные сессии по подписке могут дождаться восстановления доступного объёма и продолжить работу. Это не означает такого же поведения при API-ключе, -p или во всех фоновых режимах. Возобновление также не сводится к повторной отправке последней исходной задачи пользователя. Встроенное ожидание и автоматическое продолжение

Если вы не собираетесь оставлять возобновление задачи без присмотра, отключите в /config Continue automatically at usage limit — автоматическое продолжение после восстановления лимита. В версиях с поддержкой этой настройки можно также выполнить:

/config autoContinueAtUsageLimit=false

Если сессия уже ждёт, отмените и это конкретное ожидание: нажмите Esc при пустом поле ввода или выберите Don’t continue automatically — не продолжать автоматически в /rate-limit-options. Изменение настройки по умолчанию и отмена уже выбранного ожидания — разные действия. Отмена и настройка автоматического продолжения

Затем проверьте /tasks и фактическое состояние файлов. Что ещё выполняется, что готово, а чему нужна лишь дополнительная проверка? Используйте существующие результаты и явно укажите, какую незавершённую работу продолжить. Не отправляйте весь запрос заново, чтобы модель снова разбивала его на задачи.

Особенно важно проверить успешность предыдущей попытки перед коммитом, развёртыванием, отправкой сообщения или другим действием с внешними последствиями. Восстановление лимита отвечает только на вопрос «Можно ли снова делать запросы?». Оно не гарантирует, что следующие действия не повторят уже выполненные.

Сначала оцените результат, затем — изменение расхода

chasemdev пояснял, что Fable не пишет весь код сам, а координирует субагентов Opus. При этом автор ожидал, что скоро достигнет недельного лимита. «Скоро» здесь — его прогноз на тот момент, а не подтверждённый итог расхода. Но это напоминает о том, что легко упустить при учёте: учитывать нужно не только основную модель, но и модели субагентов и выполненную ими работу.

В текущем /usage раздел Session показывает расход токенов сессии и рассчитанную локально оценку стоимости. Пользователи подписок в том же интерфейсе видят расход по тарифному плану. Сумма в долларах в Session — не счёт за подписку; она также не обязательно совпадает с итоговым списанием API-провайдера. При оплате по факту использования ориентируйтесь на счёт своего провайдера. Что сейчас показывает /usage

Локальное распределение расхода подписки по компонентам — тоже лишь подсказка. Разбивка по субагентам, плагинам, навыкам и другим компонентам строится по недавней истории на этой машине. Она не охватывает весь расход с других устройств и веб-версии и не доказывает, «сколько лишнего потратил конкретный плагин». Если видите Showing last-known usage, запишите время показанных данных и обновите их перед сравнением. Границы атрибуции и кэшированные показатели

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

Что записать	На какие вопросы ответить
Задача, исходная версия кода, модель, effort, версия клиента	Сравниваются ли до и после одинаковая работа и одинаковые настройки?
/context и процесс сжатия	Не потерялись ли ограничения, не пришлось ли повторно читать или объяснять?
Субагенты и поведение во время ожидания	Какие задачи созданы и возобновлены, сколько одновременно выполнялось на пике, были ли повторные проверки без новых сведений?
Показатели расхода, время и границы сброса лимита	Не произошло ли восстановление лимита, не смешалась ли работа других сессий, учтены ли все связанные модели при API-доступе?
Фактический результат и проверки	Выполнены ли требования, прошли ли нужные проверки и сколько ручной доработки осталось?

Меняйте только один приём: например, сжимайте контекст после завершения исследования или ограничьте параллелизм новых субагентов. Сохраняйте исходные критерии приёмки; не сокращайте незаметно задачу ради меньшего расхода. Отмечайте и различия в состоянии кэша. Если в двух запусках различались модели, версии кода или объём задачи, не приписывайте всю разницу сжатию.

Меньше токенов при пропущенных требованиях или проверке, оставленной человеку, — не улучшение. И наоборот: если более длинный контекст позволил закончить задачу за один проход без повторного расследования, одно лишь большее заполнение окна не делает такой подход расточительным.

Независимый API-доступ и подписку тем более нужно учитывать отдельно. Смена источника оплаты не сбрасывает исходный лимит подписки и не меняет автоматически делегирование, ожидание и сжатие в клиенте. Чтобы понять, оправдан ли переход, сравнивайте общий расход и объём переделок для завершения одной и той же задачи, а не только цену единицы использования модели. Различия способов оплаты · Учёт токенов в API

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

Kun Chen начал с практичного вопроса: «when should i /compact my session» — когда стоит сжимать текущую сессию? Его compact-adviser использует Jev от TypeSafe, чтобы определить подходящий момент на границе этапов работы. Есть режим подсказок и автоматический режим, который нужно включить явно. Описание проекта

Для проверки в этой статье зафиксирован коммит d1655faa16a22b68bff60c3d7deb0123e1e52a53; в нём манифест плагина Claude Code указывает версию 0.1.4. Проект требует Node.js 22 или новее и Claude Code 2.1.274 или новее, а проверку совместимости заявляет для 2.1.275. Интеграция с Claude Code зависит от экспериментальных function hooks и требует CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1. Это заявленные проектом условия совместимости, а не результат установки и испытаний для этой статьи. Манифест зафиксированной версии · Требования к версиям и интеграции

Главное: режим hint означает лишь, что сжатие не запускается автоматически. Он не означает локальную оценку без передачи контекста наружу. В документации по безопасности сказано: после установки, если ключ доступен в окружении запуска, сохранённых настройках или .env в рабочем каталоге и выполнены условия вызова, в TypeSafe отправляются отобранные фрагменты сессии. Это ограничения пользователя, недавние видимые ответы и результаты инструментов, существующая сводка и имена созданных материалов. Отдельного переключателя согласия на передачу нет. Во фрагментах всё ещё могут оказаться код или деловые сведения; очистка по принципу best effort не гарантирует отсутствия чувствительных данных. Границы передачи контекста

Если плагин уже установлен, его можно отключить через /compact-adviser off или запускать так:

COMPACT_ADVISER_DISABLE=1 claude

Согласно описанию проекта, это останавливает запросы плагина, подсказки и автоматическое сжатие. Отключается плагин, а не собственное автоматическое сжатие Claude Code. Если нельзя дополнительно передавать рабочие материалы в TypeSafe, отключите или удалите плагин, а не просто переключите auto на hint. Способы отключения

Упомянутая автором оценка на 40 сессиях — собственная оценка проекта; набор данных не опубликован. Она не гарантирует, что в ваших задачах сохранятся все детали. Даже если плагин считает момент подходящим для сжатия, решающим остаётся то, сможет ли работа корректно продолжиться. Границы оценки

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

Цель управления долгой задачей — не заполнить окно и не сделать каждый запрос как можно дешевле на вид. Цель — меньше работать впустую и надёжно закончить уже начатое.