Question 1

Does pruning every request wreck the prompt cache?

Accepted Answer

That is why compaction-only is the default. Rewriting part of a normal request's message prefix invalidates the provider's prompt cache from the mutation point, so the suffix is re-read at full price while the removed tokens would only have saved the cached-read price. A compaction request is the one case where nothing is reused afterwards, and its input is the biggest single request in a session, so pruning there cuts the most expensive call for free. If your provider does not cache prompts, per-request mode is a pure win.

Question 2

How do I know it is not deleting my history?

Accepted Answer

Decisions are applied to clones of the messages and tool parts, never to the originals, and the README says tests enforce that. Only the request view handed to the provider is replaced, so persisted history and the UI keep everything, and if the runtime rejects the replacement array the plugin does nothing. Everything is fail-open, including any error mid-run.

Question 3

What does it cost on a long session?

Accepted Answer

The README reports one measured session of 530 messages in which 257 tool calls were judged across seven batches with a fitted state of 24,974 tokens, dropping 257 calls and 257 results and removing 282 messages, in 1,135 ms, after which the model replied normally. Because verdicts are cached per tool_use_id, a request with no new tool calls makes no Jev request at all.

Question 4

Why is the keep threshold 0.15 when upstream uses 0.5?

Accepted Answer

Because the port measures what old calls actually score: keepCall between 0.17 and 0.23, keepResult between 0.11 and 0.14 on a realistic transcript. At 0.5, and even at 0.3, every unpinned call becomes drop_call, which throws away the call and its input along with the bulky output. At 0.15 the common outcome is drop_result, keeping the call and truncating the result text with a note. Set keepThreshold to 0.5 if you want the original aggressive behaviour.

Question 5

How do I install it, and what does it need?

Accepted Answer

Run `opencode plugin add opencode-context-pruner` and export TYPESAFE_API_KEY, or symlink a local clone into ~/.config/opencode/plugins/opencode-context-pruner. The key is read from the OpenCode server environment or from ~/.config/opencode/typesafe/api_key. It requires OpenCode V2 beta 0.0.0-beta-19271 or newer, and compaction requests are pruned directly on the 2.0.x line.

Question 6

What are the other tuning knobs besides the keep threshold?

Accepted Answer

preserveRecentMessages defaults to 10, so the newest messages are never judged. minResultChars is 4000, which skips the request entirely when there is less tool output than that. truncateHeadChars is 300, kept when a result is truncated, and maxStateTokens and maxRequestTokens cap state fitting at 25000 and 30000. The model is pinned to jev-1.13.0 and rejudge defaults to never.

Question 7

Where does the code come from, and what license is it under?

Accepted Answer

It is adapted from fast-jev-compaction under MIT, whose upstream targets Claude Code's session.compact hook. This port hooks OpenCode's session hooks instead and vendors a copy of that project's src directory at v0.2.0 under src/vendor, re-copied by hand when you update. The plugin itself is MIT-licensed and unaffiliated with TypeSafe, OpenCode, or the upstream author.

Opencode Context Pruner

About this project

Highlights

Questions about this entry

More Jev resources like this

From the Jev community