fast-jev-compaction Replaces Summaries With Verbatim Context

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

An exact error string is often worth more than a neat recap, which is why tamaratran's fast-jev-compaction is interesting. The project replaces Claude Code's compaction summary with a Jev-based pass over tool calls and tool results, then keeps surviving text in its original wording.

For a Claude Code workflow, that is a sharp choice. The old question was whether the model could summarize this chat well enough. This project asks a narrower question: which tool call and result pairs no longer need to be in the context at all?

Keep the evidence, or remove it

fast-jev-compaction treats tool use as pairs. Every tool_use is matched to its tool_result by tool_use_id. Calls in the first message and in the newest preserveRecentMessages messages are pinned.

Then Jev sees the whole conversation oldest first, with tool results replaced by short notes in the state it judges. It scores which pairs still matter. Stale pairs can be dropped, results can be shortened, or pairs can stay.

The important part is that it does not rewrite user and assistant messages. An exact error, file path, command, or constraint that remains does not come back as a paraphrase.

Notice the bet it makes

Most context compaction trades volume for narration. The summary may mention a build error and lose the one character that mattered in src/generated/client.ts.

This repo makes a different bet. If the old shell output is not useful, delete it. If it is useful, keep the wording.

In the fast-jev-compaction repo itself, that distinction matters because the project has package code in src/ and Claude Code plugin code in hooks/ and .claude-plugin/. If a session bounces between library behavior and hook behavior, a summary that says “updated the plugin” is much weaker than the actual path and failing command.

Author-reported repo facts make this more than a sketch: mainly TypeScript, MIT licensed, usable as an npm package and as a Claude Code plugin, and listed with 6,137 GitHub stars in the supplied source snapshot. I would still treat the star count as interest, not proof that the compaction choice is safe for your repo.

Check what can still go wrong

The hard part is not compression. The hard part is removing exactly the things that will never matter again.

A coding agent often returns to old evidence late. It may hit a new failure that only makes sense if the earlier command output, database migration name, or generated-file path is still available. This is where compacted context earns trust or loses it.

The README describes scoring every tool call and result in one fast request, but removal and truncation are not a one-request guarantee for every history. Long histories, hook behavior, and repeated compaction points can still mean multiple requests over the life of a session.

There is also a quiet asymmetry. User and assistant messages stay verbatim, so task instructions survive, but noisy human messages survive too. If your Claude Code conventions put durable rules in the conversation instead of a maintained project artifact or skill, compaction will not clean that up for you.

Try the old-error test first

I would test fast-jev-compaction with a task that must return to earlier evidence. This belongs in Review in our methodology: do not judge the agent by whether the chat got shorter, judge it by whether the next edit used the right old fact.

Use a small repo where you can reset the branch. A good fit is a TypeScript service with a failing generated-client import, because file paths and exact module names are easy to lose in summaries.

Run a session like this:

1. Ask Claude Code to run the failing test or build.
2. Make sure the output includes one exact error, for example Cannot find module '../generated/client' from a specific test file.
3. Move on to two or three unrelated edits that create enough tool output to compact.
4. Ask Claude to fix the original failure without re-running the initial command first.
5. Check whether it names the same file path and error before editing.
6. Only then let it re-run tests and finish the repair.

Put that pass/fail rule beside your Team conventions, not as a law, but as a local test for this repo. If the agent cannot recover the earlier evidence, smaller context did not help.

What changed and what to test

This is also the line between compaction and logging. If you need a record of what Claude did for later review, compaction is the wrong primary tool; I covered that neighboring problem in homestead-memory Logs Claude Tool Calls.

Further reading

• Claude Code docs
• Claude Code skills
• fast-jev-compaction on GitHub

Run one disposable-branch check

Try fast-jev-compaction on one resettable branch with the old-error test above. Keep it only if Claude Code can recover the exact earlier evidence without being reminded.