Почему я вернулся на контекстное окно в 200К у Клода

Весной мне хватало подписки за 100 долларов для всех задач по моему пет-проекту. Идея полностью высадить пятичасовой лимит токенов выглядела как вызов. В самом начале лета я уже неплохо справлялся с этой задачей, а в августе лимитов стало хватать только на проработку технического дизайна решений, а до старта реализации приходилось ждать следующей недели. Запускал в работу и тратил весь недельный лимит примерно за 3 дня.

В cентябре у меня была подписка уже за 200$, но и её лимиты не выглядели недостижимыми. Некоторые друзья и коллеги рассказывали, что у них давно имеется по максимальной подписке на Claude и GPT одновременно и планы купить даже третью!

Вливать дополнительные деньги выглядело тупиковым сценарием и я начал разбираться, как можно оптимизировать потребление токенов. Главная причина нашлась не в сложности выполняемых задач и объеме вычитываемого кода, а в банальном повседневном удобстве.

Пачки задач

Мне нравилось сводить пачку хорошо проработанных задач в целый батч из 5-15 штук и отправлять разом в разработку. Верхнеуровневый агент мог целыми ночами её перемалывать ни разу не доходя до компакта сессии.

Это было исключительно удобно, потому что вечерами я занимался проработкой задач, а непосредственное их исполнение могло идти без моего участия. Как максимум из-за обрывов интернета нужно было написать "ты прервался, возобнови работу с момента остановки".

Удачно накладывался нюанс, что примерно с 21:00 Мск и до 9:00 следующего дня был провал по активности клиентов из Штатов (а это основной рынок Anthropic по количеству пользователей). Модельки работали быстро.

Обычно агент завершал всю пачку на собственном контексте в 500-800к, а мне оставалась независимая проверка выполненного объема вместе с GPT. Это было результативно и позволяло найти баги, которые Клод своими замыленными глазами и разболбайским подходом поймать не мог.

Неприятных побочных эффектов у этой схемы оказалось несколько и все упираются в особенности работы кэша:

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

2. Промах кэша на большом контексте будет стоить вам очень дорого. Повторный запрос в старую сессию на 800К токенов заставит заплатить заново за каждый токен (расходом лимита на подписках или деньгами на API);

3. Кэш субагента живет всего 5 минут также между вызовами инструментов. Если он ушел в долгую задачу, например запуск всей пачки интеграционных тестов в самом финале работы, то по факту её завершения весь контекст агента перечитается заново. У меня субагенты могли выростать до 400-600к в среднем. Подтюнить кэш субагентов можно параметром subagentPromptCacheTtl: 1h (или env CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL), но максимум также 1 час. Важно помнить, что цена работы с кэшем для субагентов в этом случае увеличивается, так что экономии может не случиться;

4. Обращение к кэшам имеет свою цену. По мере увеличения контекста сессии, стоимость чтения кэша также возрастает, а ведь каждый вызов инструмента (tool call) заставляет это делать в полном объеме. На банальную правку одного бага таких вызовов может быть около 20-50. Работа на сессии с 800К токенов примерно в 8 раз дороже, чем те же действия на 100К токенов. Это справедливо и для субагентов. Можно сделать вывод, что стоимость чтения кэша пропорциональна размеру контекста (условные "1" для 100К и "8" для 800К).

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

Тяжелые циклы разработки

Еще с Opus 4.5 я использовал подход классической agile-команды субагентов с разными промптами. Выглядело это следующим образом: аналитик разбирает задачу и передает в разработку, программист пишет код, ревьювер и QA принимают у него задачу с разных сторон. Управляет всем этим оркестром один верхнеуровневый агент. Задача одна, но у каждого агента своя конкретная цель в узкой области компетенций. Удивительно, но они находили кучи реальных косяков друг у друга.

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

Сейчас модельки поумнели. Например Sonnet 5 вполне способен тягаться с Opus 4.8 и быть лучше, а недавно вышло поколение 5.5. Если так, то зачем платить больше на дорогих агентах? И я так подумал, когда понял, что все мои субагенты пашут на топовых Opus 5 и Fable 5.1, да еще и на жирном контексте.

Решение очевидное:

• для дешевых задач (мелкие кросс-репо фиксы, разработка) используйте Sonnet, а для поиска берите хоть Haiku (кто-то им вообще пользуется?);

• дорогую аналитику и ревью отдавайте Opus/Fable;

• явно скажите субагенту-аналитику дробить большие задачи на пачки, чтобы контекст исполнителей не взрывался;

• запретите верхнеуровневому агенту будить спящих субагентов ради мелких правок, ведь в таком случае вы заплатите заново за весь их контекст.

Запрет на написание комментариев

Нейронки особенно любят писать размашистые комментарии для инфраструктурного кода. Ansible это просто идеальная область для их извращенного понимания того, что должно быть в комментах написано. Сюда попадает и описание логики работы тасок/плейбуков, и знания про реальную инфраструктуру (какая виртуалка где, как настраивалась, что внутри неё), и даже, черт возьми, принципы работы ансибловых модулей. Иногда видишь 20 строк комментариев на одну единственную строчку с переменной.

Не сильно лучше ситуация и в генерации кода приложений. Обычная история, когда комментарии занимают треть всего объема и больше. Как-то в диалоге с Клодом он сам мне признался, почему комментарии получаются такими размашистыми, при том сказал предельно честно:

Потому что субагенты пишут комментарии для себя, но не для будущих читателей. В комментариях они просто проговаривают, что собираются делать и как это будет работать.

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

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

Все это привело меня к пониманию, что проще запретить писать комментарии, чем бороться с их содержимым. Я сформулировал следующее правило (можете просто добавить себе в скиллы отдельной строкой):

Категорически ЗАПРЕЩЕНО писать комментарии на основе принципа "комментарий полезен, если информация верна и относится к делу". Использовать подход: комментария нет по умолчанию, он должен доказать право на существование. Субагентам давать этот же бриф дословно.

Чистота кода возросла кратно, а принцип лучшая спецификация это и есть сам код наконец стал действительно что-то значить.

Летопись в CLAUDE.md

Файлы CLAUDE.md и AGENTS.md важны для быстрого погружения агентов в суть проекта, ведь каждая новая сессия фактически видит ваш проект в первый раз. В таком случае я никак не могу понять, почему агенты так безобразно ведут эти файлы самостоятельно.

Я начинал с базовых 20-30Кб, но через несколько месяцев обнаружил верхнеуровневый CLAUDE.md весом 140Кб. Каждый субагент считал своим долгом в деталях объяснить выполненную им работу.

Но проблема даже не в этом. Для эффективного погружения агентов в работу я построил целую иерархию проекта:

• на верхнем уровне был CLAUDE.md с коротким описанием всего проекта и взаимосвязями его разных репозиториев, инвариантами (как же нейронки любят это слово), ограничениями и правилами работы;

• в подкаталоги были склонированы сами репозитории уже со своими CLAUDE.md с детальным описанием своей области.

Такой подход мне очень нравился, потому что позволял дотаскивать кросс-репо фичи буквально одним запросом. Исчезали целые классы проблем, например когда агент из ui говорил "у меня все нормально", а агент из бэка отвечал "проблема точно на стороне ui", и так по кругу (что-то мне это напоминает). За все отвечал верхнеуровневый агент и организовывал решение запросов практически любой сложности.

Что могло пойти не так?

При запуске субагентов из родительской сессии есть один решающий нюанс: субагент всегда стартует в рабочем каталоге основной сессии. Это означает, что он автоматически читает верхнеуровневый CLAUDE.md и следом (по моим правилам работы) такой же файл, но уже в целевом репозитории, в котором ему предстоит выполнять задачу. Если сложить размеры обоих файлов, то получалось, что субагент на старте еще до начала работы мог съесть 150-200К токенов, просто чтобы понять где находится. За ночь могли запуститься 20-50 таких субагентов.

Сказать субагенту "не читай верхнеуровневый CLAUDE.md", к сожалению, нельзя. Выходит единственно возможный путь оптимизации это сжатие всех таких файлов. Отказываться от них совсем не советую, но вполне возможно при оптимизации их содержимого сказать агенту что-то в духе: "оставь в файле только ту информацию, отсутствие которой способно сломать проект." Такой запрос даст сжатие примерно на 90% (в зависимости от того, насколько все запущено).

Частый compact это и есть решение

Помню еще до введения 1 млн. контекста у меня подкатывала легкая тревога, когда агент посреди объемной задачи подходил к моменту автоматического компакта. Я тогда думал, что ну вот сейчас точно потеряется что-то важное и все пойдет наперекосяк.

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

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

Как выбрать удачный момент для сжатия? Ну например когда вы переходите от дизайна задачи к её реализации.

Я нашел у процесса сжатия еще и приятный побочный эффект. Во время работы активное контекстное окно содержит всю информацию, в том числе подробные вызовы инструментов, вывод команд и скриптов, все вычитанные файлы, лог общений с субагентами. Около 90% из этого вообще не нужно, а компакт как раз подчищает этот объем. В итоге у агента остается конспект с самой важной информацией для продолжения работы. Это очень похоже на работу "оперативной" памяти у человека, когда ночной сон сбрасывает все подробности, которые вы помнили с момента последнего пробуждения, но оставляет в памяти самое важное и запоминающееся иногда на десятилетия.

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

Добро пожаловать на 200к, снова

Рациональное использование ресурсов было одной из основных инженерных задач во время моего обучения в ВУЗе. За расточительный расход памяти регистров можно было запросто пойти на пересдачу. Возможно поэтому вопрос оптимизации использования токенов в моменте увлек меня даже больше, чем сам процесс агентской разработки.

Хочется сказать, что городить огород с решениями под хранение памяти агентов и контекста сессий выглядит малоперспективным направлением, потому что каждый раз нового объема будет не хватать. Но главным побочным эффектом является даже не усиленное потребление токенов (ходят слухи, что для всех желающих OpenAI готовит подписку на $500), а деградация качества работы самих агентов, которая тем сильнее, чем больше контекста израсходовано.

Бросать все и выставлять CLAUDE_CODE_DISABLE_1M_CONTEXT=1 прямо сейчас конечно не стоит, но вот начать следить за расходом ресурсов можно в любой момент, это полностью в ваших силах.