rtok в сравнении с альтернативами

Каждый названный здесь инструмент реален, полезен и был измерен до того, как был написан rtok. Исходный обзор — 19 репозиториев, метаданные GitHub API, 27 проверенных заявлений вендоров, 17 локальных транскриптов сессий — находится в research.md §4–§7. Эта страница — прочтение этого обзора: что каждая категория делает хорошо, что rtok делает иначе и какие из заявлений rtok подкреплены строкой в базе данных, а не README.

Дата обзора — 2026-09-01, обновлён 2026-09-04/09/10 (бенчмарк режимов). Число звёзд и версии меняются; механизмы — нет.

1. Если коротко

Десять инструментов, каждый из которых сжимает свой кусочек контекста, установленные на одной машине, образуют набор, который никто не измеряет от начала до конца. Собственная машина автора до rtok: 88 записей хуков на 16 событиях, девять MCP-серверов, ~8 600 токенов описаний инструментов, оплачиваемых на каждом ходу, и два прокси в цепочке. Каждый из этих инструментов сообщал об экономии. Счёт не сдвинулся, потому что ни один счётчик не охватывал весь путь.

rtok — противоположная ставка: один бинарник, один журнал, одно число. Десять методов живут как плагины за одним трейтом, они делят один файл SQLite, и экономии, которая не является строкой в measurements, не существует — включая экономию самого rtok, поэтому таблица A/B в README сейчас состоит из нулей, а не из маркетинговой цифры.

2. Что каждая категория делает хорошо

Фильтры вывода команд — rtk

~80 написанных вручную фильтров, которые сжимают git status, cargo test, npm и им подобные, подключённых к PreToolUse. Идея верна, и rtok её копирует: вывод Bash составлял 35 % токенов результатов инструментов автора (1.00 M из 2.83 M).

Две проблемы. Он отбрасывает строки без возможности их вернуть, а единственное независимое его измерение — от JetBrains — показало эффект от +7.6 % до 0 % на агентной работе при заявленных 60–90 %. Плагин cmd в rtok сохраняет фильтрацию (TOML-правила для каждого семейства плюс форматтеры для cargo, git, тест-раннеров, tree и таблиц контейнеров) и добавляет две недостающие вещи: сырой вывод попадает в ~/.rtok/archive/<id> до того, как что-либо будет вырезано, а количество байтов до/после попадает в measurements.

Фильтры вывода команд — sqz

Та же идея на Rust (github.com/ojuschugh1/sqz; ELv2; 625 звёзд на 2026-09-18), с 45+ форматтерами, дедупликацией по хешу содержимого, которая возвращает 13-токенный §ref:HASH§ для байтов, уже встречавшихся в сессии, удалением null из JSON, схлопыванием выравнивания столбцов и безопасным режимом, который пропускает трассировки стека целиком. Без потерь, как и rtok (sqz expand). Его числа заявлены им самим (README: в среднем 24.7 % по 3,003 сжатиям). По сравнению с rtok: дедупликация по хешу содержимого, проходы по JSON и таблицам и защита трассировок — пробелы (research.md §11 → T65.1–T65.4); rtok строит ключ дедупликации по входу вызова (guard), измеряет каждую обрезку в один журнал и запускает тот же набор плагинов через интерфейсы прокси и MCP, которых у sqz нет.

MCP-серверы чтения, поиска и оболочки — lean-ctx, token-optimizer

Ограниченные чтения, режимы outline, дедупликация повторных чтений, компактные деревья каталогов. Тоже верно, тоже скопировано: read поставляет 3 MCP-инструмента с 4 режимами чтения и таблицей read_cache.

Стоимость, которую эти инструменты не учитывают, — их собственное присутствие. lean-ctx внедряет ~3.1 K токенов баннера и инструкций на каждый ход; token-optimizer устанавливает 27 хуков на Python, и полная цепочка событий на этой машине запускает до ~30 подпроцессов. И то и другое оплачивается на каждом ходу, закешировано или нет, читает агент файл или нет. Весь бюджет внедрения rtok — 800 токенов на ход, побайтно стабильных, поэтому он никогда не сбрасывает кеш промпта.

Сжимающие прокси — headroom, caveman, bifrost

Прокси — единственный интерфейс, который может переписать то, что уже есть в разговоре, а согласованная с кешем живая зона headroom — самая острая идея в этой области: сжимать хвост, оставляя закешированный префикс побайтно идентичным. Плагин archive в rtok реализует тот же инвариант, а proxy записывает usage провайдера как истину в последней инстанции.

Измерено против их заявлений: headroom заявляет до 95 %, собственный счётчик автора показал 11.3 % за 30 дней; caveman заявляет 65 %, JetBrains намерили 8.5 % на агентной работе, а его issue #112 портит inline-код. Семантический кеш bifrost — категориальная ошибка для агентов программирования: контексты агентов никогда не повторяются, поэтому попадание в кеш означает неверный ответ.

Графы кода — serena, codegraph, code-review-graph, codebase-memory-mcp, graphify

Спросить «кто это вызывает» вместо того, чтобы грепать и читать пять файлов. Лучшие из них очень хороши: LSP-бэкенд serena даёт самое точное из доступных разрешений символов, а анализ влияния в code-review-graph действительно остроумен.

Их стоимость — список инструментов. Измерено через rtok doctor 2026-09-09 — все MCP-серверы на машине автора, не только графы кода:

Строка rtok заново измерена через rtok doctor 2026-09-18, после того как explore вошёл в интерфейс графа; остальные строки — замер 2026-09-09.

Этот столбец — не разовая плата: он повторно отправляется с каждым запросом каждой сессии. Два из этих серверов вместе стоят за ход больше, чем весь бюджет внедрения rtok. graph отвечает на symbol / callers / impact / outline / explore / graph_diff / graph_export за 165 токенов описаний (cargo nextest run -p rtok graph_surface, 2026-10-10).

Компромисс, однако, реален, и §5 его называет: serena разрешает ссылки, которые индекс tree-sitter tags в rtok пропускает.

Бенчмарк с графом и без него теперь есть (rtok bench --suite graph, bench/graph.toml, T68.9). Пробный запуск 2026-09-18: rtok bench --suite graph --runs 1 --dry-run (12 вопросов × 3 репозитория × mcp/native, без трат на API). Живых чисел пока нет; заявления вендоров «с/без» ждут в §5 рядом с собственной строкой rtok.

Память — claude-mem, engram, mem0

Заметки, которые переживают компакцию. claude-mem извлекает их с помощью LLM, что стоит токенов ради построения того, что экономит токены; mem0 требует Docker и векторную базу данных. memory в rtok — это заметки, которые пишет агент, в SQLite FTS5 с постепенным раскрытием — заголовки, затем id, затем тела, и никогда тела при SessionStart, — за 3 инструмента и без вызовов модели. Ближе всего по дизайну graymatter — один бинарник на Go, MCP плюс хуки Claude Code, LLM не требуется, — и он добавляет надгробия (tombstones), затухание и закрепление. Собственный бенчмарк rtok «посадить и вспомнить» — tests/memory_bench.rs (2026-09-18, research.md §14): FTS5 и гибрид P29 — 20/20 на 1/10/30/100 сессиях, заменённые записи возвращены 0 раз, SessionStart — 100 байт против 371 866 байт при полном внедрении живых тел при N=100. Никогда не 83 % graymatter.

engram был заново прочитан по функциям 2026-09-18 (research.md §13). Две его идеи подходят для ветки rtok без LLM и были приняты: ключи тем — одна строка на развивающуюся тему, что rtok делает как upsert по проекту + виду + заголовку без нового столбца, — и переносимый экспорт, который читает его собственный import. Его оценка связей (mem_judge, mem_compare, mem_review), обязательная сводка в конце сессии и пассивный захват собственных ## Key Learnings модели приняты не были: каждый из них тратит выходные токены модели на учёт, а столбец описаний из 18 инструментов выше — цена того, чтобы нести их на каждом ходу.

Уровень промпта — ponytail, сжатые режимы

Самый дешёвый рычаг в этой области, потому что выходные токены составляют 20 % счёта (research.md §9.3, 2026-09-17) на стандартных моделях и 39 % на Fable/Mythos 5.1, по тому же источнику, где чтение из кеша стоит 0.025×. Собственный бенчмарк ponytail заявляет −54 % LOC и −22 % токенов; независимой проверки нет. caveman заявляет сжатие вывода на 65 %; JetBrains намерили 8.5 % на агентной работе, а issue #112 портил inline-код.

rtok поставляет те же идеи как необязательные режимы промпта (rtok agents install claude --mode terse,yagni, псевдонимы cave/pony) плюс нативные хелперы в src/modes/ — а не обёртку над каким-либо из этих инструментов (D6). Режимы — это данные markdown в modes/, внедряемые один раз за сессию в пределах общего бюджета в 800 токенов (D7); измеренные размеры режимов 2026-09-10: terse — 162 оценочных токена, yagni — 145 (предел 250 для каждого).

Структурированное A/B-сравнение с честными слабыми базами (cargo test --test mode_bench -- --nocapture, 2026-09-10; полное описание в подразделе о режимах в research.md):

Это бенчмарки на фикстурах, а не изменение живого счёта — то же правило честности, что и для нулей A/B в README. Они показывают, что нативный путь обходит слабые базы, которые мы можем перезапускать в CI; они не заменяют сквозной rtok bench с провайдером.

Форматы — TOON, LLMLingua-2

−42.6 % у TOON на табличном JSON — бенчмарк вендора, который прошёл проверку фактов, поэтому в rtok есть плагин toon — включённый по умолчанию, и он переписывает блок, только когда TOON меньше, потому что большинство данных агентов — не таблицы. LLMLingua-2 отсекает токены с помощью небольшой модели; на коде это риск для качества без измеренной выгоды, поэтому это v0.2+ в лучшем случае.

Сама платформа — кеширование промптов, редактирование контекста, автокомпакция

Бесплатно, от самого провайдера, и именно с этим на самом деле конкурируют все инструменты выше. Измеренная доля попаданий и разбор по интерфейсам: prompt-cache.md. Правильный ход — согласовываться с ним, а не бороться: побайтно стабильное внедрение и сохраняющие кеш переписывания в прокси в rtok существуют именно поэтому.

3. Чем rtok отличается

4. Преимущества и доказательства

1. Список инструментов — тоже контекст. 11 инструментов за ~143 токена описаний против 30 инструментов за ~2 295 в одном конкурирующем сервере. Источник: rtok doctor, 2026-09-09.
2. Ничего не теряется. cmd, read и archive записывают сырые данные в ~/.rtok/archive/<id> до сокращения; rtok expand <id> возвращает их, с --lines и --grep. rtk просто выбрасывает строки.
3. Экономия — это строка, иначе её нет. Ctx::record(&Measurement) — единственный способ для плагина заявить экономию, а rtok stats --plugin <id> её печатает. Прокси записывает usage, о котором сообщает провайдер, — это реальный счёт, а не оценка «символы/4».
4. Он признаёт то, чего не доказал. Закоммиченный A/B-бенчмарк запускался офлайн и показывает нули; README так и говорит. Набор тестов графа с/без (rtok bench --suite graph --dry-run, 2026-09-18) печатает расписание и ни одного доллара. Каждое число вендора из §2, которое было проверено независимо, оказалось в 5–10 раз ниже заявленного.
5. Он не может сломать вашего агента. Хук завершается с кодом 0 и неизменённым вводом при любой ошибке или панике, в пределах 10 мс. Наполовину установленный или падающий rtok — это no-op, а не сбой.
6. Он не борется с кешем. Внедрения укладываются в бюджет и побайтно стабильны между ходами; прокси никогда не переписывает системные инструкции, определения инструментов или самые новые результаты инструментов. При доле попаданий 97.5 %, измеренной в docs/prompt-cache.md (2026-09-18), сброс префикса стоит больше, чем экономит любой фильтр.
7. Три интерфейса, потому что одного недостаточно. PostToolUse не может изменить результат инструмента — проверено по документации хуков, — поэтому для сжатия того, что уже в контексте, нужен прокси, а для замены инструмента — MCP. У инструментов с одним интерфейсом есть потолок, который является свойством хоста, а не их кода.
8. Одна конфигурация с происхождением значений. Каждый флаг — это ключ конфигурации; rtok config show --sources называет уровень, из которого пришло каждое значение. Ни один инструмент из обзора не может ответить на этот вопрос.
9. Обратимая установка. rtok agents install claude --dry-run печатает точные правки, настоящий запуск делает резервную копию файла настроек перед записью, а rtok agents uninstall claude убирает хуки, регистрацию MCP и переменную прокси (чужие записи остаются).
10. Ваш журнал — в вашем стеке наблюдаемости. rtok otel flush проецирует вызовы, логи и метрики в OTLP/HTTP JSON — проверено с Jaeger 2.11 и Grafana otel-lgtm, а также с независимым валидатором, который заново реализует спецификацию. Стоимость при настроенном endpoint: +0.81 мс p95 на пути хука (research.md, Gate P16, 2026-09-04).

5. Где rtok отстаёт

Прямо, потому что §4 стоит читать, только если существует этот раздел.

• Живого сквозного выигрыша в стоимости не продемонстрировано. Обвязка A/B и набор тестов графа с/без (rtok bench --suite graph) работают; ни то ни другое не запускалось против живого счёта API (живая часть T68.9 открыта). Пока этого не сделано, собственное заявление rtok — «измеримо», а не «дешевле», и цифры вендоров 88 % / 62 % остаются рядом с пустой строкой rtok.
• graph находит каждое определение и пропускает большинство ссылок. Полнота и точность для определений — 1.000 на вручную размеченном наборе из 30 символов; полнота для ссылок — 0.351, потому что запрос tree-sitter tags не захватывает позиции типов и тела макросов. LSP-бэкенд serena здесь точнее. LSP-бэкенд для graph — это v0.2.
• Нет сжатия через LLM, нет эмбеддингов, нет семантического поиска. claude-mem и mem0 умеют это уже сегодня. В rtok это v0.2+ и обусловлено тем, что в бенчмарке нужно обойти путь без потерь.
• Поиск в memory — это пять самых новых заголовков, без ранжирования по давности. Жизненный цикл (retire / supersede / pin) появился в T69.1. Бенчмарк «посадить и вспомнить» (T69.3, research.md §14) даёт 20/20 для FTS5 и гибрида P29 при N=100 на этом генераторе; ранжирование half_life_days не было выпущено (T69.2), поэтому эта строка — N/A. Никогда не приводите 83 % graymatter как результат rtok.
• Библиотека фильтров меньше, чем у rtk и sqz. 28 семейств правил в rules/default.toml плюс десять форматтеров для отдельных семейств против ~80 фильтров rtk и 45+ у sqz (research.md §11; дедупликация по хешу содержимого T65.1, компактный JSON T65.2 и схлопывание столбцов T65.3 уже внедрены — сама библиотека всё равно наименьшая из трёх).
• Пока нет наблюдения за Batch, Flex prepare и маршрутизатора моделей. Пути Batch провайдеров уже проходят через fallback прокси; внедрение service_tier для Flex и маршрутизация D9 запланированы (docs/batch-flex.md). bifrost, Portkey и LiteLLM поставляют маршрутизаторы уже сегодня.
• Моложе, и мейнтейнер один. У нескольких инструментов из §2 пятизначное число звёзд и годы учтённых пограничных случаев. rtok — на версии v0.0.1.
• toon включается явно, потому что не прошёл свою проверку на этой машине. LadybugDB и Grafeo были измерены, а затем удалены (P39, 2026-09-12): Ladybug выиграл impact на глубине 4 в 77 раз, но не уложился в планку хука ≤10 мс; от Grafeo отказались после того, как тёплый impact(2) оказался ~в 22 000 раз медленнее SQLite. Индекс символов — только SQLite.

Шлюзы Batch, Flex и маршрутизации

rtok — промежуточный слой для сокращения токенов с локальным прокси; bifrost, Portkey и LiteLLM — прежде всего продукты маршрутизации / шлюзы. Batch (асинхронные API провайдеров), Flex (service_tier) и маршрутизация моделей — разные рычаги; rtok документирует их в batch-flex.md и не преобразует автоматически синхронные ходы агента в задания Batch.

Чем rtok остаётся отличным: измерение в одном журнале SQLite, сжатие со стабильными для кеша байтами и хуки/MCP, которые никогда не видят HTTP-путь LLM. Где он отстаёт: bifrost/Portkey/LiteLLM уже поставляют маршрутизаторы для продакшена; наблюдение за Batch, Flex prepare и маршрутизация D9 в rtok всё ещё пункты бэклога в ideas.md (I-100/I-101).

6. Проверьте всё сами

rtok doctor                       # ваши хуки, MCP-серверы и стоимость их токенов описаний
rtok plugins                      # что включено и на каком интерфейсе
rtok stats --since 7d             # оценки по транскриптам плюс usage провайдера
rtok stats --save-baseline before # затем что-нибудь измените, затем --compare before
rtok bench --dry-run              # расписание A/B, которое должно обойти базу
rtok expand <id>                  # оригинал всего, что сократил rtok

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

7. Когда не стоит использовать rtok

• Вам нужно самое точное из доступных разрешение символов, и вас не смущают описания 22 инструментов на каждом ходу — используйте serena.
• Вам нужна большая зрелая библиотека фильтров для вывода оболочки, и вы готовы мириться с обрезкой с потерями — используйте rtk.
• Вам уже сегодня нужна память, извлекаемая LLM, или векторный поиск — используйте claude-mem или mem0.
• Вы на тарифе, где токены не являются ограничением. Тогда ничто из этого не окупается, включая rtok.