ooples/token-optimizer-mcp

Compression that optimises your bill, not your byte count —
and ships the benchmark so you can check it.
One local ledger for optimizer tools, live-graph substitutions, every agent, and the graph's own cost.
---
Why it wins
Providers cache the prompt prefix: cached tokens re-read at **0.1x**, rewritten
ones bill at **1.25x**. Most compressors optimise bytes removed and ignore that
multiplier. This one optimises the bill.
**It wins both columns, against their real implementation, on their own
fixtures.** Not a reimplementation and not our fixtures: their harness compresses
the payload, dumps it, their resolver redeems their own markers, and ours is
handed the identical bytes.
| workload | payload | theirs | ours | ours, preset | ours, dial on | zero-turn ids |
| -------------------- | ------: | ------------: | ------------: | --------------: | --------------- | -------------: |
| agent-loop | 172,110 | 41.9% / 46.7% | 93.8% / 94.7% | 93.8% / 94.7% | 100.0% / 100.0% | 69 / 254 / 69 |
| agent-loop-logs | 328,490 | 51.3% / 45.8% | 96.3% / 97.1% | 96.3% / 97.1% | 100.0% / 100.0% | 87 / 2042 / 87 |
| browser-session | 782,294 | 21.8% / 13.6% | 93.7% / 28.9% | 100.0% / 99.9% | 100.0% / 99.9% | 336 / 336 / 0 |
| code-search | 131,444 | 47.5% / 53.5% | 95.8% / 96.5% | 95.8% / 96.5% | 99.9% / 99.9% | 65 / 470 / 65 |
| codebase-exploration | 136,113 | 99.7% / 99.6% | 65.1% / 58.0% | 100.0% / 99.9% | 100.0% / 99.9% | 509 / 5 / 0 |
| grep-output | 75,399 | 99.6% / 99.6% | 57.4% / 52.8% | 99.9% / 99.9% | 99.9% / 99.9% | 1046 / 4 / 0 |
| human-authored-json | 38,645 | 32.8% / 31.3% | 96.9% / 97.2% | 96.9% / 97.2% | 99.8% / 99.9% | 18 / 174 / 18 |
| issue-triage | 109,534 | 53.1% / 54.4% | 95.3% / 95.9% | 95.3% / 95.9% | 99.9% / 99.9% | 34 / 504 / 34 |
| raw-build-log | 158,237 | 99.8% / 99.8% | 70.7% / 47.7% | 100.0% / 100.0% | 100.0% / 100.0% | 430 / 3 / 0 |
| relevance-probe | 49,367 | 64.3% / 65.4% | 96.1% / 97.0% | 96.1% / 97.0% | 99.9% / 99.9% | 24 / 527 / 24 |
| repeated-reads | 152,321 | 22.8% / 20.5% | 74.3% / 69.7% | 100.0% / 100.0% | 100.0% / 100.0% | 361 / 405 / 0 |
| sre-debugging | 312,456 | 88.4% / 90.5% | 97.1% / 97.7% | 97.1% / 97.7% | 100.0% / 100.0% | 89 / 514 / 89 |
Recorded 2026-09-25 at 18a2d085, by the command in the
record's regenerate field. That second arm runs HeadRoom itself, so CI does not
re-derive it the way it re-derives the table below -- it checks this provenance and
these figures against bench/compression/headroom/results/head-to-head.json instead.
Over the corpus the shipped default takes **89.4%** of the characters and
**80.9%** of the tokens; theirs takes 51.3% and 62.8%. Of the 9,919 identifiers
planted in the corpus, 45 end up unrecoverable on our side and 8 on theirs.
**Read the rows, though, because the ones we lose are not compression
results.** On grep-output, codebase-exploration and raw-build-log they
report ~99.7% and we report 57-71%. Their number there is a **content-cache
reference**: the block is not made smaller, it is taken out of the request, put
in a store, and replaced by a 24-character > marker. The same is true
of the four rows where they edge us out in the nineties.
**So the last column is the one that decides a turn.** A marker is not the
content: to read what it stands for, the agent spends a request. zero-turn ids
counts the identifiers planted in each workload that need no such request --
still in the text, or rebuildable from the text alone. On the three rows we
lose on reduction we take that column outright, 509-5, 1046-4 and 430-3: their
marker leaves almost none of it behind, our skeleton leaves all of it. **We lose it on
eight rows** -- agent-loop, agent-loop-logs, code-search,
human-authored-json, issue-triage, relevance-probe, repeated-reads and
sre-debugging -- because our reduction there comes from spilling too, and a
spill costs the same turn theirs does; browser-session ties at 336-336. Over
the corpus it is 3,068 of 9,919 for us against 5,238 for them: **this column
goes to them**, and the two columns have to be read together or each one
flatters somebody.
The unit count moved with the instrument, not with the product. Every rule that
found a retention unit keyed on a digit-bearing token, a markdown heading or a
declaration, so issue-triage ("number": 3000) and relevance-probe
("id": "evt_0", the needle that workload exists to find) each scored ZERO
units and reported a tie on an empty set. Counting a string value under an
object key and a quoted substring inside a longer string -- on both arms, and
excluding multi-line values, which are not literal substrings of the block they
came from -- takes the corpus from 6,098 units to 9,919 and reverses this