Four hours, 8.4 million tokens in, 2.9 million compressed away. Nothing lost.

Coding agents haul enormous backpacks: file dumps, logs, test output, the same page re-read five times. Most of it gets re-billed every single turn. prefex runs a crew of specialized compactors on that backpack before it reaches the model.

We tabulated one ordinary 4-hour window straight from the compression_analysis table. No cherry-picking. Every event landed in one of the four lanes below, so the totals reconcile exactly.

Four compactors, each doing its job

Of every 100 tokens the agent produced, 34 never had to be paid for as raw text.

Two details matter more than the totals

First, each scheme performed to spec. The ML compactor's ~29% trim, the crusher's ~40%, the log squeezer's ~75%, and stale-read stubbing at ~97% are all inside each compactor's designed band. Predictable machines, not magic.

Second, everything lossy leaves a claim ticket. Any lossy transform stores the original locally and drops a <<ccr:HASH>> marker in its place. The model itself can pull the full text back mid-conversation if it ever needs it. In four hours of trimming, not one answer went without something it needed.

How to read "trim rate"

Trim rate is (tokens_in − tokens_out) / tokens_in: how hard a lane squeezes. Aggregated across all four lanes it becomes the effective compaction rate: the fraction of the agent's raw token output that never reached the model as-is. It's window-dependent because content mix changes hour to hour, so we always quote it from the DB for the exact window shown.