Разрушители мИИфов – тестируем Headroom. Правда ли умная прокся может сэкономить вам токены?

Признаю: в прошлой статье про тестирование Caveman я в конце написал, что такие инструменты, как RTK, действительно, могут помочь сэкономить токены. Я доверял самому принципу возможности экономии токенов, но не доверял конкретным цифрам эффективности, которые заявляет Headroom. Был уверен, что, садясь за тесты, скорее всего, увижу, не 60–95% экономии токенов, а типа 10% — или что-то такое. Но результат меня удивил в худшую сторону. Итак, тестируем Headroom вместе:

Как Headroom работает

Если у Caveman был довольно простой принцип работы, который укладывался буквально в пару строк, то у Headroom он заслуживает отдельного описания.

Проблема, с которой инструмент борется: когда кодинг-агент (например, Claude Code или Cursor) работает, он с каждым шагом тащит в модель всё больше контекста: вывод команд, простыни логов, прочитанные файлы, историю диалога. За все эти токены ты платишь, и на длинных сессиях сумма набегает приличная.

Headroom встаёт прокси-прослойкой между агентом и API. То есть, чтобы инструмент заработал, нужно слать все запросы не напрямую в API Anthropic, например, а сначала в локальный Headroom. В нем происходит следующее:

1. Прокси перехватывает ваш запрос;

2. Смотрит на тяжелые куски и выбирает инструмент для сжатия:
   * JSON — структурно (SmartCrusher): выкидывает форматирование и повторы.
   * Код — через AST/rtk (тот самый Rust Token Killer).
   * Логи, текст — локальной моделью Kompress-v2-base через PyTorch, которая сокращает их.

3. Чтобы оригинал можно было подгрузить при необходимости он кэшируется, а модели подсовывается специальный инструмент, которым она может дозапросить полный кусок, если он реально понадобится (Headroom называет это CCR — Compress-Cache-Retrieve).

Звучит все это сложно и потрясающе. И еще обещает экономию в 60–95%, ну и разумеется, без потери качества.

Как тестировал

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

1. Сделал маленький репозиторий — снова top-down игру про робота, но 4 ключевые функции отсутствуют, из-за чего unit и e2e тесты красные. Репозиторий тут. 

2. Задача агента — реализовать заглушки, чтобы всё позеленело. Промпт короткий, как и в прошлый раз:

Почини репозиторий: доделай все незавершённые функции, чтобы все тесты (юнит и визуальные) прошли и игра запускалась. Вопросов не задавай.

Гонял в изолированном Docker-контейнере (чтобы не трогать рабочий Claude Code). И еще момент: в этот раз решил делать по 3 прогона на конфиг и измерял по статистике, которую Claude Code сам отдаёт в конце сессии.

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

Часть 1. Просим починить тесты

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

С Headroom вышло значительно дороже. В каждом прогоне с Opus +62% к стоимости, а с Sonnet +45%. И это не просто выброс — диапазоны трёх прогонов даже не пересекаются. То есть, самый дорогой прогон без Headroom — дешевле самого дешёвого с ним. Но при этом в каждом прогоне все тесты проходили успешно — хотя бы это хорошо.

Интересные моменты

Экономим 2%. Если смотреть на отчеты самого хэдрума через инструмент headroom perf, то он в среднем отчитывался, что сжимал контекст всего на 2%. 

Headroom снижает эффективность кэша. Поискав немного статистику, заметил, что использование кэша в диалогах с Headroom оказалось где-то около 94% вместо ~98% в сессиях без Headroom. Казалось бы, всего 4% разницы, но это и дает основной прирост в цене.

Часть 1.5. Как считается цена использования модели

Мне кажется, тут стоит проговорить, что такое этот кэш, как он работает и как с вас списывают за него кэш? Anthropic тарифицирует довольно хитро: за токены, — но по четырём разным ценникам. Вот они для Opus 4.8:

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

К примеру. Пусть контекст дорос до 150k токенов, впереди ещё 14 ходов:

• Без кэша: каждый шаг цикла — 150k × $5/М = $0.75. За 14 итераций $10.5 только на переотправку одного и того же.

• С кэшем: стабильный префикс записали один раз (150k × $6.25/М ≈ $0.94), а дальше 14 раз читаем из кэша (150k × $0.5/М = $1.05). Итого получится примерно $2, то есть в 5 раз дешевле.

Выглядит это как-то так:

Сам Claude Code выжимает из кэша ~98% попаданий. И это довольно хорошо сказывается на итоговом счете.

Так вот: каждый процент контекста, который промахнулся мимо кэша, дорожает в 10–12 раз — вместо $0.5/М (read) он идёт по $5/М (fresh input) или $6.25/М (write).

Поэтому Headroom, встающий между агентом и кэшем, как бы говорит: он будет делать работу лучше, чем Claude Code. Сильное заявление.

Часть 2. Уловка-22

У headroom оказалось пару настроек, которые, судя по их описанию, могут помочь с кэшем:

—mode cache — это мод который нацелен именно на сохранение кэша. Есть еще вариант token, который стоит по дефолту и оптимизирует токены;

—target-ratio — это настройка которая контролирует сжатие.

Во второй группе тестов я поставил сжатие на 0.4 и mode = cache

Результаты:

Ни один конфиг не выиграл у baseline. В лучшем случае (Sonnet aggressive) сравнялся с эталоном — при 0% сжатия.

В целом тут все понятно. Но меня настолько шокировала бессмысленность этой ерунды, что мне уже было интересно, почему так плохо-то? Почему даже при сжатии в 0% цена выходит больше? 

Я полез в логи Headroom и попробовал поискать там. Логи можно получить, если запустить прокси с логом в файл:

headroom proxy —port 8787 —mode cache —log-file ~/hr.log &

Там есть три вот таких строчки:

1. Pipeline: freezing first 12/22 messages (prefix cached by provider)

2. ReadLifecycle: skipping N stale/superseded replacements in frozen prefix

3. CCR: deferring tool injection (frozen_message_count=12) to preserve cache

Что они означают:

• Чтобы сжать контент, нужно дать модели retrieve-инструмент (иначе она не сможет достать оригинал, и сжатие станет безвозвратной потерей данных).

• Но вставка инструмента меняет запрос — это ломает тот самый кэш, который Headroom только что решил беречь (строка 1).

• Поэтому он не вставляет инструмент (строка 3).

• А без инструмента нельзя безопасно сжимать контекст — поэтому он и не сжимает устаревшие чтения (строка 2).

Получается уловка-22 – если мы даем инструмент для экономии токенов, то ломаем кэш и меньше расходуем токены, но больше платим. Значит, ломать кэш нельзя. Но если не даем инструмент для сжатия, то ничего не сжимаем и тем самым ничего не экономим.

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

Часть 3. Разбор большого файла

Мне все же стало интересно, а можно ли хоть как-то вообще получить то самое сжатие? Ну хотя бы какое-то.

По описанию headroom должен быть идеален в сжатии больших логов и выделении из них нужной информации. 

Окей, давайте тестировать. Я сгенерировал большой лог на ~4 тысячи строк, где искомая ошибка была специально подложена в начало лога: WARN о том, что пул соединений снизили с 50 до 5. Дальше дал промпт:

В файле logs/incident.log — лог продакшн-инцидента. Не задавая вопросов, разберись и напиши POSTMORTEM.md: первопричина, хронология каскада отказов и что чинить.

Результаты:

Разброс результатов довольно большой. Сначала я прогнал тест три раза. Но заметил, что из-за разброса этих данных маловато. И прогнал тесты еще по три раза. 

На Opus медиана оказалась на удивление ниже, чем в базовом случае. Хотя среднее значение стабильно выше. И в целом во всех случаях интервалы минимума и максимума хотя бы начали пересекаться с базой.

Лучшее сжатие Headroom показал на модели Sonnet с настройкой —mode token. Тут можно подумать: «Ну вот — работает!» Но не тут-то было. В прогоне, где Headroom заявил об экономии в 46%, он потратил не $0.364, а $0.661. То есть, ему это сжатие не помогло добраться до минимума. Скорее всего, просто сам Claude Code в этом прогоне был более везуч.

Итого, даже в лучшем — самом пригодном для инструмента — случае, я так и не смог найти какой-то эффективности.

Общий итог по бенчмаркам

Ни на кодинге, ни на идеальной задаче по сжатию теста, ни в одном из режимов Headroom не дал обещанной экономии. token-режим сжимает, но ломает кэш и выходит дороже. Сache/aggressive бережёт кэш и приходит примерно вровень с baseline, но при этом не сжимает вообще. Заявленные 60–95% не воспроизвелись ни разу.

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

А теперь график звёзд

С Caveman график звёзд, был совсем подозрительным. Там в первый же день репозиторий набрал аж >2000 звезд. В Headroom все не настолько подозрительно. 

Репозиторий создан 7 января 2026. И свои первые 2000 звезд собирал аж 4.5 месяца. Но потом, что-то случилось — и около 1 июня что-то включилось, и сейчас репозиторию прилетает порядка 1900 звезд в день. Я бы сказал, что это не так подозрительно, но все равно подозрительно. Хотя может, и был какой-то инфоповод. Я не нашел.

Послесловие

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

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

На этом все. Спасибо, что дочитали до конца.

Мне нравится делать подобные исследования вместе с моим другом @sagos95 — так что подписывайтесь на наш телеграм-канальчик, где мы порой публикуем подобные исследования.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.У репы 50k звёзд. Как поступишь?0%Беру не глядя – 50 тысяч человек не могут ошибаться!020%Ставлю, но сначала гляну issues и код160%Звёзды давно игнорю, смотрю только на суть320%Вижу график роста звезд – сразу в бан!1 Проголосовали 5 пользователей. Воздержались 3 пользователя.

Источник: habr.com