jev-pruner

How we reviewed this: we ran its full test suite in Docker on Node 24 with no network, read the code that builds each request, and checked its retention rules against the documentation. We did not run it inside a live Claude Code or Codex session — that needs an early-access hook feature and a paid account — so everything here comes from the code and its own tests.

What it does

jev-pruner, by Tamara Tran, hooks the moment a Bash command finishes inside a coding agent and trims the output before the model sees it. Long test runs, installs and builds spend thousands of tokens on progress bars; this keeps the lines that matter.

Code does most of the work. Output under a token floor is passed through untouched. Documents, source files, JSON, diffs and the output of commands like cat, jq and git diff are protected whole. Diagnostic and result lines — warnings, failures, test totals, exit status, artifact paths — are kept by pattern, with their surrounding context. What’s left is chunked, and each chunk gets one Noul question:

Chunk c03 contains at least one line that should remain available to the agent for its ongoing task. […] Uncertain or unclassified information is needed unless every line is confidently disposable.

That last clause is the design in miniature: the default is to keep. A chunk survives if any history segment votes to keep it, unscored chunks survive, refinement failures survive, and request failures return the original output verbatim.

Its test suite is the most thorough we’ve run in this ecosystem: 276 tests across 20 files, all passing offline, including six that assert the output is returned byte-for-byte unchanged when the API answers 401, 429, 5xx, invalid JSON, missing answers or missing scores.

What it sends

The request state is built in stateFor(), and it is worth reading closely:

return {
  context: OUTPUT_CONTEXT,
  ...(category === 'build' || category === 'search' ? { category, categoryGuidance } : {}),
  task: input.goal,
  history,
  command: input.command,
  diagnosticsAndResults,
  chunks: chunks.map(({ id, text }) => ({ id, text })),
};

So each request carries the command you ran, the task, the chunks of raw output, a de-duplicated list of every diagnostic and result line, and history — the recent conversation, including tool calls and their results. Nothing is redacted. If your build log prints a token, or an earlier tool call read a credentials file, that text is in the request.

The README is candid about a related point: its “does this command look like it touches secrets” check (commands matching secret, password, token, netrc, id_rsa and friends) only suppresses the local archive copy — it does not redact anything and does not stop the upload. Worth knowing that the same check has a wide net: an ordinary rg -n token src/ matches, so that command’s output is pruned without the local archive you would otherwise use to recover the dropped lines.

Elsewhere the handling is clean: the key is read from plugin options or the environment, only ever sent as a bearer header, and we found no path that logs it. On Codex the archive is written with restrictive permissions; on Claude Code the host’s write API doesn’t accept a mode, so the archive lands under your umask.

Two things that don’t match the dial

keepThreshold above 0.1 does nothing. The retention rule is:

export function keepScore(score: number, threshold: number): boolean {
  return score >= threshold || score > MAX_DISPOSABLE_KEEP_PROBABILITY; // 0.1
}

Any chunk scoring above 0.1 is kept regardless of your threshold, so setting it to 0.9 prunes no more than 0.5 does. The README documents this safeguard plainly in two places — “removal requires a keep probability at most 0.1 and below keepThreshold” — but the plugin manifest, which is what a configuration UI shows you, says only “Minimum Jev probability for a Bash output chunk to stay visible”. Follow the README, not the dial.

There is no timeout on the Claude Code path. Codex requests abort after 30 seconds, and the README’s 30-second promise sits in the Codex section. The Claude hook uses the host’s fetch, whose options don’t include a timeout, and no abort controller is set up — so a hung request waits on whatever the host does, with up to a dozen requests in flight for one command.

Neither is dangerous: failure is fail-open, and the worst case is that you get the untrimmed output you would have had anyway. Both are reported upstream.

Maintenance

136 commits since September 18, MIT licensed, ten open pull requests, no open issues, published under the name fast-jev-output (the README explains the rename). It needs Claude Code’s early-access function hooks, or Codex CLI 0.152.1+. The quality of the test suite, and the fact that the failure modes are the ones under test, say more about this project than its age does.

Verdict

The judgment call here is unusually well-posed: not “summarize this”, but “does this chunk contain a line the agent still needs”, asked with code holding on to everything that looks like an error, a result or a document. Everything about the retention logic leans toward keeping, and the failure paths return your output untouched.

What to weigh: the whole output and your recent conversation go to TypeSafe on every long command, with no redaction. On a machine where build logs and tool results are boring, that’s a fine trade for the context you get back. On one where they aren’t, it isn’t.

For the other end of the same problem, see fast-jev-compaction, by the same author, which trims the conversation rather than the command output, and compact-adviser, which decides when to compact.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.