billion-context: сжатие истории кодинг-агента, длинные сессии и экономия токенов — обзор и гайд

billion-context: как сохранить длинную сессию кодинг-агента и не утонуть в токенах

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

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

Чем это отличается от встроенного сжатия

Почти у каждого агента есть автосжатие истории, но обычно это односторонняя операция: старые сообщения заменяются одним коротким пересказом, и вернуться к точным деталям уже нельзя. billion-context строит сжатие иначе:

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

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

Схема простая: клиент отправляет запросы не в API провайдера, а на локальный адрес прокси.

Агент (Claude Code / Codex / Cursor / Aider ...)
      │  baseURL указывает на прокси
      ▼
billion-context  1. разбирает запрос (формат Anthropic или OpenAI)
                 2. сжимает отработанную часть диалога
                 3. добавляет инструменты управления контекстом
                 4. отправляет запрос в настоящий API модели
                 5. переписывает потоковый ответ обратно клиенту
      ▼
API модели (Anthropic / OpenAI / совместимые)

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

compress — свернуть диапазон сообщений в подробный конспект;
decompress — вернуть сжатый диапазон, если снова нужны точные детали;
search_context — поиск по ключевым словам среди конспектов и видимых сообщений;
acp_status — сводка по занятому контексту и по тому, что ещё можно сжать.

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

Где это помогает на практике

Долгий рефакторинг. Агент часами ходит по модулям; в контексте остаются решения и текущие файлы, а не вся переписка.
Большие логи и вывод тестов. Шум сворачивается в конспект, а конкретный фрагмент при нужде возвращается через decompress или находится поиском.
Экономия на токенах. По заявлению авторов, в сравнении с полным контекстом расход в независимых сессиях падает на 70% и более; на длинных прогонах разрыв растёт.
Слабый интернет и малые окна. Сессия укладывается в 100k токенов контекста, что позволяет работать на моделях с небольшим окном.

Цифры из независимых сравнений

В репозитории лежит отчёт с прогоном на 1 500 задачах из трёх наборов — LongMemEval-S, ContextBench и MemoryAgentBench — против полного контекста и трёх вариантов RAG (BM25, эмбеддинги, эмбеддинги с реранкером).

Набор	Результат billion-context	Сравнение
ContextBench	Utilized F1 0.3097, первое место	−58,3% стоимости к полному контексту
LongMemEval-S	79,20%	+16,6% к лучшему RAG, −71,1% стоимости
MemoryAgentBench (1,48 млн токенов)	100% выживаемость	сжатие около 30×, полный контекст не проходит 199 из 199 задач

Отдельно авторы измеряют цену самого сжатия: по их данным, накладные расходы держатся в пределах 2%, а здоровые сессии попадают в кеш на 95–97%. Посмотреть свою статистику можно отчётом /acp-cache прямо в клиенте.

Установка и запуск

Ставится через npm, без root и правок глобальных конфигов:

npm install -g billion-context --prefix=~/.local

Команда bili окажется в ~/.local/bin. Дальше три варианта подключения:

Плагин внутри клиента: bili plugin install pi, bili plugin install opencode, bili plugin install omp, bili plugin install dsh, bili plugin install kimi, bili plugin install hermes. Клиент запускается как обычно.
Лаунчер: bili claude, bili codex, bili pi, bili opencode и другие — прокси и клиент поднимаются вместе, конфиги не меняются.
Смена адреса API: добавить к baseURL клиента адрес прокси и префикс /bili/. Работает с любым клиентом, где можно поменять baseURL.

Ручной запуск прокси — bili start на порту 8787. Для проверки есть http://localhost:8787/__bili/health (прокси поднят и куда ходит) и http://localhost:8787/__bili/stats (статистика живой сессии). Есть Dockerfile и флаг --host для работы с удалёнными агентами.

Поддерживаемые клиенты

В README перечислены Claude Code, Codex, Pi, OpenCode (1.x и 2.x), omp, dsh, Kimi Code, Hermes, ZCode, семейство Gemini (Gemini CLI, iFlow, Qwen Code, Antigravity), Cursor, Aider, Copilot, Amp, Goose и ещё несколько. Для части из них есть нативный плагин, для остальных — лаунчер или смена адреса API. Подробности по каждому клиенту собраны в CLIENTS.md: как цепляется, что пишет в конфиг, какие есть ограничения.

Ограничения и на что смотреть

Проект ранний. В статусе прямо написано: протокол и сжатие проверены на мок-тестах (500+), интеграция с реальными моделями — следующий этап. Возможны шероховатости.
Не все клиенты сжимаются. Клиенты, которые работают через blind CONNECT-туннель, прокси не видит; незнакомые эндпоинты уходят напрямую.
Своя лицензия. MIT плюс дополнительное условие: продукт или сервис, где пользователи видят работу этого софта, должен указывать, что использует billion-context, со ссылкой на репозиторий. Для личного использования это не мешает, но при встраивании в свой продукт условие нужно учесть.
Локальный прокси — это точка, через которую идут запросы. Данные не уходят третьим лицам, но сам прокси нужно держать обновлённым: в README упомянуты принудительные обновления при критических дефектах.

Итог

billion-context — практичный способ продлить жизнь длинной сессии агента, не теряя деталей задачи. Он не пытается заменить память агента, а аккуратно разгружает контекст: свернуть, при необходимости вернуть, найти по слову и не сломать кеш провайдера. Для работы с крупными репозиториями и долгими задачами это заметно дешевле полного контекста, особенно если вы платите за токены. Если проект ещё сырой — начинать стоит с лаунчера на одной сессии и смотреть на отчёты /acp-cache.

Репозиторий: github.com/ranxianglei/billion-context