RTK removes command noise. The result depends on the command.

The best result is a denser context, not a universal reduction.

Several recent articles have discussed RTK and reported large gains from its use. Some of these claims treat raw command-output reduction as if it were the same as model-visible context reduction or lower token spending. That comparison can be misleading because a coding host may already clip, store, cache, or summarize the output before the model sees it. This article therefore uses a bounded set of controlled experiments to measure where RTK provides real value, where the gain becomes smaller, and where no size saving remains.

What RTK actually changes

RTK works before command output reaches the model. When the filter keeps the right details, this can give the model less repetitive text to process. The host may also limit one large tool result before it enters the conversation. The measured benefit must therefore be compared with what the host would deliver, not only with raw shell output.

A deterministic filter between the shell and the agent.

The agent still requests a normal development command. RTK selects a command-specific formatter, runs the child process, and keeps the child exit status. It returns a smaller result when safe filtering is available; a safety fallback may keep the native output. A path to the full captured output is shown when recovery is available.

Useful changes in the current build

Large output reduction is not enough by itself.

Six command cases were run in fresh directories: five failures and one successful .NET build. The native and RTK paths used the same source and child-command options. All exit codes remained unchanged.

What these fixtures represent

The Python fixture prints 120 successful status records before three failures. The Rust fixture contains 120 passing tests and three failing tests in standard and --nocapture modes. The C++ build prints 120 CMake status records before three Clang errors. The two .NET projects use a custom MSBuild target with 120 high-importance messages; one succeeds and one ends with three C# compiler errors. These controlled cases are not an estimate of every project.

Python, Cargo, and .NET used dedicated RTK wrappers. CMake build and Clang-family compiler commands now rewrite directly to the generic rtk err filter; the measured C++ command used that same route.

One-result limits change the value of filtering before compaction begins.

Command output does not always move directly into the model context. A coding host may first keep it inline, replace it with a preview, or return a head-and-tail excerpt. Only then does the result join the session and later take part in compaction. RTK acts before both host stages, but its effective gain depends on what the host would deliver anyway.

Claude Code has separate paths for valid and failed results

Anthropic documents roughly 30,000 inline characters for a valid Bash result. Above that level, Claude receives a short preview from the start and a saved-file path. A failed command uses a smaller path: roughly 10,000 characters, taken from the head and tail, without a file path. The local Claude Code 2.1.222 build uses 30,000, 10,000, and an up-to-2,000-unit head preview at these boundaries. It uses JavaScript string length, not UTF-8 byte length, and stdout and stderr share the same accumulator.

The probe commands ran locally. Their treatment was replayed from the verified local implementation. The authenticated Claude Code matrix then observed the same 10,039-unit failure envelope in live pytest tool results. These boundaries may change between releases.

What Claude would receive from the six command fixtures

The native and RTK commands were executed again. Their results were then passed through the local valid-or-failure delivery rule. The table counts visible command text, including the failure marker but excluding generated path and wrapper text. All selected diagnostic groups remained visible in both arms of these controlled fixtures.

The same model can behave differently in a different host

A model's context capacity and the host's delivery behavior are separate. Claude Sonnet 4.6 was therefore tested both in Claude Code and inside Copilot CLI. At six calls, RTK reduced cumulative input by 43.6% in Claude Code and 59.3% in Copilot. The difference does not come from model capacity alone: the hosts delivered the tool result and managed caches differently.

The context limits above came from the live session records. They describe the measured model and host versions, not every model available in those products.

What changes before and after compaction

Per-result delivery happens first. RTK can reduce the inline result, replace an unhelpful preview with a focused summary, or do nothing to the delivered size when both forms hit the same limit. If the model then reads a saved full-output file, that extra read adds new content and can return some of the avoided pressure.

Session compaction happens later and considers the whole conversation. A smaller inline result can leave more room for code and earlier decisions, but RTK cannot choose when the host compacts or which earlier details its summary keeps. After compaction, RTK also cannot restore a fact that the host removed.

The input benefit grows when tool results remain in the conversation.

The live study used exact host counters from Claude Code, GitHub Copilot CLI, and Codex. Each fresh session ran the same failing pytest suite one, three, or six times. The RTK arm used the tested release binary; the control arm called pytest directly. All 90 sessions returned the same correct diagnostic answer. The 45 matched pairs cover 332 verified shell calls and five host-and-model configurations.

The host changes how much RTK reaches the model

The same Claude Sonnet 4.6 model was tested in two hosts at six calls. Copilot delivered the complete 14,216-byte native result because each call stayed below its 20 KiB result gate. Claude Code delivered a 10,039-character failure excerpt. RTK stayed inline in both hosts. Cumulative input was 59.3% lower in Copilot and 43.6% lower in Claude Code.

This is not a ranking of the hosts. Their system prompts, tool schemas, cache placement, and auxiliary model work are different. It shows why a shell-output percentage cannot be reused as a token percentage. RTK acts first; the host then decides what enters each model call and what returns from cache.

Why a 93% tool-text reduction becomes a 9–59% input reduction

RTK removed about 93% of the full pytest tool result in Copilot and Codex. It did not remove the host system prompt, tool definitions, user request, model replies, or fixed session data. One Codex Sol call therefore used 8.9% less total input, while six calls used 28.7% less. The repeated result can be included again in later model steps, so the gap grows with session depth. Copilot GPT-5.3-Codex reached 54.4% at six calls. Claude Code reached 43.6% after its own failure clipping had already reduced the control arm.

Token spending has several parts

Total input alone is not a complete cost view. Cache reads, cache creation, ordinary new input, generated output, and reported reasoning output can use different rates. The table keeps these parts separate. Claude Code also reported a small auxiliary-model call, which is included in its totals.

RTK input was lower in every one of the 45 matched pairs. Generated output moved in the other direction: its aggregate was higher with RTK in all eleven groups. The extra output was much smaller than the avoided input, but it must not be hidden in a spending claim. Reported reasoning tokens were mixed, and the Sonnet paths did not expose them as a separate exact field.

No single money value is stated because account and model rates can differ. A current estimate should price cache reads, cache creation, other input, and output separately. The input-reduction percentage must not be applied directly to a complete bill.

How RTK can influence model reasoning

RTK does not change the model itself. It changes the information available while the model decides what failed and what to do next. Four effects matter in the measured paths.

RTK overhead is small beside a model call, but it is not zero.

Release benchmarks on the same machine put bare startup near 7 ms and rewrite paths near 14 ms. This local overhead is small compared with the 8–34 second live sessions, but RTK sessions were faster in only 19 of 45 pairs. Model latency did not improve consistently.

For large test and build outputs, a 7–14 ms local process is a reasonable trade for a much smaller tool result. For small commands that already return a few lines, the same fixed work may offer no useful gain.

RTK's main value is information density, not a universal saving.

Across six controlled commands, RTK consistently kept the selected facts and the child exit status. Five results became much smaller. The sixth, a failed .NET build, became larger at the shell because RTK kept the complete native log as a safety fallback. The Claude boundary replay changed the effective percentages and removed that size penalty: both .NET failure forms reached the same host excerpt. Shell reduction, host delivery, and fidelity must therefore be read as separate results.

The live model study covers diagnostic extraction from the Python fixture. Rust, C++, and .NET were measured for command-output fidelity rather than model behavior.

RTK is strongest when noise is predictable and failures are structured.

Test runners and build tools often repeat successful status lines while the agent needs only a few failures. RTK has the clearest value in this pattern: the command remains the same, but the result is reshaped around the next debugging decision.

The Cargo --nocapture result makes the difference concrete. Native output used 150 lines. The RTK result used 11 lines and still showed each failing test, its panic message, the assertion values, the final counts, and exit code 101. The model has less text to search, but it receives the same facts needed to explain the failure.

Compiler workflows show the same pattern. CMake and Clang produced three source-level errors after 120 build messages; RTK returned the three symbols and locations in 13 lines. A successful .NET build collapsed to one verdict. When the .NET build failed, RTK emitted the full log instead. That protected the shell result, but Claude Code still reduced both native and RTK failures to its head-and-tail envelope. The current fallback is safe at the command boundary, not efficient for that host.

The effect on the model is therefore indirect but practical. RTK does not add reasoning ability. It reduces the search space around a decision and leaves more context for code, instructions, and earlier conclusions. In the live comparison, that smaller information load preserved answer correctness and lowered exact cumulative input, but it did not produce a consistent change in answer length or speed.