RTK AI 1.0: Real Token Savings, Setup and Licensing

Back

Kevin Riedl

12 min read · 15 Oct 2026
Last reviewed October 15, 2026

Next

A shorter agent transcript is useful. A lower bill for the same working software is more useful. RTK 1.0 makes that distinction worth revisiting because it can now do more than tidy up terminal output.

Version check: 15 October 2026. RTK 1.0.0 was released on 13 October; 1.0.1 followed on 14 October and is the latest stable release checked for this article. This is a documentation and source review, not a Wavect benchmark of 1.0.1. Development release candidates are not treated as stable releases.

What is RTK AI, and what does it actually optimize?

RTK AI, short for Rust Token Killer, filters command output before an AI coding agent reads it. Instead of returning every passing test or repeated log line, it can keep failures, group similar entries and shorten verbose output. The 1.0.1 README lists more than 100 supported commands across Git, test runners, build tools and other developer utilities.

Think of it as preparing a useful handover for the model. You are not making the model itself cheaper. You are changing part of what it has to read.

The traditional rewrite hook covers eligible shell commands. It does not automatically cover an agent's built-in Read, Grep or Glob tools. The full 1.0 edition adds optional mechanisms for reaching beyond that shell-output layer. Which mechanism you enable matters more than the headline compression percentage.

This guide focuses on RTK: versions, editions, setup, coverage and evidence. For the broader accounting method, use our guide to cost per accepted coding task.

What changed in RTK 1.0?

The important addition is a configurable pipeline. The version-pinned pipeline guide describes rules for when RTK should act, what content it should process and which operation to apply. Broader compression and delegation are opt-in rather than an automatic consequence of upgrading.

The old rtk proxy <command> name remains as an alias for rtk bypass <command>. It is not the separately installed API proxy.

Do not read “agent-agnostic” as “every feature works in every agent.” The release's hook-scope correction explicitly restricted pipeline hook rules to Claude Code. Existing shell-command integrations and the new pipeline control behavior are different capabilities. Check your exact agent and RTK version rather than copying a feature matrix from a development branch.

Is RTK 1.0 open source, and which edition should you install?

The Apache-only edition remains available, but the default full download is now mixed-license. The 1.0.1 editions and licensing guide distinguishes three downloads:

The project's additional grant permits free production use, including the daemon. It does not cover offering RTK or a derivative to third parties as a commercial product or service. That is not a blanket ban on using RTK at work. For redistribution, embedding or a client-facing RTK service, review the actual grant with the vendor and your legal adviser.

Our starting recommendation is the Apache-only edition when command-output filtering is all you need. Choose the full edition deliberately when its additional capabilities justify the license review. The two editions install the same rtk executable and cannot coexist; remove one before installing the other.

Does “up to 90% less output” mean a 90% lower AI bill?

No. Output reduction, model input reduction and total task cost are different measurements. RTK's savings explanation says its traditional command statistics estimate tokens from bytes / 4. That is not your provider's tokenizer. Treat the percentage as an output-size measure, not a verified reduction in billable model tokens.

A simple illustration: suppose a €100 workload contains €10 of genuinely avoidable command-output cost, after accounting for the agent's own truncation and cache pricing. Reducing that component by 80% saves €8, not €80. The workload becomes €92 before overhead. An additional €9 of retries or model work would make it €101. These are invented assumptions to explain the arithmetic, not RTK performance measurements.

There is also a baseline problem. If the agent would have truncated a huge output anyway, comparing a filtered result with the entire original file exaggerates what the model would otherwise have received. The 1.0 release notes acknowledge a reporting change: oversized outputs are excluded from the headline savings rate. Old and new dashboard percentages therefore need not be directly comparable.

A fixed-price AI subscription creates another distinction. Less usage may create more working headroom without reducing the subscription charge. Neither a dashboard percentage nor a token estimate proves how many additional tasks your plan will allow.

What do the RTK benchmarks actually show?

JetBrains tested RTK 0.43.0, not 1.0. It used Claude Code 2.1.201, Claude Sonnet 5 and 86 SkillsBench tasks. Across 80 clean low-effort pairs, the RTK arm had a median 7.6% higher cost per task, with p=0.004. At high effort, the median difference was +0.1%, with p=0.99. Task quality was statistically indistinguishable between the arms.

That is evidence against treating shell compression as guaranteed end-to-end savings. It does not establish that RTK 1.0 is worse, that every workload becomes more expensive or that compression cannot help.

The RTK team's published response argues that broad SkillsBench tasks underrepresent its target developer loop and that agent behavior introduces substantial variance. Its RTK 0.45.0 follow-up reported a 4.8% lower pooled cost across 12 balanced tasks from a 13-task sweep, but p=0.305: not a statistically established saving. The team also agrees that compressing one layer is different from reducing the whole bill.

A September Quesma test used RTK 0.45.0 across 1,740 Terminal-Bench 2.1 attempts. Cost per passed attempt fell 3% for Fable and rose 7% for DeepSeek. Fable's total savings were concentrated in one task. This is also pre-1.0 evidence, not a 1.0.1 result.

None of these studies measures 1.0.1. The new coverage is a reason to test again, not permission to re-label an older result as a 1.0 benchmark. This review does not establish an independently verified end-to-end saving for the new release.

How do you set up RTK for Claude Code or Codex?

Begin in a development environment with backed-up agent settings. For a first install that only needs the Apache-2.0 command filters, the documented Homebrew option is:

brew install rtk-ai/tap/rtk-oss
rtk --version
rtk gain --text

This installs the version currently served by the formula, not necessarily 1.0.1 forever. Record the actual version. Use the versioned release assets and published checksums when you need to reproduce this review exactly. Existing installations should be upgraded through their original installation method, not layered with a second edition.

The RTK quick-start guide documents a dry run for every initialization flavor. For Claude Code, first inspect the planned changes, then initialize:

rtk init -g --dry-run
rtk init -g

For Codex, use this alternative instead:

rtk init -g --codex --dry-run
rtk init -g --codex

The -g flag changes global agent configuration. Run only the block for the agent you intend to configure. Restart that agent and ask it to run git status in a test repository, then inspect rtk gain --history. A normal terminal command outside the agent is not automatically intercepted by its hook.

OpenAI's Codex hook documentation supports the underlying distinction: PreToolUse can rewrite tool input through updatedInput. That does not establish support for every RTK pipeline feature or API-proxy transform. Keep the agent's permissions and sandbox enabled.

Should you enable post-tool compression immediately?

No. Establish a baseline with command filtering first. In the full edition, rtk:default preserves the traditional setup. To test the documented post-tool layer separately, the pipeline fragment is:

[pipeline]
extends = "rtk:posthook"

Merge it into the appropriate user pipeline file rather than overwriting existing configuration. The pipeline guide uses ~/.config/rtk/pipeline.toml on Linux, with different user-data paths on macOS and Windows. Validate the full-edition configuration, then rerun initialization when new hook events are required:

rtk pipeline show rtk:default
rtk pipeline validate
rtk init -g --dry-run

After reviewing the dry run, apply the required initialization and restart the agent. A pipeline file in the Apache-only edition is inert. For the new hook rules, use the Claude Code scope established by the reviewed release rather than assuming cross-agent parity.

Keep the first pilot free of model delegation. Delegating a read to another model introduces a separate cost and data boundary, so it deserves its own experiment. Changing compression, routing and model choice together makes any result difficult to explain.

Does RTK's API proxy compress Codex or OpenAI traffic?

Not in the same way as Anthropic traffic in the reviewed 1.0.1 release. The proxy overview describes a separate local daemon, rtk-proxy, managed through rtk llm-proxy. It is not bundled inside either rtk edition. Hooks and proxying can be used independently.

The version-pinned proxy configuration makes the protocol boundary explicit:

Codex shell-command filtering is therefore not evidence that Codex's full API traffic can be compressed by this proxy. The proxy guide lists rtk claude as its verified launcher. Start with rtk llm-proxy setup after installing the daemon; do not redirect every agent to it by assumption.

Already using another compression layer? Our Caveman 3.0 guide covers that tool separately. Do not stack two context-transforming proxies and attribute the result to RTK alone.

What should a team verify before using RTK on client work?

Keep the proxy on loopback. The proxy security guidance says it forwards provider credentials and is designed as a single-operator local process. Exposing it on a public server is not equivalent to installing a harmless terminal formatter.

Also distinguish “no prompt logging by default” from “no local content retention.” The proxy documentation describes an opt-in CCR feature that stores original compressed content for recovery, with a seven-day retention period. Review local access, deletion, backups and client data rules before enabling it. Local preprocessing does not stop approved content from reaching the configured model provider.

Our recommended acceptance checks are simple: a failing test must remain visibly failed; its exit status must remain authoritative; a necessary traceback must be recoverable; and exact machine-readable output must not silently become a summary. Keep deployment decisions attached to original CI results, not an agent's interpretation of a shortened transcript.

For a read-only diagnostic comparison, rtk bypass git status provides unfiltered output. Do not rerun a mutating operation merely to compare two formats. Compression is a presentation choice, not a substitute for permissions, isolation or QA.

How should you measure an RTK 1.0 upgrade?

The 1.0.1 analytics guide provides history, exports and recall statistics. Recall frequency helps identify filters that regularly hide information the agent then retrieves again. It is a diagnostic signal, not proof that the accepted result is correct.

rtk gain --text
rtk gain --history
rtk gain --recalls
rtk gain --all --format json

For a credible pilot, freeze the repository revision, tasks, model, effort level, agent version, RTK edition and configuration. Compare no RTK with command filtering first. Test the post-tool layer and proxy as separate treatments. Repeat tasks and vary run order; one unusually cheap run should not decide a rollout.

Use provider-reported usage and charges, including worker calls, cache categories and failed attempts. Record accepted outcomes, reviewer time, elapsed time, retries and missing information. Keep failed runs in the report rather than silently removing the cases that make a tool look worse.

Your keep-or-remove rule should be explicit: adopt a configuration when it improves the agreed cost, latency or context objective while maintaining acceptance quality and security. A lower rtk gain percentage can be a better result when it avoids unnecessary rereads.

Wavect's view: optimize what the client receives

RTK 1.0 is worth evaluating because it expands what a team can control. The Apache-only filters offer a narrower starting point; the full engine and proxy add capabilities, setup choices and responsibilities. None removes the need to verify the software being delivered.

Our Semaprax architecture keeps authoritative command results separate from compact model-facing views. That is the principle we recommend here too. It is not a claim that RTK 1.0.1 is already qualified across Semaprax or every Wavect project.

For clients, the useful result is working software with credible evidence, not a screenshot of a token counter. Our AI engineering service focuses on choosing and integrating the right components. Talk to Wavect about a measurable coding-agent pilot with a defined baseline, acceptance tests and a clear rollout decision.