The Missing Math Behind RTK’s Token Savings

Key takeaways

• Reducing tokens in command output does not cut the entire task’s cost by the same percentage.
• Actual savings depend on which tokens disappear, their billing rates, and their share of total spending.
• Missing information can trigger extra queries and retries that eat into the savings.
• Compare total cost per successful task under the same quality requirements.

A promise to slash token usage is an easy sell when you’re paying an AI agent to fix code. The harder question is how much less you’ll pay for a working fix. That’s the question to bring to RTK and Quesma-related cost benchmarks.

First, check what got smaller

Tokens are the chunks of text a model processes and generates. They’re also a billing unit, but a token count alone doesn’t tell you what an entire coding task costs.

Suppose a tool condenses terminal output before passing it to the model. That reduces one slice of the model’s workload. It doesn’t automatically shrink your prompt, the other source files the agent reads, or the code it generates.

There’s a terminology trap here: command output becomes model input. A test log printed in your terminal is different from the output tokens a model generates when it writes a response or a patch.

So before celebrating a reduction, check the denominator. Does the percentage describe one command’s output, all tool results, or every token consumed before the task was finished? Those measure different things.

An 80% token reduction can mean a 16% cost reduction

Consider a hypothetical coding task that costs $10 in usage-based model charges.

Reading the command output you want to compress accounts for $2. Other inputs and model-generated output account for the remaining $8.

Now cut those targeted tokens by 80%, while keeping their billing rate and all other usage unchanged:

• Original cost of targeted input: $2.
• Savings: $2 × 80% = $1.60.
• New total task cost: $8.40.

The targeted token count fell 80%. The total bill fell 16%. Both figures are correct; they answer different questions.

Pricing adds another wrinkle. If a plan charges different rates for ordinary input, cached input, and generated output, you need to calculate each category separately. Cached input reuses previously processed content. Where that reuse receives a discount, removing a cached token can save less than removing an ordinary input token.

For a fixed subscription, the effect may be extra capacity rather than cash savings. If your subscription tier and additional charges stay the same, your monthly payment stays the same too. Lower usage may simply leave more room within your allowance.

A shorter log can create a longer debugging session

The value of compressed output depends on what survives.

Removing repetitive test-success messages may leave everything the agent needs to proceed. Removing the error location that explains a failure may force it to fetch the logs again.

That second lookup spends some of the tokens saved on the first pass. If missing context leads to an incorrect patch, the agent may also need another round of code generation and test execution.

The first response’s token reduction therefore tells you little about the complete workflow unless you also track follow-up requests and retries.

Longer output isn’t automatically better, either. Cutting repetition can make useful information easier to find. The practical requirement is straightforward: preserve the information needed to choose the next action.

Measure the price of a working fix

The most useful metric is cost per successful task.

For a bug-fixing comparison, both approaches should face the same acceptance criteria. A run that stops halfway through can be cheap. That doesn’t make it an economical way to fix the bug.

When evaluating an RTK savings claim or a Quesma-related comparison, check four things:

• Task setup: The same starting code, request, model, and settings.
• Billing: The applicable rates for each token category, including cache discounts.
• Completion: The same success criteria, such as passing the required tests.
• Full execution: All follow-up queries, retries, and failed attempts included in the cost.

For repeated runs, look at the spread as well as the average. A workflow that usually finishes cheaply but occasionally gets stuck in an expensive retry loop needs a budget that accounts for both outcomes.

Human review belongs in a separate calculation. A smaller model bill may offer little overall benefit if someone spends substantially longer reviewing and repairing the result.

Token reduction can lower costs, but the percentage alone doesn’t tell you how much you saved. The number that matters is what you paid to finish the job at the quality you required.