What is turn amplification?

Turn amplification is when a change that makes each agent turn smaller causes the agent to take more turns, so the total bill rises even though every individual turn got cheaper. It happens because an agent re-sends its whole context on every turn, so the number of turns is a multiplier on everything, not just on the part you compressed.

Why does compressing terminal output not reliably cut coding-agent cost?

Three reasons showed up in the Quesma benchmark. Terminal output was only about 7% of Fable's input tokens and 26% of DeepSeek's, so the reachable slice was small. Most of what a later turn re-sends is billed as a discounted cache read, one tenth to one thirtieth of normal input price, so the compressed part was already the cheapest part. And the RTK runs took 18% more turns overall, which outweighed the 7% smaller average turn.

Why is rtk gain not a cost metric?

rtk gain subtracts filtered-output bytes from raw-output bytes and divides by four. That is an estimated token count, not tokens billed, and it compares against output the command would never have produced. In one task two head -1 calls were credited 120.5 million saved tokens each against the size of the whole file, which alone was 69% of the counter. It also cannot see how many turns the run actually took.

How should a team evaluate a context-compression tool?

Run paired attempts with and without the tool on the same model route, platform and timeout, repeat each task several times, and compare cost per successful task rather than bytes removed. Track turns alongside tokens, since turns are the multiplier. Weight tasks equally as well as summing the total bill, because one expensive task can carry a headline number that does not hold anywhere else.

Agent· 2026-09-13

RTK reported 89% token savings and DeepSeek's cost rose 17% — Turn amplification — What does it mean?

TL;DR

What is it: Turn amplification is the effect a Quesma cost benchmark of 1,740 Terminal-Bench 2.1 attempts measured behind RTK (Rust Token Killer), a wrapper that compresses terminal output before a coding agent reads it: every turn got thinner, and the agent took more turns.
Why it’s needed: Context compression is sold as a cost lever, so teams adopt it on bytes removed — but an agent's bill is turns multiplied by the context each turn carries, and a tool that shrinks one term while inflating the other can leave you paying more for the same work.
vs previous: The previous approach was to trust the compressor's own savings counter — rtk gain reported 349.2 million tokens saved, an 89% reduction — which silently assumes the rest of the run stays identical; turn amplification is the failure mode where it does not, and DeepSeek's average per-task cost rose 17%.

Jargon

Agent turn: One cycle of the loop: the agent sends its whole conversation so far to the model, gets a response, runs a tool, and appends the result. The next turn re-sends everything, plus the new result.
Turn amplification: When a change that shrinks each turn makes the agent need more turns, so total spend rises even though every individual turn got cheaper.
Cached input tokens: Context the provider already holds from a previous turn, billed at a discount — about 1/10 of normal input price for Fable and 1/30 for DeepSeek in this benchmark. Covered in Agent Engineering → Prompt Caching.
rtk gain: RTK's built-in savings counter. It subtracts filtered-output bytes from raw-output bytes and divides by 4 — an estimated token count, not a count of tokens you were billed for.
Terminal-Bench 2.1: A benchmark of terminal-heavy coding tasks. Quesma stayed on 2.1 rather than 3.0 or 4.0 because agents pass most 2.1 tasks, and cost only means something on tasks that pass.
Cost per successful task: Total spend, including failed attempts, divided by the number of passes. It is the honest denominator when a change also moves the pass rate; see Beyond price per token.
Tokenflation: Quesma's name for the broader pattern where a simple task quietly consumes ever more context, reasoning and tool calls without producing more useful output.

The news. On September 11, 2026, Quesma published a cost benchmark of RTK (Rust Token Killer), a wrapper that rewrites shell commands so a coding agent reads a terser version of the output. RTK has over 79,000 GitHub stars, and a widely shared post claimed it could cut Claude Code tokens by up to 60%. Quesma ran Terminal-Bench 2.1 five times with RTK and five times without, on the same model route, platform and timeout — 1,740 attempts across 85 Claude Code + Fable 5.0 tasks and 89 OpenCode + DeepSeek V4 Pro tasks. Fable's total bill fell 5%. DeepSeek's rose 5%, and its average per-task cost rose 17%. Read the benchmark →

Smaller bags, more trips

Picture the errand in the illustration. You are fetching groceries and someone hands you a smaller bag. Less to carry each time — obviously an improvement. But the bag is not what you are paying for. You are paying for the drive, and the drive is charged per trip. Take a bag half the size and you make the journey twice, and the meter runs from the first mile of each one.

A coding agent pays the same way. Every turn re-sends the whole conversation so far: the system prompt, the tool definitions, the file it read nine steps ago, and the output of every command it has run. The model answers, a tool runs, the result is appended, and the next turn sends all of it again. Turn amplification is what happens when you shrink one of those terms and inflate the other: an agent's bill is turns multiplied by the context each turn carries, so a cheaper turn bought with an extra turn is not cheaper at all. Compressing terminal output attacks a slice of the second term. It does nothing about the first — and if the agent has to ask twice because the compressed answer left out the detail it needed, it makes the first term worse.

This is the tension the Context Engineering module calls context as a scarce resource, seen from the billing side. The four fixes for a crowded context window are real fixes for a real problem — the window fills up, the model loses the thread. Cost is a different problem with a different unit, and a fix aimed at one does not automatically help the other.

Turn Nwhole context re-sent

Tool calloutput compressed

Thinner resultless in each turn

Turn N+1another full context

The billcontext re-billed, turns up 18%

The arithmetic of an extra turn

Quesma measured both halves of the product for the DeepSeek runs, which makes the compounding easy to see. Hold the task fixed and compare the RTK attempts with the baseline attempts. The average turn carried 7% less input with RTK — the compression worked, exactly as advertised. But the agent took 18% more turns to finish. Total input is roughly input-per-turn multiplied by turns, so the two changes compose. A 7% thinner turn and 18% more turns give 0.93 × 1.18 = 1.10 — about 10% more input in total, and the benchmark measured prompt tokens up 9%. The 7% discount was real, and it was eaten whole. The benchmark measures the extra turns; it does not isolate why each individual one happened.

The direction held case by case, not just in the average. DeepSeek's RTK attempts took more turns on 58 tasks, and 44 of those cost more. They took fewer turns on 28 tasks, and 23 of those cost less. Turns, not bytes, tracked the bill.

The pricing makes the trade worse than it looks. In agentic coding the context is cached after each turn, so most of what a later turn re-sends is billed as a discounted cache read — 1/10 of normal input price for Fable, 1/30 for DeepSeek. Cache reads were 98% of DeepSeek's input tokens but only 26% of its bill. So RTK was shaving the cheapest tokens in the run while adding turns that pull in everything else: DeepSeek's uncached input fell 1%, its cached input rose 9%, and model output including reasoning stayed at roughly 56% of the total cost, untouched.

Setup	Terminal share of input	Total bill	Cost per successful task	Avg cost per task
Claude Code + Fable 5.0	~7%	−5%	−3%	+1% (no clear difference from zero)
OpenCode + DeepSeek V4 Pro	~26%	+5%	+7%	+17%

Why the lever was small before anyone pulled it

Terminal output was only about 7% of Fable's input tokens, so even perfect compression could not move most of the bill. For DeepSeek it was 26% — bigger, but still a minority of a minority once cache pricing is applied. Three things kept the reachable slice small. RTK rewrites shell commands only, so the Read, Grep and Glob tools both harnesses expose go straight past it; in practice just 31% of Claude Code's terminal calls and 51% of OpenCode's actually ran through RTK. About half of Claude Code's remaining shell calls already limited their own output with head, tail or wc. And frontier models reach for those flags unprompted, which is the same saving arriving for free.

The savings counter hid all of this. Across 445 DeepSeek RTK attempts, rtk gain reported 349.2 million tokens saved, an 89% reduction. In one task the model ran head -1 train.txt twice; RTK credited itself 120.5 million tokens each time by diffing those one-line reads against the whole file, and those two calls alone accounted for 69% of the counter. The command was never going to return the file. A counter that estimates tokens from bytes removed against a hypothetical the agent would never have requested is not measuring money, and it cannot see the turns the run actually took.

There is a tail risk too, which is the part that belongs in an incident review rather than a cost model. One DeepSeek attempt hit a rewrite bug in RTK 0.45.0: the agent used a find flag the wrapper did not support, the wrapper rewrote the command anyway, the command failed with an instruction to use find directly, and every retry was rewritten again. The agent burned 339 consecutive errors over about twelve minutes. It still passed the task, and it cost roughly 9× the matching baseline attempt. RTK fixed the bug in 0.46.0. One outlier does not make the trend, but it shows the shape of the downside: a layer that sits between the agent and its tools can convert one unsupported flag into a loop the agent cannot reason its way out of.

What to measure instead

Measure cost per successful task, not bytes removed. That single denominator change would have caught this: Fable came out 3% cheaper per pass and DeepSeek 7% more expensive, while both pass rates slipped slightly — 84% to 83% for Fable, 71% to 69% for DeepSeek. Then look at turns as a first-class metric alongside tokens, because turns are what actually moved. And weight tasks equally as well as summing the bill: almost all of Fable's headline 5% saving came from a single task, winning-avg-corewars, where RTK happened to finish in about half the turns. Across the other 84 tasks the saving was under 1%.

None of this says compression is a bad idea. It says compression is an intervention, and an intervention on an agent has to be evaluated the way any other change to a stochastic system is — paired runs, the same model route, the same timeout, enough repeats to see past one lucky task, and an outcome metric rather than a proxy. That is the A/B harness discipline, applied to a tool rather than a prompt. Quesma's answer for RTK on this benchmark was a niche optimization, not a general source of savings — and the reason is worth more than the verdict.

Goes deeper in: Agent Engineering → Cost & Latency Engineering → The Cost Profile of an Agent

Related explainers

All three extend the same lesson: optimize the outcome, not a compression proxy.

Beyond price per token: cost per successful outcome — the denominator this benchmark turns on, worked through on its own.
FastContext: explorer-subagent context offloading — a context cut that did pay off, and what made it different.
The Context-Generation Substitution Law — the general form of the trade: context you remove has to be regenerated somewhere.

Frequently Asked Questions

Check what you knowMap your AI & GPU knowledge across every track — free, role-based