Две последние строки показательны: код и результаты поиска проходят нетронутыми. На отдельном тесте качества критическая ошибка находилась правильно при сокращении входа с 10 144 до 1260 токенов, а ответы на четыре проверочных вопроса остались верными все четыре. Публикуются и замеры задержки: само сжатие больших сценариев занимает сотни миллисекунд или секунды, но за счёт уменьшения предобработки на стороне модели авторы получили положительный баланс в 11 сценариях из 12.
Теперь о цифрах, которые попадают в заголовки, и о том, насколько им можно верить.
60-95% на JSON - подтверждается направлением замеров: на больших массивах опубликованы 83-91%, структурированные логи заходят выше 90%.
15-20% для агентов с кодом - заявление README. Это уже сквозной ориентир, а не замер отдельного компрессора, и реальный процент зависит от доли машинного вывода против кода и запросов пользователя.
"Ответы те же" - формулировка слишком широкая. Проект показывает конкретные проверки точности, но ни одна схема сжатия с потерями не может гарантировать одинаковое качество на всех неизвестных задачах.
Сжатие для RAG - документация расходится: введение говорит о результатах RAG как о цели, а раздел ограничений указывает документы RAG как проходящие без изменений.
40-70% на коде - только при активном сжатии через дерево. Предохранители по умолчанию часто оставляют код нетронутым.
Ограничения и безопасность
Короткие разговоры почти не выигрывают: в ограничениях приводится медиана около 4.8% для коротких обменов репликами. На одном вопросе без инструментов Headroom просто не с чем работать.
Код защищается именно тогда, когда он нужен - при отладке, ревью и починке. Это снижает экономию, но защищает правильность, и для агента, работающего с кодом, это скорее плюс.
Сжатие может добавить задержку, особенно на обычном тексте через модель. Выигрыш считается по всей цепочке, а не внутри компрессора.
Сжимается далеко не всё: короткое содержимое, некорректный JSON, маленькие массивы, системные промпты и уже компактные блоки проходят как есть.
И отдельно - часть документации противоречит сама себе. Диапазоны для текста, поведение RAG и сжатие кода описаны по-разному на разных страницах. Проект развивается быстро, поэтому для production стоит фиксировать конкретную версию и проверять на своей нагрузке.
По безопасности картина такая. Headroom позиционируется как локальный: в режиме прокси содержимое обрабатывается на вашей машине, а затем уходит тому поставщику, к которому вы и так обращаетесь; хранилище CCR тоже локальное. Но прокси стоит в крайне чувствительной точке - через него проходят промпты, результаты инструментов, учётные данные в заголовках и потенциально приватный код. Поэтому относиться к нему нужно как к части доверенной вычислительной базы: ставить из официального репозитория, не выставлять наружу без необходимости, контролировать хранилище CCR, читать заметки к выпускам перед обновлением и фиксировать версию вместо слепого обновления до последней.
Аргумент в пользу такой осторожности есть прямо в истории проекта: в 0.34.0 среди исправлений - обновления зависимостей aiohttp и cryptography по соображениям безопасности, а в соседних выпусках менялось поведение CORS и транспорта. И ещё раз про рассинхрон: политика безопасности в репозитории всё ещё перечисляет 0.27.x как поддерживаемую последнюю версию, так что ориентироваться надо на выпуски.
Headroom против pxpipe: цель одна, механика разная
