Токенная диета для ИИ-агентов: Caveman, Ponytail и Headroom

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

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

Каждая отдельная вещь выглядит терпимо. В длинной сессии это превращается в счет у провайдера, раннее сжатие истории, забитое окно контекста и потерянные детали. Агент вроде продолжает работать, но внезапно забывает ограничение, на котором держалась задача.

Отсюда и появилась странная, но практичная тема: токенная диета для агентов.

На первом уровне это, конечно, экономия денег. Меньше входных токенов, меньше выходных токенов, меньше счет при оплате по API. Но на практике история шире.

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

Сначала такие инструменты выглядели почти как мем. Caveman: агент отвечает как пещерный человек, без церемоний и длинных объяснений. Потом появился Ponytail: “ленивый сеньор”, который перед написанием кода сначала проверяет, можно ли не писать его вообще. Теперь рядом всплыл Headroom: локальный слой, который сжимает логи, выводы команд, JSON и историю до того, как все это попадет в модель.

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

Мне они интересны именно вместе. По ним видно, что фокус постепенно съезжает с вопроса “какую модель выбрать” к более скучному, но практичному вопросу: почему агент вообще так много тащит, пишет и проговаривает.

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

Но длинный контекст не работает как идеальная память.

У Chroma, команды, которая делает инфраструктуру поиска и хранения контекста для ИИ-приложений, есть технический отчет от июля 2025 года. Они сравнивали 18 моделей на контролируемых задачах и смотрели, что происходит, когда вход становится длиннее. Их термин context rot я бы по-русски перевел как “протухание контекста”: текст формально лежит в окне модели, но пользоваться им модель начинает менее надежно.

Рядом с этим лежит более старый эффект Lost in the Middle: нужная информация хуже достается, когда она оказывается в середине длинного контекста, а не в начале или конце.

Вместе эти две идеи хорошо объясняют, почему токенная диета не сводится к “заплатить меньше”. Лишний контекст не просто стоит денег. Он может мешать модели пользоваться важными деталями.

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

Где агент набирает лишнее

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

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

Самый заметный слой — речь. Агент может раздуть видимый ответ: вместо одной команды написать вступление, рассуждение, список вариантов и бодрый финал.

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

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

Это разные источники лишнего веса. Их нельзя лечить одним и тем же способом.

Caveman работает с речью агента: меньше выходных токенов, меньше текста в истории, меньше времени на чтение.

Ponytail работает с реализацией: меньше лишнего кода, меньше файлов для проверки, меньше будущего контекста, который следующие агенты будут тащить за собой.

Headroom работает с входом в модель: меньше сырого вывода инструментов, логов, JSON и длинной истории внутри сессии.

Если спутать эти слои, получаются странные ожидания. Caveman не обязан делать агентную сессию в два раза дешевле. Ponytail не является компрессором контекста. Headroom не учит агента быть хорошим разработчиком.

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

Дальше я буду держаться этой простой карты: речь, реализация, контекст.

Смысл схемы не в том, что один инструмент лучше другого. Они просто режут разные источники лишнего веса.

Caveman: меньше говорить

Caveman — самый прямолинейный из трех.

Это набор правил или плагин для агентных инструментов вроде Claude Code, Codex, Cursor, Gemini, Windsurf и других. Он говорит агенту: отвечай коротко, убери приветствия, воду, самоповторы и декоративные объяснения. Но не трогай код, команды, пути, имена API и тексты ошибок.

По сути, Caveman не делает агента умнее и не уменьшает все расходы сессии. Он убирает публичный шум.

В README заявлена средняя экономия 65% выходных токенов на 10 задачах. Диапазон большой: где-то 22%, где-то 87%. И это важная деталь: речь про выходные токены, то есть про то, что модель написала в ответе.

Для базового режима автор отдельно вынес честное предупреждение в HONEST-NUMBERS.md: Caveman сжимает именно видимый ответ. Он не уменьшает вход, файлы, общий контекст и скрытые рассуждения модели. Более того, сами правила добавляют примерно 1-1.5k входных токенов на ход.

Вот здесь мем превращается в нормальную инженерную тему.

Если агент обычно пишет длинные объяснения на тысячу токенов и больше, Caveman может быть полезен. Особенно там, где от ответа нужен статус, команда, короткое решение или аккуратная сводка вывода инструмента. Ответ быстрее дочитывается, в нем меньше церемоний и меньше “Sure, I can help” перед одной полезной строкой.

Но если обычный ответ и так на 150-300 токенов, Caveman может стать налогом. Он сэкономит копейки на выходе и добавит больше на входе. Если сервис считает не токены, а запросы, экономии по деньгам может не быть вообще.

При подписке смысл все равно остается, просто другой. Это не обещание, что Caveman сам вылечит протухание контекста. Скорее он убирает один источник мусора: длинные видимые ответы, которые потом остаются в истории и попадают в пересказы.

Мне нравится, что проект это не прячет. У таких инструментов обычно сильный соблазн написать “минус 65%” крупно и дальше не объяснять. Здесь хотя бы видно границу: Caveman полезен против болтливости, а не против всех расходов агентной сессии.

И еще одна граница. Краткость не всегда добродетель.

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

Ponytail: меньше строить

Ponytail атакует другую часть расходов.

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

Нужно ли это вообще? Есть ли уже похожий код в проекте? Умеет ли это стандартная библиотека? Есть ли штатная возможность платформы? Покрывает ли задачу уже установленная зависимость? Можно ли обойтись маленьким изменением? И только потом писать новый код.

Сама идея старая. YAGNI, стандартная библиотека перед велосипедом, возможности платформы перед новой зависимостью, меньше самописного там, где оно не нужно. У людей это называется инженерной привычкой. У ИИ-агентов с ней часто плохо.

Агент видит задачу как приглашение производить код. Чем сильнее модель, тем убедительнее она может развернуть маленькую правку в маленькую архитектуру. Иногда это выглядит аккуратно. Но разбираться потом все равно человеку.

Мне Ponytail интересен именно как попытка зашить старую инженерную привычку в агентный цикл.

С цифрами там надо аккуратно. Самый вирусный крючок вокруг Ponytail — 90% или 94% меньше кода. Такие числа действительно встречаются, но это не средняя магическая экономия. Это пик на задачах с явной ловушкой переусложнения, вроде ситуации, где агент строит самописный выбор даты вместо штатного элемента.

После критики ранних сравнений проект выложил более внятный, но все еще официальный и узкий прогон от 2026-06-18: Claude Code без интерфейса, Haiku 4.5, один публичный репозиторий, 12 задач на продуктовые изменения, по 4 прогона на ячейку.

Там средние числа по задачам на продуктовые изменения такие:

Это не доказательство универсальной экономии. Но как рабочий сигнал — уже интересно.

Еще полезнее не средняя цифра, а распределение. На задачах, где агент мог реально раздувать решение, Ponytail сильно резал изменение. На типовых CRUD-задачах на серверной части эффект почти пропадал. Это похоже на правду: если лишнего кода нет, минимализм не достанет экономию из воздуха.

Интересный контроль в этом же прогоне — Caveman. Он уменьшал количество строк слабее Ponytail и при этом на задачах с продуктовым изменением увеличивал токены, стоимость и время. Для меня это хороший маркер: “говори короче” и “делай меньше лишней работы” — разные навыки.

Главная ценность Ponytail даже не в токенах. Для меня важнее объем, который человеку потом надо понять и принять на себя. Маленькое изменение дешевле проверить. Меньше файлов — меньше мест, где агент мог ошибиться. Меньше абстракций — меньше будущего долга.

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

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

Поэтому Ponytail может уменьшать текущий объем изменения и будущую площадь внимания. Хотя это уже вывод из устройства агентной работы, а не отдельная метрика этого прогона.

Но здесь тоже есть граница.

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

Я бы не ставил Ponytail как глобальный режим для всех ролей. Для агента, который пишет код, это полезное смещение. Для агента, который проверяет изменения, аудитора безопасности или архитектора — уже опаснее. Им нельзя быть “ленивыми” в смысле “сказать меньше замечаний”.

Headroom: меньше тащить в модель

Headroom находится на третьем уровне.

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

Если Caveman режет то, что модель говорит наружу, Headroom режет то, что модель читает на входе.

В README у Headroom сейчас заявлены 60-95% меньше токенов для JSON-данных и 15-20% для агентов, которые пишут код. Плюс локальная работа и обратимое сжатие. Я бы не читал это как “любой текст превращается в короткую версию без потерь”. Практически идея проще: исходный материал остается локально, в модель уходит более короткая версия, а если нужна деталь, агент может вернуться к оригиналу.

Для читателя это можно держать проще: перед моделью появляется фильтр. Он понимает, что перед ним лог, JSON, вывод команды или обычный текст; оставляет структуру и подозрительные места; убирает повторяющийся шум; а то, что опасно сжимать, пропускает как есть.

Headroom устроен шире, чем одно правило. Он не говорит агенту “будь кратким” и не просит писать меньше кода. Он управляет потоком данных вокруг агента: что отправить в модель целиком, что отправить в сокращенном виде, что сохранить рядом на случай, если понадобится полная версия.

Мне здесь больше всего нравится не рекламная цифра, а сама постановка задачи. В агентной разработке контекст часто раздувается не из-за финального ответа. Он раздувается из-за инструментов.

git diff, результаты поиска, лог сборки, JSON от API, список файлов, кусок документации, очередная история переписки. Модель может получить 10 тысяч токенов, чтобы найти одну строку с FATAL.

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

В документации с замерами есть хорошая отрезвляющая часть. На наборе реалистичных выводов инструментов общий результат — 66.1% сжатия. JSON, вывод командной оболочки и логи сборки сжимаются сильно. А результаты grep и исходный код на Python получили 0%, потому что уже компактны или опасны для сжатия.

Есть и еще более полезная цифра: рабочая телеметрия. Медианное сжатие там всего 4.8%, среднее 11.3%, потому что много запросов короткие и разговорные. Зато тяжелые сессии с большим числом инструментов дают 40-80%.

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

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

Сначала понять, где пухнет

С этими инструментами легко прийти к неправильному выводу: поставить все сразу и ждать, что агент сам станет дешевым и аккуратным. Я бы так не смотрел.

Диета работает только тогда, когда понятно, от чего именно набирается лишнее. Caveman нужен, если агент распухает в ответах. Ponytail — если реализация превращается в маленькую стройку на пустом месте. Headroom — если в модель летят огромные логи, JSON и выводы инструментов.

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

Но это не значит, что все надо ставить сразу. Если болит только болтливость, Headroom может быть лишним. Если основной шум — огромные логи и JSON, один Caveman не спасет. Если проблема в переусложнении кода, сжатие контекста не научит агента выбирать штатный элемент вместо самописного компонента.

Я бы начинал с простого наблюдения за своими сессиями.

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

Это звучит банально, но именно здесь появляется польза. Инструмент выбирается не по красивому проценту в README, а по месту, где агент реально набирает лишнее.

Сначала симптом, потом инструмент. Иначе легко поставить все сразу и не понять, что вообще сработало.

Можно смотреть на эти проекты как на набор способов платить меньше. Это нормальный практический мотив. Но если остановиться только на деньгах, тема становится мелкой.

На практике агент может быть умным и все равно дорогим. Может быстро решить задачу и оставить лишний слой кода. Может иметь большое окно контекста и все равно забивать его логами, пересказами и случайными кусками истории.

Поэтому мне ближе смотреть на Caveman, Ponytail и Headroom как на части одной дисциплины.

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

Обратная сторона везде одна и та же. Если резать не там, качество падает.

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

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

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

Мне нравится этот сдвиг. Не потому что 65%, 54% или 95% звучат красиво. Такие цифры почти всегда зависят от сценария.

Нравится другое: в этих проектах наконец-то признается, что цена токена тут не единственная проблема. Проблема еще и в поведении агента, и в качестве контекста, который он тащит за собой.

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

Это не самый эффектный сдвиг. Зато он ближе к реальной разработке.