Context GC: fast-jev-compaction, Winnow and the Pruning Pattern
Two open-source tools use Jev to decide which old tool output an agent can forget, keeping originals verbatim. How the pruning pattern works and where it can go wrong.
Long agent sessions rot from the inside. Every grep, every cat, every failed build leaves its full output in the context window, long after anyone needs it. The usual fix is summarization: ask a model to rewrite the history shorter. That works, but it rewrites. Paths get paraphrased, error strings get softened, and the exact command you ran three steps ago becomes "the earlier build attempt."
A different approach is emerging around Jev, TypeSafe AI's decision model that returns typed scores and choices rather than prose. Instead of writing a summary, ask Jev a yes/no question about each piece of old output, and let ordinary code delete, truncate or keep it. The originals that survive are untouched. This article looks at two projects built on that idea, fast-jev-compaction for Claude Code and Winnow, and at what they do and do not prove. Both are listed on the Awesome Jev radar.
Key Takeaways
- Pruning beats rewriting for exact content. Both tools keep surviving text verbatim, so paths, errors and commands are not paraphrased.
- Jev answers questions; code applies policy. The model returns probabilities, and thresholds you can inspect decide what gets dropped.
- fast-jev-compaction is the popular one. It had 2,645 stars as of September 2026. Winnow had 13. Adoption and evidence are very different things.
- A probability is not proof. fast-jev-compaction's own README says so. The agent can re-run a tool if something useful was dropped.
- No savings figure is independently verified. Numbers in the READMEs are the authors' own.
The pattern: score, threshold, act
Both projects follow the same three steps.
- Ask. For each old tool call or output block, pose a yes/no question to Jev: is this still relevant to the current task?
- Threshold. Turn the returned probability into an action using a configurable cutoff.
- Act locally. Plain code keeps, truncates or removes the item. No text is generated.
That split is the point. A text model doing compaction can hallucinate a detail. A typed decision cannot invent a file path, because it never writes one. Its failure mode is different: it can be wrong about relevance. If you want the background on why typed outputs suit this job, see Typed Decisions vs Free Text.
fast-jev-compaction: prune the tool history
fast-jev-compaction (listed on the site as fast-jev-compaction) targets Claude Code's compaction step. Per its README, for each non-pinned tool call Jev answers two questions: does the call still matter, and should its result stay verbatim? The tiers:
- Result score meets the threshold: keep the call and the result.
- Otherwise, if the call score meets it: keep the call and truncate the result to its first
truncateHeadCharscharacters plus a one-line note. - Otherwise: remove the call and its result together.
Only tool calls and results are candidates. User messages are never removed from the output.
Requests are split so the state plus the questions stay under maxRequestTokens, which defaults to 30k, below Jev's 32k request limit. The full state is resent with each request, requests run concurrently, and answers are merged. When the state won't fit, the tool reduces it in stages: truncating tool inputs, abridging long text, collapsing old messages into notes, and so on.
The README is candid about the risk: "A probability is not a proof that a result is safe to delete. The assistant can always re-run the tool." It also admits the tool can delete things it shouldn't. The animated demo in the README is a scripted illustration that does not call the API.
Winnow: hide noisy output, keep a recall key
Winnow (on aiskill.market) works one level lower, on individual outputs. It intercepts Read, Bash and Grep results over 1,500 characters by default, splits them into roughly 25-line blocks, and asks one question per block: is this needed for the current task?
Blocks judged unlikely to matter are replaced with a three-line stub containing what was hidden, a summary and a recall key. The full text is cached locally in ~/.winnow/cache/, and you can retrieve it with winnow_recall or winnow recall <key> --start 41 --end 188.
Two safety gates apply: if the output shows an error, nothing is hidden, and blocks scoring between the drop threshold (default 0.1) and the keep threshold (0.5) are kept verbatim. Drop only the confidently irrelevant.
Winnow also supports a Claude Haiku 4.5 adapter for the judge, but the README notes those probabilities are not calibrated. The maintainer reports on 300 real cases with 97 hand labels that the judge hides about 5% of text while staying clean below 0.1. That is a small, self-reported evaluation, and this site has not retested it.
What the evidence does and doesn't show
| Claim | Status |
|---|---|
| Surviving text stays verbatim | Stated design in both READMEs |
| Threshold logic is inspectable | Documented in both |
| Winnow: ~5% hidden, clean below 0.1 | Author's hand-labeled set of 97; not independently retested |
| Token or cost savings in practice | No controlled comparison found |
| Never drops something you need later | Explicitly not guaranteed |
Winnow's repository was created on 16 September 2026, two days before this article. fast-jev-compaction's star count is large for a repo that new, but stars measure attention, not correctness. Treat both as promising, early tools.
What to do next
- Try it on a throwaway session first. Run either tool on a long debugging session and diff what got pruned against what you later needed.
- Start conservative. Winnow's 0.1 drop threshold is the low-risk default. Raise it only after you have seen what gets hidden.
- Know your recovery path. With Winnow, that is the recall key. With fast-jev-compaction, it is re-running the tool.
- Read the sibling implementations in One Idea, Four Agents, and learn how to judge thin evidence in How to Evaluate Jev Projects Honestly.