RTK token compression: what it trims from tool output

If you have ever watched a Cline or Claude Code session and felt the token meter spinning, most of what you are paying for is not your prompt or the model's reply. It is tool output: the files the agent read, the diffs it ran, the build logs it checked.

And you pay for it more than once. Every request an agent makes carries the conversation so far, so a 600-line git diff read on turn three is sent again on turn four, five and six, until the context is compacted or the session ends.

RTK is kRouter's answer to that, and it is on by default. This post explains what it actually does.

What changed in this post

The first version of this post described RTK as lossless, quoted a 500-task benchmark with zero regressions, and gave savings figures for each kind of output. None of that holds up. RTK cuts information on purpose -- it truncates long outputs and caps long lists -- and there is no benchmark in kRouter's repository behind those numbers. This version describes what the code does.

What RTK is

RTK stands for Rust Token Killer. It is an open-source command-line tool (rtk-ai/rtk) that filters shell output before an agent reads it. kRouter ports its filters to JavaScript and runs them on the request instead of in your shell: when a request passes through kRouter, RTK looks at each tool result in it and, if it recognises the content, swaps in a compact version before the request goes upstream.

It only touches content the request marks as a tool result:

OpenAI Chat Completions role: "tool" messages
Claude tool_result blocks
Responses API function_call_output items
Gemini and Antigravity functionResponse parts
Kiro tool results

Your prompt, the system prompt and the model's earlier replies are left alone. So is a tool result marked as an error, because an error trace is usually the part the model needs in full. If your client sends tool output as ordinary user-message text instead, RTK does not see it.

What it does to each kind of output

RTK looks at the first kilobyte of a tool result to decide what it is, then applies one filter:

Output	What the filter does
`git diff`	Compacts file headers, adds a +/- count per file, cuts each hunk after 100 lines and the whole diff after 500
`git status`	Summarises, listing at most 10 changed and 10 untracked files
Build output (npm, yarn, cargo, pip, maven, gradle)	Keeps errors, warnings and the final summary; drops progress and "Compiling..." lines
`grep` results	Groups matches by file and keeps at most 10 per file
`find` and path lists	Groups paths by directory, at most 10 per directory and 20 directories
`ls -la`	Drops noise directories such as `node_modules`, `.git` and `dist`, and compacts each row
`tree`	Drops the summary line and caps the output at 200 lines
`curl -v`	Drops TLS and connection chatter, keeps headers and body
Unrecognised output over 500 lines, usually a big file read	Keeps the first 200 and the last 100 lines and marks the gap
Other unrecognised output	Collapses runs of identical lines

Three safety rules apply to all of it. Results under 500 bytes are skipped, because there is nothing worth saving. A filtered result is only used if it is shorter than the original and not empty. And if a filter throws, the original goes through unchanged.

It is lossy, and that is the point

A truncated diff or a capped grep is not the same information as the full one. Most of the time the model does not need line 140 of a 600-line hunk, and when it does, the agent can read that part of the file again. That second read costs a turn. RTK trades an occasional extra read for not paying, on every turn, for output nobody needed.

If your workflow depends on the model seeing complete outputs -- reviewing a whole large diff in one pass, for instance -- turn RTK off for that work.

How much it saves

Honestly: it depends on how much of your traffic is tool output, and on what that output is. Two figures exist, and both are claims rather than measurements you can reproduce from the repository:

kRouter's README estimates 20-40% fewer input tokens per request for agent work.
The dashboard's toggle says 60-90% fewer input tokens for git, grep, ls, tree and log output specifically. That is the RTK project's own figure for those commands, and it describes the output being filtered, not your whole bill.

A chat session with no tool calls saves nothing, because there is nothing for RTK to touch.

Caveman: the output side

RTK only reduces input. kRouter's Caveman saver works on output instead: it adds a system prompt asking the model to answer tersely. It is off by default, has three levels (lite, full and ultra), and is a global setting rather than a per-combo one. The dashboard describes it as about 65% fewer output tokens, up to 87%; treat that as the claim it is, and expect explanations to get shorter along with the filler.

The other savers -- Headroom, PXPIPE and the response cache -- are off by default too. The token savers doc covers all of them.

Turning it on and off

RTK needs nothing to start. To check it or turn it off, open the dashboard's Token Saver page: RTK is the Compress tool output toggle, and Caveman is Compress LLM output on the same page. The setting applies to every request kRouter handles.

npm install -g @sifxprime/krouter
krouter -t

Common questions

Is RTK lossless?

No. It truncates long diffs, file reads and logs, and caps long lists of matches and paths. It removes what is usually noise, but it does remove content. If the model needs a part that was cut, it has to read it again.

Does RTK change my prompt or the model's answers?

No. It only rewrites tool results inside the request. Your messages, the system prompt and earlier assistant replies pass through unchanged, and tool results flagged as errors are skipped.

Is RTK on by default?

Yes. It is the only token saver kRouter turns on by default. Caveman, Headroom, PXPIPE and the response cache all start off.

How much will it save me?

kRouter's README estimates 20-40% of input tokens for agent work. That is an estimate, not a benchmark, and a session with few tool calls will save much less.

Does it work with every client?

It works with any client whose requests mark tool output as tool results, in the OpenAI, Claude, Responses, Gemini or Kiro formats. Output sent as plain message text is not touched.

ShareX LinkedIn Hacker News Reddit

Kodelyth · The team behind kRouter

Published by Kodelyth, the team that builds kRouter. Posts are drafted with AI assistance and reviewed by a person before they go out. kRouter is free and MIT licensed.

Install kRouter