rtk-ai/rtk: a CLI proxy that compresses bash output before your agent reads it

The problem rtk targets: bash output that your agent pays for twice

An agent that runs `git status`, `cargo test` and `ls` in a loop reads every line of the result. Most of those lines carry no decision-relevant information: progress bars, passing test names, one directory entry per line. rtk's premise is that the filtering belongs in the shell path, not in the agent's prompt, so the model never sees the noise at all.

The README frames the scope narrowly, which is to its credit. It says rtk "filters and compresses command outputs before they reach your LLM context", with 100+ supported commands and under 10ms of overhead. The audience is anyone running a hook-capable coding agent on a repository where shell commands produce long, repetitive output: test suites, large diffs, deep directory trees. If your agent mostly reads files through a dedicated Read tool rather than through `cat`, the win is smaller than the headline suggests.

How the interception works: hooks rewrite commands, rtk filters the result

The README's diagram shows the agent calling `git status`, rtk receiving it, rtk invoking git, and a filtered result returning to the model instead of the raw output. For hook-based agents the rewrite happens before execution, so `git status` becomes `rtk git status` transparently. Plugin-based agents, Hermes among them, use their plugin API for the same rewrite. The agent does not have to know rtk exists.

Four strategies are applied per command type, according to the README: smart filtering to drop comments, whitespace and boilerplate; grouping so files are aggregated by directory and errors by type; truncation to keep context and cut redundancy; and deduplication that collapses repeated log lines with counts. The per-command behaviour is concrete: `git log` keeps hash, author and subject only; `git diff` reduces context and strips headers; `cargo test` and `npm test` show failures and collapse passing tests to a count; `pytest` trims tracebacks; `go test` parses NDJSON and reports failures only.

The savings claim is stated carefully. rtk cuts "up to 90% of the bash output" your agent reads, and the README explicitly separates that from cutting your bill by 90%. Bash output is one contributor to input tokens, input tokens are part of the bill, and the reduction dilutes at each step. Token counts are estimated as bytes divided by four because rtk ships no tokenizer, so the README says the percentages are reliable and the absolute token numbers are approximate. That is a rarer disclosure than the marketing line that usually accompanies a compression tool.

Installing rtk and getting a first filtered command

Homebrew is the recommended path. The README gives a single command, and the formula is referenced from the project's badge list.

brew install rtk

On Linux or macOS without Homebrew, the install script places the binary in `~/.local/bin`. If that directory is not already on your PATH, the README supplies the export line for `~/.bashrc` or `~/.zshrc`.

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh

Cargo works too, but only from git. There is a name collision on crates.io with an unrelated project called Rust Type Kit, and the README warns that if `rtk gain` fails after a plain `cargo install`, you have the wrong package.

cargo install --git https://github.com/rtk-ai/rtk

Verification is two commands. `rtk --version` should print a version string and `rtk gain` should open the savings dashboard. The README's example output for the version check shows "rtk 0.28.2" while `Cargo.toml` in the repository declares version 0.48.0, so treat the printed number as whatever your installed build reports rather than a fixed value.

rtk --version
rtk gain

The first real use is registering the hook for your agent. The default target is Claude Code or Copilot; other agents take a flag, and some take an agent name.

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor

After that, run a command through rtk directly to see the shape of the output before trusting the hook. `rtk git status` returns a compact status and `rtk ls .` returns a tree with file counts.

rtk git status
rtk ls .

One caveat the README states plainly: the hook only runs on Bash tool calls. Claude Code's built-in Read, Grep and Glob tools do not pass through it, so those workflows need shell equivalents (`cat`, `rg`, `find`) or direct calls to `rtk read`, `rtk grep` and `rtk find`.

Where rtk stops helping, and the token arithmetic you should not trust

The most important limitation is self-declared. The savings percentages describe reductions in bash output, not reductions in cost, and the README walks through why: your prompt, the system prompt and conversation history all contribute input tokens, and output tokens are billed separately. A team that reads "up to 90%" as a billing forecast will be disappointed.

The second limitation is the estimator. Without a bundled tokenizer, rtk computes tokens as bytes divided by four. That is a heuristic, and it will drift on content that is not English prose: minified JSON, CJK text, source code with heavy punctuation. The relative comparison between two runs of the same command is still meaningful; the absolute number on the dashboard is an approximation.

The third is coverage. The hook fires on Bash tool calls only, so an agent that leans on native file-reading tools gets no benefit from the rewrite path. The README's own suggested workaround is to switch to shell commands or call rtk's subcommands directly, which means changing how the agent works rather than only installing a binary.

Finally, there is a correctness question the README does not answer. rtk compresses `git diff` by reducing context and stripping headers, and `rtk diff` exits 1 when files differ. Whether a trimmed diff still carries the hunks an agent needs to reason about a change is command-specific, and the README does not document a rollback path or a dry-run mode for the hook. If your agent's edits depend on full diff context, test that workflow before enabling the hook globally.

rtk compared with simply narrowing what the agent runs

The obvious alternative is not another proxy but a change in habits: tell the agent to run `git status --short`, `pytest -q --tb=line`, `rg --files-with-matches` instead of `rg`, and pipe long output through `head`. That approach needs no installation, no hook, and no new binary in the path, and it composes with any agent that can be instructed.

The difference in approach is where the intelligence sits. Prompt-level narrowing depends on the model remembering to use the right flags every time, and it degrades as the conversation grows. rtk moves the decision into the shell layer, where the rewrite is deterministic and applies whether or not the model cooperates. The trade-off is that rtk's choices are fixed per command type, so a project that genuinely needs full `git log` bodies or untruncated grep lines has to bypass the proxy or call git directly.

A second alternative is a general context-management layer inside the agent itself, such as summarization or output truncation performed by the harness. Those operate after the command runs and can summarize anything, including tool output that never touched a shell. rtk is narrower and cheaper: it never sends the bytes in the first place, which is why the overhead figure matters. The README puts that overhead under 10ms, and the binary has no runtime dependencies beyond the OS, since it is a single Rust executable.

Maintenance, release cadence and what Apache-2.0 means here

The repository is not archived, and the last push was on 2026-08-28, which is recent enough that the project is being worked on now. The release history shows a steady stream of tagged versions and release candidates: v0.46.0 on 2026-08-26, with dev-0.46.1-rc.367 and dev-0.46.1-rc.368 following within days. Release-please configuration files sit at the repository root, which is consistent with automated versioning from conventional commits.

Upgrade cost is low by design. The Homebrew formula, the install script and `cargo install --git` all pull the latest build, and the binary has no service to restart and no database migration to run. The one operational detail worth knowing is the release-candidate channel: the `dev-` tags indicate that pre-release builds are published alongside stable ones, so a script that installs "latest" may pick up an rc.

The licence is Apache-2.0, stated in `Cargo.toml` and in the README badge. That permits commercial and internal use, modification and redistribution, with the usual conditions around attribution and the patent grant. Redistributing a modified rtk inside a product means carrying the licence text and noting changes. This is a description of the licence identifier, not legal advice; check the full text in the LICENSE file for your situation.

Editorial conclusion

Adopt rtk if your agent burns context on repetitive shell output and you are willing to route Bash tool calls through a hook, and start by checking that rtk init -g actually rewrote a command rather than assuming it did. Skip it if most of your context comes from Read, Grep and Glob tool calls, because the README states the hook only fires on Bash, or if you need exact token accounting, since the project estimates tokens as bytes divided by four. Before rolling it out, verify two things on your own setup: that rtk gain reports a plausible reduction on the commands you actually run, and that your agent's non-Bash tools are unaffected.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes