Second episode of Spending Less on AI. The first one — Headroom: the editor between you and the model — described what the tool promises and set it up. This one reports what the receipts say. Next week, episode three: the same tool, configured the way its documentation describes rather than the way I improvised.
Eight days ago I put a proxy between my coding agent and the model, wrote down the rules of the test before the first request went through, and promised to publish what the receipts said. This is that.
The short version: it saved $439, and roughly $1,200 came back on another line of the same invoice.
Both halves are real. Understanding how they can both be true is the whole point of this episode, and it is worth more than either number.
What it did, exactly as advertised
Six days of ordinary work. 3,994 requests, each one logged with what went in before the proxy touched it and what went out after.
6.4% less text sent to the model. On claude-opus-5, which carries 91% of
what I spend, the proxy’s own ledger puts the saving at $438.94. That is not
a vendor estimate and it is not my arithmetic — it is the tool’s accounting of
its own work, and my request log agrees with it.
The editor did his job. He shortened the dossier before it went out the door.
And the invoice went the other way
Here is the part I did not see coming.
An agent has no memory, so every step re-sends the whole conversation. The provider stores that conversation and charges very little to read it back — a tenth of the base rate. Storing it fresh costs 1.25× the base rate. Between reusing what is stored and storing it again there is a factor of twelve and a half, for the same words.
The proxy shrinks the message by editing the beginning of it: the tool definitions, the catalogue, the instructions that sit before everything else. And the beginning of the message is exactly what the cache uses as its key. Change one byte there and nothing after it can be reused. The whole conversation gets stored again, at the expensive rate.
Worse, the amount it trims varies from request to request — twenty-eight tools deferred on one call, twenty-one on the next, six on the one after. The prefix never settles. So the cache never gets a chance to pay off.
What that looks like day by day:
That is the whole mechanism. Less text, more money, no contradiction.
The rules I wrote before I measured
Episode one committed to three numbers in advance, precisely so that I could not bend them afterwards. Here is the scorecard.
| The rule I set | What the receipts say | |
|---|---|---|
| Tokens per request fall by 15% or more | 6.4% | missed |
| Re-reads and retrievals rise by no more than a fifth | re-reads fell 31%; retrievals were 28 events in 3,994 requests | met |
| Added latency under 4 seconds at the ninetieth percentile | 9.5 seconds (p99: 31s) | missed |
Two of three missed, and the rule I wrote said what to do in that case: fall back to cache mode or lossless compaction, and say so. I am saying so.
The part that actually taught me something
Look again at the middle row. It passed.
Re-reads did not rise — they fell, by nearly a third. Retrievals were a rounding error. By the letter of my own rule, that criterion was met, and if I had only watched what I said I would watch, I would have concluded that the editor was behaving well.
Meanwhile, re-writes per request rose 527%.
I built a rule to stop myself from moving the goalposts, and the rule had a blind spot exactly where the money went. I was watching the cheap half of the cache and had written nothing about the expensive half.
If you take one thing from this episode, take that one. Not “compression proxies are bad” — they are not. The measurement you design before the experiment is itself a hypothesis, and it can be wrong in ways the experiment will not tell you about. Mine was.
Where it does work
The same tool, the same week, three different models:
Six to eight times more effective on the cheap models than on the expensive one — and the expensive one is where practically all the money is.
That is not a flaw in the tool, it is a mismatch between where it can reach and where my spend lives. My sessions on the big model are long, and what fills them is the accumulated conversation, not tool output. Across the whole period, tool results were under 1% of the traffic. A proxy that compresses tool output cannot move a number that is dominated by the conversation being re-read.
On short, cheap, disposable work — a subagent that reads three files and answers — it does very well indeed.
What I did not run
I have to be straight about the scope of this verdict, because it is narrower than the headline.
I ran the basic setup: start the proxy, point the agent at it, protect file contents from compression, truncate tool descriptions. That is what episode one described, and it is what I measured.
It is not what the documentation describes. Four of the tool’s capabilities were never switched on, and one of them reduces the answer rather than the question — the output side, which on the expensive model costs five times what input costs, and which in my case has never produced a single measurement. The routing is also incomplete: some of my sessions bypassed the proxy entirely, which means these numbers understate the traffic and overstate the tool’s share of the damage at the same time.
So this is a reading of my configuration. It is not a verdict on the tool.
Before you buy efficiency for your own AI spend
Five questions, in the order I wish I had asked them.
Which unit does it optimise, and is that the unit on your invoice? Tokens, requests, context window and dollars are four different things, and an optimisation can win on one while losing on another.
If it touches the start of the prompt, measure the cache. Anything that rewrites the prefix invalidates everything after it. Watch stored-again against reused, not just total volume.
Compare money on comparable days. My first attempt at this analysis announced an 18% improvement that evaporated the moment I controlled for how the days were structured. Percentages of text are easy and misleading; dollars per comparable unit of work are harder and honest.
Aim it where the spend actually is. If 90% of your bill is one model, a tool that performs beautifully on the other 10% will not show up on the invoice.
Set a ceiling before you switch anything on. I had none. An optimisation that silently costs more is exactly the failure mode a ceiling catches.
Episode three
Next week, the same tool, configured the way its documentation describes: the output reducer switched on, routing made durable so that every session actually goes through it, the work aimed at the models where it already performs, and a spending ceiling in place.
Then I measure again and publish that number too, whichever way it goes. If it earns the chair, I will say so. It has not earned it yet.
Versions: Headroom 0.36.5, Claude Code 2.1.278, September 2026. The numbers come from my own Claude Code transcripts and the proxy’s request log, on one real project that is not the subject and is not named. The $439 and the percentages are measured; the ~$1,200 and the ~−$750 net are estimates — three independent scopes put the excess between $1,110 and $1,271, and 290 idle gaps longer than an hour over the period break the cache on their own, which makes that figure an upper bound on what the proxy alone cost.