RTK: the savings number is about output bytes, and the manifest and the release tags carry different version numbers

The 90 percent is about bash output, and the README walks back the rest

The headline is that RTK cuts up to 90 percent of the bash output your agent reads. Two paragraphs later the README explains what that does not mean. Bash output is one contributor to input tokens, alongside your prompt, the system prompt, and conversation history. Input tokens are in turn only part of the bill, which also counts output tokens. The reduction dilutes at every step.

That paragraph is the most useful thing in the file, and it sits directly under the table of what RTK does to each command's output.

Consequence for the reader: a tool that compresses one input channel cannot promise a proportional cut in cost, and the README says so in the project's own voice rather than leaving you to discover the arithmetic. Treat the percentage as a property of the pipeline from the shell to the model context, not as a property of your invoice. The repository description, which says 60-90 percent of LLM token consumption, states it more strongly than the README does.

Token counts are bytes divided by four, because there is no tokenizer in the binary

The savings dashboard reports token numbers, and the README says how it gets them: estimated as bytes / 4, because RTK ships no tokenizer. The stated consequence is that the percentages are reliable while the absolute token numbers are approximate.

A ratio survives a constant multiplier. If every input and every output byte is divided by the same four, then the share of bytes removed is the share of tokens removed, and the ratio holds. The absolute figure does not survive, because a four-bytes-per-token rule ignores the actual distribution of your command output.

Consequence for the reader: you can trust the percentage and you cannot trust the number next to it. If a dashboard line says it saved 42,000 tokens, the defensible reading is that it removed roughly 168,000 bytes, and how many tokens that was depends on a tokenizer this project does not carry. Anyone budgeting from the absolute figure is budgeting from a constant.

The manifest, the tags, and the README's own check all name a different version

Cargo.toml declares version 0.49.0 with edition 2024 and rust-version 1.91. The three most recent releases are dev-1.2.0-rc.612, dev-1.2.0-rc.610, and dev-1.2.0-rc.609, dated 2026-11-03 and 2026-11-02, which is a release candidate line well above the manifest.

Then there is the verification step the README tells you to run after installing:

rtk --version   # any current version
rtk gain        # must show the savings dashboard, not "command not found"

The README's check now reads any current version, so it no longer pins a number.

Consequence for the reader: the manifest says 0.49.0 while the tags say 1.2.0, so a version number alone does not say which build you have. Every recent tag carries a dev- prefix and an -rc suffix, so the tags point at release-candidate builds.

The description says zero dependencies and the manifest lists twenty-one

The repository description advertises a single Rust binary with zero dependencies. Cargo.toml opens with a comment saying it is two crates and one binary: the Apache-2.0 rtk CLI links the BUSL-1.1 engine crate, so the shipped binary contains BUSL-1.1 code, and the workspace members are the root crate, text, engine and plugin.

The same comment notes that libsqlite3-sys is pinned by hand in both lockfiles, with rusqlite 0.34 in the root crate and in proxy/Cargo.toml.

Consequence for the reader: zero dependencies describes the binary at runtime, not the source tree, which is several crates with a BUSL-1.1 engine linked in. Anyone with a supply-chain policy has to read the manifests rather than the description.

The install script is fetched from master while the default branch is develop

The quickest install for Linux and macOS pipes a remote script into a shell:

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

The URL names refs/heads/master, and the repository's default branch is develop.

The alternatives avoid the question. Homebrew is the first path listed with brew install rtk, Windows has winget install rtk-ai.rtk, and Cargo is covered by the installation guide, with Cargo.toml naming cargo install --git <url> rtk.

Consequence for the reader: the script you pipe into a shell is fetched from a branch that is not the branch the project treats as current, and it is the path with the least review.

The hook only catches Bash calls, so Read, Grep and Glob are not compressed

RTK installs itself into an agent with rtk init, and there are at least twelve agent variants in the list, from a default global install for Claude Code and Copilot through flags for Gemini, Codex, and agent names for cursor, windsurf, cline, kilocode, antigravity, kimi, pi, omp, and hermes.

Hook-based agents get their Bash commands rewritten before execution, so git status becomes rtk git status. Then the README states the limit plainly: the hook only runs on Bash tool calls, and Claude Code built-in tools like Read, Grep, and Glob do not pass through the Bash hook, so they are not auto-rewritten. The suggested workaround is to use shell commands such as cat, rg, and find instead, or to call rtk read or rtk grep directly.

Consequence for the reader: an agent that reads most files with its built-in Read tool is running the uncompressed path for most of its reading. The savings you get depend on the agent's tool preferences, not on RTK's filters,.

A different rtk exists on crates.io, and the check that reveals it is rtk gain

The README carries a name collision warning. Another project named rtk, exists on crates.io. The check is that rtk gain must show the savings dashboard, not "command not found".

Consequence for the reader: the collision warning means a plain cargo install rtk can install something that shares the name and none of the behaviour, and the only way to tell is to run a subcommand and see whether it exists.

Windows gets a separate set of instructions because of what the hook needs

The README's Windows route is winget install rtk-ai.rtk, and it points to the Installation guide for Cargo, pre-built binaries, native Windows, WSL and uninstall. Cargo.toml mentions no Windows-specific dependencies in the visible part, so the Windows details are best taken from that guide.

Editorial conclusion

Use RTK if your agent runs a lot of shell commands whose output is long and mostly uninteresting, since that is the case its filters are built for, and you are willing to audit which of your tools actually route through the hook. Do not adopt it on the strength of a cost estimate: the README itself says the reduction dilutes at every step between bash output and the invoice, and that absolute token numbers are approximate because there is no tokenizer in the binary. Before you install, check three things: which install path you take, because cargo install without --git pulls a different project from crates.io, whether the commands you care about are Bash tool calls or built-in tools like Read and Grep, and what version you actually installed, since the manifest and the release tags each name a different one.

Frequently asked questions

Official sources

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