[ENHANCEMENT] I saved 10M tokens (89%) on my Claude Code sessions with a CLI proxy

[muskiness]

Problem (one or two sentences)

CLI commands executed by the LLM (like cargo test, git status, npm install) produce verbose output that floods the context window with noise — passing tests, progress bars, redundant formatting. This wastes massive amounts of tokens (up to 89% according to real-world measurements) and degrades reasoning quality.

Context (who is affected and when)

Every user who relies on terminal commands during AI-assisted coding sessions is affected. It's especially painful in projects with large test suites, monorepos, or frequent git/build/package-manager operations — the LLM receives hundreds of irrelevant lines per command, burning tokens and pushing useful context out of the window.

Desired behavior (conceptual, not technical)

Command output should be automatically filtered and compressed before reaching the LLM context. For example, instead of 155 lines of test output, the model should see a compact summary like "47 passed, 2 failed" with only the failure details. This should work out-of-the-box for common tools (git, npm, cargo, pip, test runners) with sensible defaults, be toggleable per session, and allow users to define custom filtering rules for their own commands. Inspired by the RTK project (https://github.com/rtk-ai/rtk) which demonstrated ~10M tokens saved (89% reduction) over two weeks.

Constraints / preferences (optional)

Feature Request: Built-in CLI output filtering/compression to reduce token usage (inspired by RTK)

Hey team! 👋

I recently came across an interesting project called [RTK (Rust Token Killer)](https://github.com/rtk-ai/rtk) — a CLI proxy that filters and compresses command output before it reaches the LLM context. The author shared their results on [Reddit](https://www.reddit.com/r/ClaudeAI/comments/1r2tt7q/i_saved_10m_tokens_89_on_my_claude_code_sessions/), and the numbers are impressive:

• cargo test: 155 lines → 3 lines (98% reduction)
• git status: 119 chars → 28 chars (76% reduction)
• git log: compact summaries instead of full output
• Total savings over 2 weeks: ~10M tokens (89%)

The core idea is simple: most CLI output sent to the LLM is noise — passing tests, verbose logs, progress bars, redundant formatting. Stripping that out before it hits the context window saves a massive amount of tokens without losing any useful information.

Why this would be valuable as a built-in feature in your project:

1. Users wouldn't need to install and configure a separate tool
2. Filtering rules could be context-aware and tightly integrated with your existing command execution pipeline
3. It directly reduces costs and improves response quality (less noise = better reasoning)
4. It could be opt-in with sensible defaults

Possible implementation scope:

• Configurable output filters for common commands (git, npm, cargo, pip, test runners, etc.)
• Smart truncation with summary (e.g., "47 tests passed, 2 failed" instead of full test output)
• User-defined rules for custom commands
• Toggle on/off per session or globally

I think this kind of optimization would be a huge quality-of-life improvement for users and a natural fit for your tool. Would love to hear your thoughts on whether this is something you'd consider exploring!

References:

• RTK repo: https://github.com/rtk-ai/rtk
• RTK site: https://www.rtk-ai.app
• Reddit discussion: https://www.reddit.com/r/ClaudeAI/comments/1r2tt7q/

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and explored the codebase to understand the terminal output pipeline. Here's my proposed implementation plan:

Current Architecture

Terminal command output flows through:

1. ExecuteCommandTool -> executeCommandInTerminal() which captures output via callbacks
2. OutputInterceptor handles large output with a head/tail buffer + disk spill strategy
3. compressTerminalOutput() applies run-length encoding and truncation for UI display
4. The LLM sees either inline output (small) or a persisted head/tail preview (large via terminalOutputPreviewSize)

There is currently no semantic/command-aware filtering -- the existing compression is purely structural (line limits, character limits, RLE for repeated lines). This means verbose test suites, git logs, npm install output, etc. all hit the LLM context at full size (up to the preview budget).

Proposed Implementation

1. New TerminalOutputFilter module (src/integrations/terminal/TerminalOutputFilter.ts)

A filter engine with pluggable, command-aware rules. Each rule would:

• Match against the command string (e.g., /^(cargo |npm |npx )?test/, /^git (status|log|diff)/)
• Transform the output into a compact summary while preserving actionable information (errors, failures)

Built-in filters for common commands:

• Test runners (jest, vitest, cargo test, pytest, go test, mocha): Extract pass/fail counts, show only failure details
• git status: Compact file-change summary
• git log: Reduce to one-line-per-commit format
• npm/yarn/pnpm install: Strip progress bars, show only warnings/errors + final summary
• Build tools (cargo build, tsc, webpack): Strip progress, keep errors/warnings

2. Integration point in ExecuteCommandTool.ts

Apply the filter at the point where output is formatted for the LLM tool result (lines ~389-424 in ExecuteCommandTool.ts). The filter would run on the final result string before it's returned to the LLM, and also in OutputInterceptor.finalize() for large outputs.

3. New setting: terminalOutputFilterEnabled (boolean, default: true)

• Stored in GlobalSettings (in packages/types/src/global-settings.ts)
• Togglable in the Settings UI under the existing Terminal section
• When enabled, command output is filtered before reaching the LLM
• When disabled, existing behavior is preserved

4. User-defined custom filter rules setting

• New setting terminalOutputFilterRules -- an array of { pattern: string, replacement: string } objects
• Users can define regex patterns that match output lines to strip or transform
• Applied after built-in filters

5. Filter bypass indicator

• When a filter is applied, append a note to the tool result like: [Output filtered: 155 lines -> 3 lines. Use read_command_output for full output.]
• This ensures the LLM knows filtering occurred and can access full output if needed

Files to modify/create

• Create: src/integrations/terminal/TerminalOutputFilter.ts -- filter engine + built-in rules
• Create: src/integrations/terminal/__tests__/TerminalOutputFilter.spec.ts -- tests
• Modify: src/core/tools/ExecuteCommandTool.ts -- apply filter before returning output to LLM
• Modify: packages/types/src/global-settings.ts -- add new settings
• Modify: webview-ui/src/components/settings/TerminalSettings.tsx -- add toggle + custom rules UI

Scope / trade-offs

• Phase 1 (this PR): Built-in filters for the most impactful commands (test runners, git, npm/yarn), the enable/disable toggle, and the filter bypass indicator
• Phase 2 (follow-up): User-defined custom rules UI, per-session toggle, and more filter patterns
• The filter runs only on the LLM-bound output, not the UI display or the persisted artifact (full output is always available via read_command_output)

This approach integrates naturally with the existing OutputInterceptor pattern and should deliver meaningful token savings (especially for test suites) without losing information.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[muskiness]

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[roomote]

Thanks for flagging this @muskiness! I have seen the comment and will proceed with implementing the plan I outlined above. I will open a draft PR to share progress shortly.

[roomote]

Opened a draft PR with my attempt at implementing Phase 1 of the terminal output filtering plan: #11472

The PR adds a new TerminalOutputFilter module with built-in command-aware filters for test runners, git, package managers, and build tools. It includes a new "Smart output filtering" toggle in Terminal Settings (enabled by default) and 20 test cases. Full output is always preserved and accessible via read_command_output -- filtering only affects what the LLM sees in its context window.

Feedback welcome!