Эффект двунаправленный. В плюс: чистый, структурированный вывод — это лучший сигнал/шум, модель меньше отвлекается на ANSI-мусор и прошедшие тесты, дольше живёт до compaction. Для типовых команд (git, тесты, линтеры) качество рассуждений скорее растёт, чем падает — модель видит ровно то, что нужно для решения.

В минус: любая lossy-компрессия — это ставка на то, что фильтр правильно угадал, что важно. На 100+ поддерживаемых командах эвристики вылизаны, но на edge-cases возможна деградация: агент получает «FAILED: 2/15» без нюанса, который был в полном stack trace, и делает лишнюю итерацию. Tee-механизм это смягчает, но добавляет шаг.

Практический совет под твой контекст (внедрение LLM в департаменте): ставь себе, гоняй rtk gain пару недель, и смотри не только на tokens saved, но и на то, не выросло ли число повторных чтений/перезапусков команд у агента. Кстати, это красиво ложится в твою метрику LLM Efficiency — если rtk реально работает, median task time должен падать при том же LLM code share. exclude_commands в конфиге позволяет точечно выключать фильтры там, где они мешают. Для командного rollout — только после того, как убедишься, что фильтры не режут вывод ваших специфичных Gradle/Android-тулчейнов (Android-сборки в списке из коробки, замечу, нет — grep по README не находит gradle-фильтра, скорее всего пойдёт через generic rtk err/rtk test).