Pruning and summarization make different tradeoffs
A summary rewrites material into a shorter account. Pruning removes or truncates selected material while leaving retained spans as written. Neither approach guarantees that a later task will have every necessary fact.
The useful question is not only “How much smaller is the context?” It is also “Can the agent still recover the exact constraint, failure, file path or result it needs next?” Keep the original history recoverable when experimenting with either approach.
Two documented Jev compaction approaches
fast-jev-compaction describes scoring tool calls and results, dropping or truncating stale material and keeping retained text verbatim. Its README distinguishes the library and Claude Code plugin surfaces.
HAR5HA-7663/jev-compact describes local cleanup rules first, followed by Jev ranking when more reduction is needed. Local rule processing and a remote model judgment have different data flows. The claim that a first step is local does not establish that the entire compaction process is offline.
Hermes and Pi toolkits can include additional context modules. Verify the current host integration, which message types are retained, and what happens when an API call fails. Do not treat all repositories named “compact” as the same implementation.
Define a retention contract
Before choosing thresholds, identify what the current task must preserve. A practical contract includes:
- The user's objective, later corrections and authorization boundaries.
- Current files, outstanding changes and unresolved errors.
- The exact test result or source evidence supporting the next action.
- Paths and identifiers needed to recover previously inspected material.
- Open decisions and the reason a previous attempt failed.
Use deterministic preservation rules for requirements that must survive. A relevance score is an input to the retention policy, not authority to discard the user's constraints. If a tool replaces deleted content with stubs, check whether those stubs identify a real recovery location.
Evaluate on tasks that need earlier evidence
Replay the same saved task history under an unchanged baseline and the compaction candidate. Include cases where an important result appears early, a later correction changes the objective, or the agent must reopen an exact earlier error. These cases reveal losses that a simple token count misses.
| Measure | Why it matters |
|---|---|
| Context tokens before and after | Shows the amount of reduction. |
| Required facts retained | Checks the retention contract directly. |
| Completion and recovery success | Shows whether a smaller context still supports the task. |
| Additional retrieval and retries | Captures work caused by missing context. |
| End-to-end latency and cost | Includes compaction calls and downstream work. |
Choose a recoverable failure path
For an initial rollout, retain the baseline history if the model call or response validation fails. Check how the selected integration handles timeouts, malformed answers and insufficient context. The official Jev 1.13 notes explain that irrelevant context and adversarial material can affect judgments.
When the task needs new source material rather than less history, a retrieval workflow may address the problem more directly. Compaction, retrieval and persistent memory are related tools, but each solves a different part of context management.