Инструмент RTK обещает разработчикам золотую жилу: сократить расход токенов, сохранить интеллект модели и платить в десять раз меньше. Проект собрал 60 тысяч звёзд на GitHub, и индустрия явно повелась на хайп. Но в нынешней золотой лихорадке devtools, если что-то звучит слишком хорошо, чтобы быть правдой — так оно и есть.
Главная претензия — статистика «экономии 60-90%». Она глубоко вводит в заблуждение. Это не снижение счёта за LLM, а просто процент сырого вывода командной строки, который RTK отрезает. Инструмент трогает вывод Bash, но полностью игнорирует самые тяжёлые статьи расходов: глубокое чтение файлов, контекст репозитория, системные промпты и внутренние токены рассуждения самой модели. Команда rtk gain выглядит так, будто её сделали специально для скриншотов в соцсетях, а не для реальной оптимизации архитектуры.
Вторая проблема — «тихие сбои». Оптимизация бесполезна без точности. В открытых issue уже жалуются, что терминальный вывод просто молча искажается или теряется. Главная архитектурная опасность — асимметрия: AI-агент понятия не имеет, что текст сжали. Если RTK вырежет критическую строку стектрейса или контекст компилятора, вы и LLM будете действовать вслепую.
Третий вопрос: где бенчмарки точности? Маркетинг RTK показывает красивые графики сэкономленных токенов, но умалчивает о единственной важной метрике — Task Success Rate. Решил ли агент задачу в итоге? Сэкономить 80% на промпте — чистый минус, если деградация контекста заставит агента галлюцинировать, сломать сборку или зациклиться, сжигая ещё больше токенов.
С архитектурной точки зрения RTK — это хрупкая внешняя зависимость прямо в критическом синхронном пути между агентом и вашей оболочкой. Это не самостоятельный продукт, а функция. Основные CLI-инструменты (git, cargo, npm, grep) легко могут добавить нативный флаг --compact или --json-stream для LLM, и тогда главное преимущество RTK исчезнет.
Парсинг тоже ломкий. RTK сильно завязан на разбор человекочитаемых форматов stdout/stderr. Стоит git или cargo обновить форматирование на пару пробелов — и регулярки RTK сломаются. И опять — без ошибки, просто молча отдадут битый текст.
Вывод: RTK просит обменять детерминированную надёжность, полноту контекста и простоту архитектуры на понтовое сокращение сырых токенов. Пока инструмент не исправит проблему тихих сбоев и не предоставит прозрачные бенчмарки точности, ставить его в критический путь production-агента — операционный риск, который не стоит никакой скидки.