fast-jev-compaction: The Context Manager That Refuses to Summarize

The Wrong Kind of Memory

Most context managers try to help an agent remember by asking it to retell what happened. That works until the details matter: a path becomes a paraphrase, an error string gets softened, and a constraint turns into vague prose.

`fast-jev-compaction` rejects that bargain. It assumes coding agents need the exact words that carry technical meaning, and that the rest of the history is mostly noise.

That is the thesis of the repo in one sentence. Not summary. Not retrieval. Just selective deletion with a bias toward preserving the parts a future model is most likely to need exactly as they were written.

What fast-jev-compaction Actually Does

The plugin sits in Claude Code’s hook flow and looks at tool calls and tool results as paired events. For each pair, it decides whether to keep both, keep the call and trim the result, or drop the interaction entirely.

The important distinction is that it leaves user and assistant text alone. The pruning target is the tool chatter around the work, which is often where the token bloat lives.

// Conceptual shape of the decision
if (keepCall && keepResult) {
  keepBothVerbatim()
} else if (keepCall && !keepResult) {
  keepCallAndTruncateResult()
} else {
  dropInteraction()
}

That makes the project feel less like a summarizer and more like an editor with a ruthless red pen. The red pen is just smarter than most, because it is judging relevance at the level of tool actions instead of rewriting the conversation as a story.

The Jev Trick: Two Questions per Tool Call

The unusual part of the design is the split. Jev is not asked a single vague question about relevance. It is asked whether the fact that something happened matters, and whether the verbatim payload matters.

That split is why the plugin can preserve intent without preserving bulk. A tool call may be worth remembering because it proves the model already tried a path, even if the result was a giant blob that can safely be trimmed.

This is a better fit for coding sessions than narrative memory. In code work, chronology and exact strings do a lot of heavy lifting.

Why the split matters

• A call can matter even when its output is disposable.
• A result can matter even when the surrounding search or edit no longer does.
• Keeping those decisions separate reduces the chance that compaction destroys technical intent.

That is the logic behind the repo’s `noul` question pattern. It behaves like a small adjudication engine, not a summary prompt pretending to be memory.

How the Engine Fits the State Into the Model

Before Jev can score anything, the repository has to fit the conversation into a request it can actually analyze. That is where `estimateTokens` and the fallback shrinking strategy come in.

The implementation favors cheap heuristics over heavyweight tokenization. That keeps the plugin fast enough for a hook environment, where loading overhead matters as much as algorithmic elegance.

The engineering trade-off is straightforward. The repo would rather be approximately clever about budget math than drag in a dependency stack that slows every compaction cycle.

Claude Code Integration Without Heavy Machinery

The plugin is built to live inside Claude Code’s constrained hook environment, not in a roomy application server. That is why the transport layer is abstracted and the integration code maps internal messages to Claude Code session messages with as little ceremony as possible.

The hook layer also enforces a quality gate with `minReductionRatio`. If the compaction does not save enough, it gets rejected. That is a practical safeguard against spending API calls to make tiny, risky changes.

// The integration pattern in plain terms
// 1. Capture session history
// 2. Fit state for analysis
// 3. Ask Jev to score tool interactions
// 4. Drop or trim only the irrelevant parts
// 5. Reject the compaction if savings are too small

This is where the repo earns its plugin shape. It does not need heavyweight orchestration because its job is narrow: preserve useful context inside an interactive CLI session without turning the whole session into a prose document.

Why This Beats Built-in Summaries

A summary sounds helpful until you compare it to what a coding agent actually needs. Exact paths matter. Exact errors matter. The order of edits, commands, and failures matters.

Traditional recursive summarization is good at compressing meaning. It is weak at preserving the literal artifacts that often drive the next step of debugging.

The distinction is subtle but important. Retrieval can surface related context, but it does not preserve the lived order of the session. Summaries can reduce bulk, but they often mutate the evidence.

That line captures the article’s core reversal. The project does not try to write a better summary. It tries to make the wrong data disappear.

What This Suggests About Agent Memory

`fast-jev-compaction` points to a bigger pattern in agent systems: not every meta-decision needs the same model that does the main work. Sometimes a narrow classifier is the right layer for the job.

In that sense, the repo is less about Claude Code than about architecture. It treats memory management as a separate primitive, one that can be optimized for speed, fidelity, and session continuity rather than linguistic elegance.

That is a useful mental model for agent builders. The next breakthrough in memory may not be a smarter summary. It may be a more disciplined way to decide what is allowed to vanish.