RTK v0.48.0 filters more than 100 developer commands
RTK v0.48.0 wraps more than 100 developer commands and filters their output before a coding agent sees it. Git summaries keep the changes, test runners collapse passing cases, file tools group or trim results, and log commands deduplicate repeated lines. The agent invokes commands, while a hook rewrites supported Bash calls to RTK. It targets context waste when a successful test run produces pages of output.
The design is command-specific. cargo test, git diff, pytest, docker logs, and kubectl each need different parsing, so RTK routes them through separate adapters instead of cutting every stream at the same line count. Our measured checkout contained 412 files and about 93,976 source lines. That scale explains the breadth, and it also means buyers are trusting many small parsers to track changes in the tools they wrap.
Version 0.48.0 hooks Bash, while built-in file tools bypass it
RTK v0.48.0 documents integrations for Claude Code, Codex, Copilot, Cursor, Gemini CLI, Windsurf, and several other agents. Hook-capable clients can rewrite a supported shell command before execution. Codex uses instruction files instead. Claude Code's built-in Read, Grep, and Glob calls never reach its Bash hook, so those workflows need explicit RTK file commands or ordinary shell equivalents to receive filtering.
Our 3-CPU sandbox result shows that source setup is manageable, although agent integration remains a separate local change. The recommended global initialization writes hook and instruction files, may patch an agent settings file, and requires a client restart. rtk init --show checks the installed integration. A team should inspect those files, start with a small command set, and keep exclusions for tools whose exact output feeds another program.
What happened when we ran it
Our sandbox installed commit 29f9bb7 in 24 seconds and pulled 160 packages. Our test method used an unprivileged rust:1-bookworm container with 3 CPUs, 12 GB of RAM, and no secrets. The checkout contained 412 files, about 93,976 lines of source, and occupied 4.3 MB. Installation completed without a reported failure.
The build succeeded in 64 seconds. cargo test then finished in 70 seconds with 2,704 passed and 0 failed out of 2,704 tests. The repository contained 5 CI workflow files and a tests directory. It did not contain a Dockerfile. Those are the complete install, build, and test outcomes from our run of that commit.
RTK 0.46.0 issue reports show some failed commands reading as success
Open issue #3843 reports that RTK 0.46.0 and the then-current development branch could return success after a second git diff or git show invocation failed, dropping the external driver's diagnostic. Issue #3870 reports a golangci-lint adapter that maps the tool's issues-found status to success, discards stderr on another error path, and can print "No issues found" after a hard error. Both reports remained open when checked.
The 2,704 passing tests are meaningful, yet these newer reports show why adapter compatibility needs its own acceptance set. RTK can save full output when a command fails, expose raw output at the highest verbosity, bypass filtering through rtk proxy, and exclude selected commands in configuration. Start with interactive commands where a developer can notice a strange summary. Keep deployment gates and machine-parsed output on their original path until representative failures behave correctly.
RTK estimates one token for every 4 bytes of command output
RTK estimates one token for every 4 bytes, without using a model tokenizer. Its reduction percentage describes Bash output removed before the agent reads it. The final API bill also includes prompts, conversation history, and model output, so the dashboard cannot predict the same percentage of saved money. It is useful as a directional counter for command text, provided teams compare the final transcript received by their agent.
Our source install pulled 160 packages for a 4.3 MB checkout, while release binaries avoid that Rust dependency tree. The core utility stays local and needs no provider credential. Its gain, discover, and session commands read locally tracked usage. Optional daily telemetry requires consent; the README says it sends aggregate command names and usage data while excluding source code, file paths, command arguments, secrets, and environment variables.
Version 0.48.0 shipped on 2026-09-04, one day before the last push
GitHub showed 78,619 stars, 1,053 open issues, and 1,035 open pull requests on 2026-09-05. The repository was pushed that day, while v0.48.0 was published on 2026-09-04 with Bun and Deno support plus fixes across filters, discovery, telemetry, and command routing. The queue is unusually large, but the dated release and issue activity show a project receiving code and detailed bug reports rather than one coasting on stars.
Our 2,704-test run covered version 0.42.4 at commit 29f9bb7, not the current v0.48.0 release. That distinction matters because RTK's value depends on parsers matching current output formats and preserving failures. The newer release activity is a health signal; it does not extend our passing result to code we did not run. Evaluate the exact binary version against the external tools and locales used in production.
RTK fits beneath an existing agent when shell noise is the bottleneck
RTK v0.48.0 makes the most sense for a developer who already likes an agent and repeatedly sees useful context displaced by Git, test, build, or log chatter. Trial it on listings, status summaries, passing test output, and repetitive logs. Use the saved raw output when a summary looks odd. Workflows dominated by built-in file tools, short commands, or already compact agent output have less room to benefit.
The 24-second source install makes an experiment cheap, but the alternative should match the bottleneck. Aider replaces the coding workflow, LiteLLM manages model traffic and spend, and Simon Willison's LLM controls direct prompt calls from a terminal. RTK is the more focused choice when the agent stays and shell output is the waste. Keep its version pinned, preserve raw recovery, and promote each adapter only after a failing fixture returns the right text and status.