Skip to content

the arithmetic

Removing half your conversation does not halve your bill

It is not obvious that it lowers it at all.

Cache reads bill at 0.1× and writes at 1.25× (five-minute) or 2× (one hour). Matching is exact and prefix-ordered, so an edit invalidates everything after the cut point.

break-even

What a cut costs and what it earns

Let S be the suffix after the cut and D the bytes removed from it. The edit pays 1.9·S − 2·D once, and earns 0.1·D back on every later turn. Neither term is a rate you can shop for: both fall out of how the API prices a cached prefix.

Cut half the suffix and it pays for itself in 18 turns. Cut a tenth and it needs 170 more turns than the session has had — and in the corpus that was measured, only 807 turns out of 11,422 sat past index 160 at all.

The formula is model-independent and absolute size cancels. S/D decides, not the size of the session: a big session is not automatically worth pruning.

T* = 19·(S/D) − 20

further turns, before the cut has paid for itself.

The 2.0× is not the list-price assumption. It is a measurement over 26,194 turns of one install where every main-thread turn wrote at the one-hour class, and it is recorded outside this repository.

Illustration of when a context cut pays for itself. Bars measure the further turns a cut must survive, against the README's worked half cut of 18. Removing a tenth of the suffix needs 170 turns and removing a quarter needs 56, both past it; removing a half needs exactly 18 and removing two thirds needs 9. The same half cut taken immediately before a resume needs none, because the resume was going to rewrite that suffix anyway. The intake filter has no break-even at all. Illustration, on an invented 120,000-token suffix. The arithmetic is the README's: a cache read bills at 0.1× and the one-hour write it measured over 26,194 turns bills at 2.0×, so an edit pays 1.9·S − 2·D once and earns 0.1·D a turn back. S/D decides — the same four bars are drawn for a session ten times the size.

the intake filter

The one position that pays nothing

The pruner edits a conversation that is already cached, so it pays 1.9·S − 2·D once. The only way not to pay that is to never let the bytes into the cached prefix.

Per result of D tokens over T following turns, the baseline is a 2.0× cache write plus a 0.1× read on every later turn. The filter pays 1.0× once and nothing after. There is no break-even term — it is cheaper from the first request, at every S/D, which is the one thing the pruner cannot say.

It reaches less, because only the rules needing no hindsight can fire — C1, C3 and B2. C2, B1 and A1 all need to see the conversation's future, and a policy that did would change the prefix under the cache.

position

There is exactly one moment when the edit is free

Immediately before a handover that was going to rewrite the suffix anyway, the 2·D term is refunded. winnow acts at resume boundaries for this reason, not out of caution.

That is also why the deliverable is a comparison rather than a saving. Every existing tool reports bytes or tokens removed; none reports the netted cost, and none has ever been measured against task quality.

This arithmetic was got wrong here once, by assuming the 1.25× multiplier from the documentation instead of reading the measurement. That version understated invalidation by about 40 percent, and section 3.1 of docs/COZEMPIC.md keeps the error on the record — it is exactly the mistake the measurement exists to catch.