Proof and receipts

Every number Compaction shows was measured on real end-to-end sessions — real token counts from real runs, not projections — and every figure carries the label of how it was measured. This page is the methodology.

The per-turn line

Every measured turn produces one content-free line. It is the same line everywhere, built by one renderer:

compaction · observed input 1,309 · output 20 · basic shaping · id 8e46224f
compaction · input 75,777→51,720 (−32%) · output 115→61 (−47%, est. · default prior) · id 7ac17b88

Reading it left to right:

input — observed input N is a plain count: nothing was done to the input on that turn. input B→A (−PP%) appears only when input optimization actually ran; both endpoints are measured, which is why that percentage carries no estimate label. input paused appears at the Community allowance ceiling — the axis is replaced rather than filled with a number that would not be true.
output — output N is the count the provider reported. output B→A (−PP%, est.) adds a “before” that is derived, never observed, so it always carries a label: est. means the rate came from this device’s own A/B, and est. · default prior means it came from the rate Compaction ships with.
tier — apply off, basic shaping, or full apply: what posture actually produced this turn.
id — the short receipt id, so any line can be traced back to its receipt.

Any clause whose axis is unavailable is left out rather than filled in. Where each surface shows the line:

Claude Code — in the status line, every turn.
Codex — returned by a Stop hook as a system message; compaction watch is the surface that always shows it.
Cursor — Cursor has no channel that displays a per-turn line, so its numbers reach you through compaction watch and compaction status. Cursor counts are local estimates and say so.
Gateway — inline in the gateway log, plus the receipt.

To silence the line without losing the measurement, set COMPACTION_RECEIPT_LINE=0 — receipts are still written.

The numbers

Output: up to ~50–70% fewer output tokens on coding tasks — measured in a real A/B on Claude coding sessions, provider-reported, with quality held (eval-gated). Task-dependent.
Input, uncached: ~48–50% less billed input on uncached API sessions — measured on real gateway end-to-end runs, provider-reported.
Input, cached: ~5–10% less input on cached sessions — the provider’s cache already covers most of the input there, so the bigger cached-session win is headroom: the session fits under the context ceiling longer.
Bill impact: for API-key usage, fewer tokens are directly a smaller bill — the provider prices every token, and output tokens are billed at full price.

Methodology

Output shaping. The 50–70% figure comes from a real A/B on Claude coding tasks: same tasks with and without the shaping instruction, output tokens read from the provider’s own usage fields, and answer quality checked by an eval gate before the figure is claimed. Shaping targets the code/answer regime only — planning, reasoning, and extended-thinking turns are held, never shaped. The effect is task-dependent: verbose-by-default outputs shrink the most, and an already-terse output can be 0% — there was nothing to remove. The same instruction ships for Codex and Cursor; per-tool end-to-end figures for those tools land once measured there.

Input compaction. Measured on real gateway end-to-end sessions with the provider’s usage fields as ground truth. Where the provider reports cache usage, cache savings are measured as provider-reported fresh-input reduction — the provider’s own numbers, not a local guess. Verify it yourself:

compaction gateway verify-cache

The evidence labels

Every figure on every surface carries one of these labels:

provider-reported — read from the provider’s own usage fields (token and cache counts through the gateway). The strongest label a client-side tool can carry, and the label on the headline figures above.
local estimate — computed on your machine and labeled as such. Cursor figures are local-estimate: the session-level surface has no provider usage channel.

Cost figures are provider-reported token counts × the provider’s published prices — an exact price applied to an exact count. That is an estimate basis (your invoice is not observable from a local tool, so a cost figure is not invoice-confirmed), and each cost figure says so.

Two proof scopes, kept separate

Plan lifetime (subscription sessions) — measured token reduction supports “session/plan window likely extended”, reported as the inference it is. Plan quota itself is not observable, so quota is never turned into a figure.
Provider-priced API cost (API-key sessions) — provider-reported usage × versioned published prices, labeled with that basis.

Claim boundaries

Where our claims stop — precisely because the measurements above are real:

the measured figures are per-task token reductions, not a universal percentage of anyone’s total provider bill
plan quota is not observable, so it is never quantified
per-tool figures are claimed only where measured end-to-end (Claude today; Codex and Cursor when their measurements land)
recoverability (byte, hash, source pointer) is the guarantee on removed context; whether it mattered stays a human call