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 і таблиць та захист трейсів — це прогалини rtok (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 пошкоджує вбудований код. Семантичний кеш bifrost — категорійна помилка для агентів програмування: контексти агентів ніколи не повторюються, тож влучання в кеш — це неправильна відповідь.

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

Запитати «хто це викликає» замість grep і читання п'яти файлів. Найкращі з них дуже хороші: 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 пошкоджував вбудований код.

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 нічого не робить, а не спричиняє збій.
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, жодних embeddings, жодного семантичного пошуку. 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, prepare для Flex чи маршрутизатора моделей. Шляхи Batch провайдера вже проходять через fallback проксі; вставлення Flex service_tier і маршрутизація 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 уже постачають production-маршрутизатори; спостереження за Batch, prepare для Flex і маршрутизація D9 у rtok досі лише пункти беклогу в ideas.md (I-100/I-101).

6. Перевірте будь-що самі

rtok doctor                       # ваші хуки, MCP-сервери та їхня вартість у токенах опису
rtok plugins                      # що ввімкнено і на якому інтерфейсі
rtok stats --since 7d             # оцінки з транскриптів плюс використання від провайдера
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.