Trimming an agent's context to save money is such an obvious win that almost nobody bills it out. This team did — 2,848 paid runs, about $643. An arm that sent 38% fewer tool-output tokens cost 6.8% more, not less, because roughly 80% of the bill is not fresh tokens at all: it is the cached conversation prefix, re-read on every model call. Cut a token and you barely touch that; compress too hard and the agent searches again, adds turns, and re-transmits the whole prefix — so the meter climbs.
It feels like an identity: fewer tokens, smaller invoice. But when you meter a real coding agent against its provider's cost ledger, per-task token reduction and cost change barely move together — the correlation is near zero. The reason is where the money actually goes. Here is the billed cost of 2,848 runs, broken into what you paid for.
Fresh tokens — the generated output plus the uncached input — are barely a tenth of the bill. The thing you optimise when you trim tool output lives in that sliver. The rest is cache traffic: writing the conversation into the cache once, then reading it back on every subsequent call.
With prompt caching, a delivered token is paid for twice over. Once, when it is written into the cache — about 1.25× the input price. Then a small 0.1× every time a later model call re-reads the cached prefix to keep going. So a token's true cost depends on when in the run it arrives: an early token is re-read by every turn after it; a late one by almost none. Drag the run length and the arrival point and watch the multiplier.
This is why cache reads pile up: a typical run re-reads roughly 117,000 cached tokens but generates only about 700. The bill is dominated by re-reading context you already sent, and that total scales with the number of turns — not with how tightly you compressed any single response.
Here is the part the token counter never shows you. Cut lightly and you shave a little off the sliver — roughly free. Cut hard and you strip out context the agent needed, so it searches again, takes extra turns, and re-transmits the whole cached prefix on each one. Those recovery turns cost far more than the tokens you removed. Slide the compression up and watch the two numbers pull apart.
The curve dips slightly, then turns and climbs. A little compression is roughly free because it trims the sliver without breaking anything; past that, every extra percent you strip buys you recovery turns whose cache re-reads dwarf the saving. At 38% removed the paper's aggressive arm sat at +6.8% cost.
The campaign block-randomised four handling arms across identical fresh copies of each task, then read the real provider bill. Measured by cost per successful task — not per run, not per token — the compressors did not win. Step through the arms.
The arm that removed 38% of tool-output tokens (RTK-ML) landed slightly above baseline, not below. The proxy that rewrote traffic at the API boundary (Headroom) cost 46% more for no measured quality gain. Only the lightest, deterministic compression came out roughly neutral — and that is the ceiling on the whole idea, not the floor.
Set your agent's daily run volume and how many turns a run takes, then choose what you do with context. Blanket compression applies the paper's measured penalty; grounding — handing the agent byte-exact context at the right lines instead of a squeezed view of everything — stands in for the cheaper-per-fix path the paper found. The turn count matters because cache re-reads scale with it. Treat the totals as illustrative.
The workbench point stands on its own: the only way to know whether a context layer earns its keep is to bill it against real runs and count solved tasks. A token counter will tell you a clean, confident, wrong story.