RTK обещает экономию токенов, но бенчмарки Quesma не подтверждают снижение затрат
RTK reports token savings, but our cost benchmarks disagree
RTK (Rust Token Killer) сжимает вывод терминала перед тем, как его прочитает AI-агент, и рекламируется как способ сократить расходы на AI-кодинг. Quesma потратила более $1500 на токены и прогнала 1740 попыток на Terminal-Bench 2.1 с Claude Code + Fable 5.0 и OpenCode + DeepSeek V4 Pro 0813. У Fable экономия 5% объясняется одной задачей, у DeepSeek затраты выросли на 5–17%. Метрика rtk gain считает удалённые байты, а не сэкономленные деньги.
RTK сокращает до 90% вывода bash, который читает ваш агент. […] это не то же самое, что сократить ваш счёт на 90%.
- aeneas_ory
Все эти «хаки» — шарлатанство, и, думаю, в глубине души мы все это знаем. Неважно, caveman это, RTK или какой-нибудь другой вайб-кодинг-хак/скилл/claude.md для экономии токенов или повышения продуктивности.
Что у меня сработало (хотя бенчмарки уже устарели) — это индексация кодовой базы с помощью выделенной локальной модели эмбеддингов кода. По CPU это довольно дорого, но в моих бенчмарках это значительно снизило расход токенов и реальное время. Конечно, всё всегда зависит от статистического шума и загрузки хост-системы, а запускать достаточно масштабные бенчмарки просто слишком дорого, так что относитесь к ним скептически.
Почему это работает, спросите вы? Ну, LLM по сути перебирают слова/фразы и скармливают это в find/grep/pgrep/что угодно (или, как недавно обсуждалось здесь, пишут для этого python-скрипт — https://news.ycombinator.com/item?id=49654229). Семантический поиск ищет сходства, так что перебирать приходится меньше. Но за это, конечно, приходится платить предварительной индексацией всего.
Проект можно найти здесь: https://github.com/ory/lumen
- ProjectBarks
Похоже, большинство этих инструментов — в основном пар. Бенчмарки, сделанные на Headroom и RTK, показывают, что ни один из них не даёт реальной экономии. Если бы можно было получить такой простой шаг предобработки, почему бы AI-лаборатории сами не внедрили эти оптимизации на своей стороне?
Моё предположение: они в основном не работают или делают поведение модели гораздо более запутанным. Я действительно считаю, что нужен какой-то независимый бенчмарк.
Вот другие случаи, демонстрирующие точно такие же проблемы с подобными инструментами:
https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-...
https://brandonbarker.me/writing/headroom-fewer-tokens-bigge...
- oefrha
Это совершенно очевидно любому, кто хоть раз удосужился посмотреть на вывод rtk gain, никакой бенчмарк вообще не нужен. Агент запускает
rtk command-that-prints-100k-tokens | tail -5
стоит 5 строк, может быть, 100 токенов без rtk, но rtk отчитается об экономии в 100k. Конечно, он не знает про этот tail -5.
Хуже того, поскольку rtk по умолчанию сохраняет эту статистику экономии, это ломает песочницу. Префикс rtk также время от времени приводит к случайным отказам в auto-режиме (это не зависит от отключения сохранения статистики экономии).
Честно говоря, понятия не имею, почему кто-то, кто хоть немного разбирается в CLI, воспринимает rtk gain всерьёз. Полагаю, ничего не понимающие вайб-кодеры, которые почти никогда не работали в терминале, посмотрят на эту статистику и почувствуют себя хорошо?
Тем не менее, rtk всё ещё слегка полезен для сжатия повторяющихся выводов тестовых прогонов и тому подобного, но использовать его следует только для команд из белого списка; оборачивать всё, как они предлагают, — просто глупо.
- gillesjacobs
Главный вывод:
Средняя стоимость попытки, без → с RTK:
Claude/Fable: $1.72 → $1.64 (~5% дешевле)
DeepSeek: $0.115 → $0.121 (~5% дороже)
Почти вся экономия на Claude пришлась на одну задачу.
Без неё экономия была меньше 1%.
Мне потребовалось несколько раз перечитать, чтобы разобрать эту верхнюю строчку.
Эта статья действительно прячет главное в самом конце.
- fg137
Рад видеть, что всё больше людей понимают: это просто шарлатанство. Без объективных метрик вроде бенчмарков все эти заявления ничего не значат.
То же самое я чувствую насчёт скиллов/плагинов. Хотя некоторые дают важный контекст для конкретных проектов/окружений, я очень скептически отношусь к (сверх)обобщённым скиллам вроде «написание JS-тестов» или «создание спецификации». В моей компании есть десятки таких скиллов, но я не видел ни одного бенчмарка, который показывал бы, что хоть один из них значимо (то есть статистически значимо) лучше, чем просто обычные промпты в одно предложение.