Headroom на 80 запусках агента: что получилось с расходом токенов

Недавно увидел ещё один репозиторий с обещанием резко сократить расход контекста у LLM-агентов — Headroom. Я сейчас исследую эту тему на примере SKILL.state и уже писал о первых результатах на Хабре - это были первые инженерные эксперименты; более строгие проверки ещё продолжаются.
Так что меня заинтересовал подход headroom и я решил заодно с прочими экспериментами наскоро прогнать Headroom через тот же тестовый стенд. Эта статья — о том, что получилось.

Headroom сжимает данные перед отправкой в LLM. Агент читает файлы, получает логи и результаты команд, а затем снова передаёт эту историю модели. Если сократить повторяющиеся данные, расход должен уменьшиться. Теоретически. Но что произойдёт на практике и как это повлияет на качество?

Провели две серии: десять задач Terminal-Bench 2.1 и пять небольших проектов с тремя повторами, использованных ранее для тестов skill.state. Всего — 80 попыток. По парам с полным учётом расхода у Sol на Terminal-Bench input снизился на 4,1%, на небольших проектах вырос на 40,7%. У Astra на тех же проектах снизился на 25,3%.

Разобраться в таком результате помогли сохранённые запросы до и после сжатия.

Что именно проверяли

Headroom можно поставить между агентом и провайдером модели. Библиотека обрабатывает текст, код и структурированные данные; механизм CCR сохраняет оригиналы локально, чтобы агент мог запросить их через инструмент восстановления. В README закреплённой версии приведены примеры сжатия на 21–57%, а для повторяющихся JSON и логов — более 90%. Там же оговорено: плотный текст сжимается гораздо слабее.

Использовали headroom-ai[proxy,code]==0.37.0 с локальной ONNX-моделью Kompress. Тестировали прокси со сжатием: без Serena, headroom learn, смены модели и сокращения ответов. headroom wrap не запускали, поэтому выводы относятся только к этому режиму интеграции.

У каждого задания были два варианта:

• Native: запрос проходит через прокси без изменения.

• Headroom: тот же агент и модель, но со сжатием запроса.

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

Считали результат внешних проверок, input, некешированный input, output, число обращений к модели и время агента. Input уже включает кешированные токены, output — reasoning. Токены подписки не переводили в деньги.

Первая серия: десять задач Terminal-Bench 2.1

Здесь работала gpt-5.6-sol с reasoning high: по одной попытке на задачу в каждом режиме, всего 20 запусков. Это выбранная десятка из TB2.1, не весь бенчмарк: среди задач — извлечение данных из ELF, настройка PyPI-сервера, сборка SQLite, Git webserver и редактирование большого текста.

За суммарным результатом скрывается большой разброс: у extract-elf input уменьшился на 45,4%, у pypi-server вырос на 85,6%.

Единственное расхождение по успешности — Git webserver. С Headroom агент не запустил sshd, хотя отсутствие порта 22 было видно в неизменённом выводе. Компрессор также убрал часть if/then из показанного модели shell-hook; сам файл остался целым. Связь сжатия с провалом не установлена: по одной попытке и с ограничениями оценщика такой вывод сделать нельзя.

По одной попытке на режим нельзя оценить устойчивость результата. Поэтому следующая серия уже включала повторы.

Вторая серия: пять проектов, две модели, три повтора

Взяли пять базовых задач из прежнего стенда: taskboard CLI, анализатор CSV, шаблонизатор, HTTP key-value сервер и планировщик зависимостей. Для каждой провели три повтора в обоих режимах на двух профилях:

• gpt-6-astra, reasoning medium;

• gpt-5.6-sol, reasoning high.

Получилось ещё 60 попыток. У Astra инструменты вызывались напрямую, у Sol — через code mode; внутри каждого профиля native и Headroom использовали одинаковый формат. Между собой модели здесь не ранжируем.

У двух попыток оказался неполный учёт расхода: Sol остановился на перегрузке провайдера, у Astra оборвался поток, после чего CLI переподключился и завершил работу. Неизвестные токены не заменяли нулями. Для сравнения расхода исключили обе стороны соответствующей пары — осталось по 14 полных пар на профиль.

Полным успехом считали прохождение всех внешних проверок и штатное завершение агента. Astra получила 15/15 в обоих режимах, Sol — 13/15 native против 15/15 с Headroom.

Но преимущество по качеству из этого не следует. Один native-запуск Sol прервала перегрузка, хотя код прошёл проверки. Другой потерял балл за ответ {"deleted":2} вместо поля id, которого спецификация не требовала. Дополнительная проверка подтвердила, что удаление работает; исходный балл оставили без изменений.

Повторы тоже не дают единой картины. У Astra на taskboard input снижался во всех трёх парах — на 35–45%. На HTTP KV результаты лежали между −8,9% и +25,8%. У Sol на CSV — между −44,2% и +261,7%. Три повтора помогают увидеть разброс, но набор из пяти задач от этого не становится разнообразнее.

Во второй серии были паузы из-за квоты, свободного диска и технических сбоев. После исключения пар, разделённых паузами, направление эффекта сохранилось: input Astra ниже на 22,7%, Sol выше на 53,7%. Это проверка чувствительности на меньшей выборке. Кеш провайдера не сбрасывался, локальное состояние Headroom сохранялось.

Сколько убрал сам компрессор

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

Для второго измерения сохранили полный JSON до и после прокси и посчитали его через o200k_base. Ниже — сокращение суммы локальных токенов по всем учтённым запросам Headroom в соответствующей серии:

У Astra расход входных токенов снизился на 25,3%, хотя сам Headroom сократил объём JSON всего на 0,22%. Выходных токенов тоже стало меньше — на 8,1%, а обращений к модели — на 14,4%. То есть заметное снижение расхода сопровождалось почти нулевым прямым сжатием: агент прошёл другой путь решения и реже обращался к модели.

Локальный подсчёт JSON не равен provider input: в JSON есть служебное оформление, поэтому проценты нельзя напрямую вычитать друг из друга. Но разница масштабов показывает, почему всю экономию нельзя объяснить тем, сколько текста убрал компрессор. Вызвали ли небольшие изменения контекста более короткий путь или мы видим разброс поведения модели и влияние условий запуска — пока неизвестно. Статистическую значимость и воспроизводимость этой экономии мы не установили. У Sol запросы тоже сжимались, но обращений стало больше и суммарный расход вырос.

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

Одинаковые результаты инструментов иногда сжимались по-разному при повторной передаче; у native такого не наблюдалось. Влияние на кеш провайдера не установлено. Восстановление оригиналов через CCR за все 80 попыток не вызывалось — его практическая полезность здесь осталась непроверенной.

Что из этого следует

На этих задачах универсальной экономии не получилось. Обе серии — небольшие выборки из уже знакомых задач и не претендуют на всеобъемлющий бенчмарк

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

Больше всего порадовало, что Headroom в этой серии оказался достаточно бережным: там, где сжимать почти нечего, он мало менял контекст, а Astra успешно завершила все 15 запусков в каждом режиме. Создалось впечатление, что инструмент достаточно умный, чтобы не мешать там, где он не особо нужен. Впрочем, это впечатление от конкретной серии, не забываем, что в TB2.1 был провал только с Headroom, причину которого установить не удалось.

Следующую серию хочется провести на задачах из более подходящего для сжатия домена: разборе объёмных логов, больших JSON-ответов API и повторяющихся результатов поиска. Там у компрессора будет больше материала. Интересно проверить, превратится ли заметное сжатие в устойчивую экономию за всё решение — и сохранится ли качество.