Where the tokens go

Halfway through this audit I discovered I was running the same cost-saving plugin twice — two live installations, each injecting its instructions into every prompt I sent. I had not noticed. Nobody notices. That is the real problem with token costs on coding agents: the spending happens in a layer nobody reads, and the tools that promise to fix it aim at the layer everybody reads.

It started with a post on Code Pointer claiming that the popular token-saver tools — rtk, headroom, caveman — save about 3.7 percent combined on a real bill, not the 60 to 90 their marketing implies. A strong claim, but a checkable one, because coding agents keep receipts. Every response in the transcript carries the exact token counts the API billed, split four ways: fresh input, output, cache writes, cache reads. So I priced eight weeks of my own traffic. 2,671 sessions. 22.8 billion tokens.

At list rates that traffic is worth $19,745 — an accounting unit, not an invoice, since I am on a subscription. The ratios are what matter, and the ratios are lopsided.

One number runs the show. Sixty-two cents of every dollar went to cache reads — the agent re-reading its own setup rather than my code, my questions, or the model's answers. Every request re-sends the entire static prefix: the system prompt, tool definitions for every connected MCP server (one server on my machine ships about three hundred of them), plugin instructions, hooks, rules files. Caching discounts this re-reading to about a tenth of the normal input rate. The discount is real; the volume swallows it. By raw token count, 97.1 percent of everything I sent was the model re-reading things it had already read.

That one chart reframes the whole category. A tool that compresses the model's answers is competing for the 7.6 percent slice. A tool that compresses terminal output is competing for a fraction of the 1.5 percent slice. And the 62 percent slice does not care about either of them. It scales with exactly one thing: the size of what you send on every request.

Still, I wanted to be fair to the biggest of the three claims. Caveman is a plugin that instructs the model to answer in compressed, telegraphic prose, and it publishes a benchmark: answers about 53 percent shorter. I ran its own ten evaluation prompts live against the API, three ways — no instruction, a terse control whose entire system prompt is 'Answer concisely.', and the terse control plus the plugin's full style — in a clean-room config so nothing else touched the measurement.

The vendor's number is honest. On a mid-tier model the style cut output 51 percent against the terse control; they claim 53. On a small model it did nothing at all — one model on ten prompts is an observation rather than a law, but it suggests that following a compression style is itself work a model has to be big enough to do. But look at the control arm, because it hides the strangest result in this audit: telling the model to answer concisely made every answer longer. Thirty-eight percent longer on the mid-tier model. The instruction primes the model to perform brevity — to add structure and commentary about being brief — instead of being brief. I have no explanation I trust, which is itself the lesson: cost intuitions about prompts are unreliable, including the obvious ones.

Now run the honest 51 percent through the actual bill. Output was $1,501 of the $19,745. Most of that is code, diffs, and tool calls, which a compressor must not touch. The compressible part — conversational prose — was 31.3 percent of output tokens, about $470. Cut it in half and you have saved $240 in eight weeks. One point two percent of the bill, with the tool performing exactly as advertised. That is the ceiling.

And the ceiling only bounds the upside. The plugin works by injecting its style instructions through hooks — a block when a session starts, a reminder on every prompt — and this is where I found my two parallel installations, faithfully injecting everything twice. Injected tokens are billed twice in a deeper sense too: once when written, then again on every later turn of the session, because they become part of the context the model re-reads. My transcripts held 16,180 injections carrying about four million tokens of instructions. Writing those tokens cost $27. The re-reads are the expensive part: each injection sits in the context for the rest of its session, so I charged every injection its own token count times the turns that followed it, at the cache-read rate — $1,270. The ledger comes to $1,297 against a ceiling of $240.

Minus $1,057, net. Even a clean single install would have carried about half the overhead — still more than double what the tool could ever save. Injection costs compound. Savings do not.

The double install raises a fair objection: if my environment was misconfigured, why trust the rest of the data? Fair question, measurable answer. The plugin came out on July 24, which handed me four clean weeks — 6.3 billion tokens with zero injections, confirmed by scanning every transcript for the hook's marker — to re-run the headline measurement on.

The clean month tells the same story, slightly louder. Cache reads took a larger share of the bill, not a smaller one. Output stayed under eight cents of every dollar. The injections were gone and the shape did not move, because the composition was never about the plugin — it is simply what an agentic environment looks like.

The other two tools never had a chance, through no fault of their own. rtk compresses verbose terminal output before it reaches the model; headroom compresses JSON-shaped context. I measured how much of my traffic they could even see.

Modern coding agents read files with built-in read and search tools, not shell pipelines. The traffic these tools were built to shrink has mostly left the building.

So the 3.7 percent post was right, and in my environment it was generous. The real lever was sitting in the settings file the whole time: disconnect the MCP servers a project does not use, prune the plugins, audit the hooks — duplicates are silent — and compact long sessions, because a session re-reads its whole history every turn. A token removed from the static prefix is saved on every request of every session. It is the only compounding in this story that works in your favor.