---
title: "RTK AI 1.0: Real Token Savings, Setup and Licensing"
canonical: https://wavect.io/blog/rtk-ai-token-savings-review/
language: en
description: "RTK AI 1.0 reviewed: real token savings, Claude Code and Codex setup, Apache vs BUSL editions, proxy limits and what to measure before upgrading your team."
image: "https://wavect.io/img/blog/headers/header_rtk-ai-token-savings-review.png"
author: ["Kevin Riedl"]
published: "2026-10-15"
updated: "2026-10-15"
reviewed: "2026-10-15"
---

# RTK AI 1.0: Real Token Savings, Setup and Licensing

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

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

[**Next**](/blog/smarter-token-usage-with-your-ai-coding-agent/)

TL;DR

RTK 1.0 adds opt-in pipelines and a separate API proxy; 1.0.1 is the latest stable version checked on 15 October 2026. The Apache-only rtk-oss edition retains command filters, while the full engine and proxy involve BUSL-1.1 terms. Large reductions in command output do not prove equivalent bill savings. Older JetBrains and RTK-team benchmarks did not establish general end-to-end savings and did not test 1.0.1. Start with the smallest useful configuration, verify your agent and API route, and measure accepted outcomes against a controlled baseline.

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](https://github.com/rtk-ai/rtk/releases/tag/v1.0.0); [1.0.1 followed on 14 October and is the latest stable release checked for this article](https://github.com/rtk-ai/rtk/releases/tag/v1.0.1). 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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/README.md) 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](/blog/smarter-token-usage-with-your-ai-coding-agent/).

## What changed in RTK 1.0?

The important addition is a configurable pipeline. The [version-pinned pipeline guide](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/pipelines/overview.md) 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.

| Change | Practical consequence |
| --- | --- |
| Pipeline engine | Inspect and configure behavior through `pipeline.toml`; the engine is not part of the Apache-only edition. |
| Optional post-tool compression | Expand beyond shell output where the integration supports it. Test file reads and exact recovery before rollout. |
| Separate API proxy | Process supported requests between an agent and its model provider, not merely what a shell command prints. |
| Changed reporting and CLI | The release changes the headline savings calculation, removes `--ultra-compact` and introduces the clearer `rtk bypass` name. |

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](https://github.com/rtk-ai/rtk/commit/2b96061bf6795f5ea22327770fab933c392b0b16) 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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/resources/editions.md) distinguishes three downloads:

| Download | License | Included |
| --- | --- | --- |
| `rtk-oss` | Apache-2.0 | Shell rewrite hooks and command filters. Installs an executable named `rtk`. |
| `rtk`, full edition | Apache-2.0 + BUSL-1.1 | The CLI, filters and compression engine. |
| `rtk-proxy` | BUSL-1.1 | The separately installed API proxy daemon. |

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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/resources/savings-explained.md) 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](#src-release) 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](https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/), 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](https://www.rtk-ai.app/blog/rtk-on-skillsbench/) 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](https://quesma.com/blog/does-rtk-make-ai-coding-cheaper/) 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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/getting-started/quick-start.md) 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](https://developers.openai.com/codex/hooks) 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](#src-pipelines) 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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/proxy/overview.md) 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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/proxy/configuration.md) makes the protocol boundary explicit:

| API route | Reviewed behavior |
| --- | --- |
| `/v1/messages` | Anthropic Messages: forwarded, measured and eligible for the shipped compression transforms. |
| `/v1/chat/completions` | OpenAI Chat Completions: forwarded and measured, but not compressed. |
| `/v1/responses` | Not a supported route in this release's documented allowlist; unmatched routes return an error. |

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](/blog/caveman-3-claude-code-input-compression/) 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](#src-proxy-config) 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](#src-proxy) 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](https://github.com/rtk-ai/rtk/blob/4ef8730cf3a0dea11c8d64a9b90bc0616fe52100/docs/guide/analytics/gain.md) 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](/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](/services/artificial-intelligence/) focuses on choosing and integrating the right components. [Talk to Wavect about a measurable coding-agent pilot](/contact/) with a defined baseline, acceptance tests and a clear rollout decision.

## Frequently asked questions

### What is RTK AI?

RTK AI means Rust Token Killer. It filters developer-command output before a coding agent reads it. Version 1.0 adds optional pipeline and proxy capabilities beyond the traditional shell filters.

### What is the latest stable RTK release?

As checked on 15 October 2026, the latest stable release is 1.0.1, published on 14 October. Version 1.0.0 was released on 13 October. Development release candidates are separate.

### Is RTK 1.0 fully Apache-2.0 licensed?

No. The rtk-oss download is Apache-2.0. The full rtk download combines Apache-2.0 and BUSL-1.1 components. The separate rtk-proxy daemon uses BUSL-1.1. Review the additional use grant for your use case.

### Does RTK reduce the whole AI bill by 90%?

Not necessarily. Command-output reduction is not total-task cost reduction. Provider billing, cached context, output tokens, retries and accepted outcomes must be measured separately. The older benchmarks discussed here do not evaluate 1.0.1.

### Does RTK work with Codex?

RTK documents a Codex shell-command integration through rtk init -g --codex. That does not imply complete pipeline parity or API-proxy compression. In the reviewed proxy, OpenAI Chat Completions is forwarded and measured without compression.

### Do I need rtk-proxy to use RTK?

No. The command hooks and API proxy are independent. The Apache-only command-filtering setup does not require the separately downloaded proxy daemon.

### Can RTK hide information an agent needs?

Compression can remove detail needed later. Test failed commands, tracebacks, exact output and recovery in your workflow. Keep authoritative raw CI results for acceptance; a compact transcript alone is not proof of a correct change.

## Final thoughts

RTK 1.0 makes a focused evaluation more interesting, not a 90% bill reduction more certain. Choose an edition deliberately, verify the actual integration and retain only the configuration that improves your agreed objective without weakening acceptance evidence.

Agent engineering

## Read next

Coding agents, MCP, context systems, evaluation and the controls required for dependable automation.

[Start here**Graph Engineering for AI Agents: When Does a Knowledge Graph Pay Off?**](/blog/graph-engineering-ai-agents/)

- [Anatomy for Claude Code: Interactive SVGs for Documentation](/blog/anatomy-claude-code-interactive-svg/)
- [Google AX: Suspend/Resume, Restart Costs and Self-Hosting](/blog/google-ax-agent-executor-security-self-hosting/)
- [WikiSkill: How Agents Evolve SKILL.md from Experience](/blog/wikiskill-self-evolving-agent-skills/)
- [Tencent Octop Review: What Builders Actually Get for Free](/blog/tencent-octop-ai-assistant-review/)
- [Wigolo Review: Local Web Intelligence for AI Agents](/blog/wigolo-local-web-intelligence-mcp-review/)

[Next article**Anatomy for Claude Code: Interactive SVGs for Documentation**](/blog/anatomy-claude-code-interactive-svg/)

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

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

[**Next**](/blog/smarter-token-usage-with-your-ai-coding-agent/)
