Token Optimizer MCP

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 <<ccr:...>> marker. The same is true of the four rows where they edge us out in the nineties.