BETA Testing / Discussion

[Tarquinen]

Version 3 will probably be a pretty radical transition to just 1 DCP tool, compress. This has several significant benefits:

• Significantly decrease how often DCP causes cache invalidation (fixes all anthropic related cache issues without needing manual mode).
• Simplify behavior for the model, it doesn't need to pick from 3 context management tools anymore.
• Allow conversations to last virtually infinitely, previously with tool pruning the user/AI messages remaining limited this.
• A lot more control over how frequently the tool is triggered. Since I can't test behavior for each model, users will be able to adjust on their own through the config if they want more / less frequent compressions.

You can test if out by setting your plugin array in opencode.json to

"plugin": ["@tarquinen/opencode-dcp@beta"]

The config settings for the beta can be found in the readme: https://github.com/Opencode-DCP/opencode-dynamic-context-pruning/blob/refactor/one-tool-to-rule-them-all/README.md

Please let me know what you think if you try it out!

[BouquetAntoine]

Hi, thanks for your work ! trying that right now !
Is there any way to send you a private message btw ? (not related to the beta)

[BouquetAntoine]

No more "protectedTools" for specific tools ? I'm using multiple tools that returns a unique id which need to be used for other tools, should I implement a state into my MCP server to save unique ids here instead ?
(same for exa with their exa_deep_researcher_start tool which returns an ID used by the agent to get response when ready)

Will try that on Sonnet & Opus today :)

btw the default configuration for the beta (in the readme) is :
"$schema": "https://raw.githubusercontent.com/Opencode-DCP/opencode-dynamic-context-pruning/master/dcp.schema.json",
instead of
"$schema": "https://raw.githubusercontent.com/Opencode-DCP/opencode-dynamic-context-pruning/refs/heads/refactor/one-tool-to-rule-them-all/dcp.schema.json",

[Tarquinen]

Hey, you can email me at dansmolsky@gmail.com, or message me on discord @tarquin_dan

I do have a way to do protectedTools, it's not fully finished yet but should have it added to the beta tomorrow. My idea is to just append to the summary something like "the following important tools were used in this range as well: tool 1 title and output, tool 2 title and output, etc". What field do your unique IDs live in? Are they part of the tool output? I hadn't originally planed on including the tool input, but it can be done if necessary (or a config option for it).

I'm not sure if I want to swap the schema URL, I think it may lead to some confusion when users go back to @latest and they forget to change the URL to the master branch... not sure which approach is less friction here.

[motonari728]

I've been testing a v2 fork with prunableToolsInjectionFrequency gating (#411) and it's been working well with Claude/Codex models. Here are my thoughts on the v3 direction.

Recoverability

My core concern is replacing prune/distill with compress-only.
Prune removes a tool output — the LLM can just re-invoke the tool to get it back. Distill replaces a tool output with a summary, but again, re-invocation recovers the original. Both operations are inherently reversible at the tool-call level.
Compress replaces an entire message range with a free-form summary. There's no structural recovery path. If the summary drops a file path, a constraint, or a side-effect the LLM noticed earlier, that information is gone for good.
As engineers, we have a strong instinct against irrecoverable operations — that's why we have git reflog, soft deletes, and WAL. Compress is a destructive overwrite of conversation history with no undo, which makes me uncomfortable relying on it as the sole context management mechanism.

Summary quality is entirely LLM-dependent

The prompts say "EXHAUSTIVE" and "preserve FULL understanding," but that's asking, not guaranteeing. With prune/distill, what gets removed is structurally determined — a specific tool output identified by numeric ID. With compress, both the boundaries and the replacement content are LLM-generated free text. The surface area for silent information loss is fundamentally larger.

Granularity

Prune/distill targets individual tool call outputs by numeric ID. The LLM can surgically remove a single stale grep result while preserving the read output in the same assistant message. In v3, the smallest addressable unit is an entire message (mNNNN). If an assistant message contains 10 tool calls, you can't compress 3 of them — it's all or nothing for that range.

Where I'm landing

If v3 drops prune/distill entirely, I'll fork and continue developing v2 with them. Tool-level granularity and recoverability are core to my workflow — I'd rather keep building on that foundation than move to message-range-only compress.

[Tarquinen]

Unfortunately the #411 approach is not viable as I mentioned in the PR, it allows hallucinated tool calls without any way of detecting them. It may work for claude models most of the time, but it will definitely fail on dumber models much more frequently.

This system will be recoverable, it isn't working yet but you'll be able to /undo to go back to a previous user message, and any compressions done after it will be undone. There will also be a /decompress [n] to decompress a compression #n back to its original messages.

You're right this approach has drawbacks, its less "surgical" in how it modifies context. I'm working on some ideas to reduce information loss that you have control over, for example compress has protectedTools and protectedFilePatterns now, those tool outputs are saved even through compressions. Compressions also can't overwrite prior compressions and therefore can't dillute information down, instead prior compression summaries get included in the new encompassing one. Any other ideas on what else can be done in this regard?

Overall i'm not 100% convinced this is the way to go yet, but I think the pros outlined above (mostly the cache benefits and better control over how frequently DCP is done) outweigh the cons. Let me know what you think

[motonari728]

Proposal: Hash-anchored validation for both prune/distill and compress

The hallucination concern from #411 is valid, but it's solvable structurally — and the same solution strengthens compress too.

The core idea: attach short random hashes (inspired by hashline edit) to context management anchors, and reject any call where the hash doesn't match. This is a structural guarantee, not a prompt-based one.

For prune/distill (v2-style tool-level operations)

1. Plugin injects a short random hash (e.g., #XK) into each tool call result as it's returned to the LLM. This persists in the conversation history permanently — cache-friendly because the content is written once and never mutated afterward
2. When prunable tool count >= threshold, a new message is sent listing prunable items with their hashes, plus a one-time authorization hash:

   <prunable-tools auth="#A7Q">
     12#XK: read, src/index.ts (~800 tokens)
     15#MR: grep, lib/ (~1200 tokens)
   </prunable-tools>
   

3. Validation is two-factor — each identifier pairs a guessable index with an unguessable hash (like a userid + password):
   • Authorization hash (#A7Q): validates the prune/distill call as a whole
   • Tool call index + hash (12#XK): validates each individual target — the index is predictable, but the hash is not
   • Non-existent tool call hashes are silently ignored
   • If error rate >= 20% of specified targets, the entire call is treated as hallucination and rejected
4. Once used, the authorization hash is invalidated. The cycle: notification → prune call → invalidation → ~20 turns pass → new notification with a fresh auth hash. Stale auth hashes are rejected

Cache impact: zero for injection. Hashes on tool results are written once and persist. Prunable notifications are new messages, not appended to existing ones. No existing message is ever mutated. Cache invalidation only occurs when prune/distill actually executes (unavoidable, same as compress).

For compress (v3-style range operations)

The same principle applies. Current compress boundaries use sequential mNNNN IDs, which are predictable — a hallucinated m0050 could pass validation even if the model never saw that message.

If message IDs included a hash component (e.g., m0042#VK instead of m0042), compress boundary validation becomes structurally robust too. The model must have actually seen the message to know its hash.

Why hash anchors work for LLMs

The hashline edit benchmark tested 16 models with 2-3 character content hashes as anchors. Short hash recall is something LLMs are exceptionally good at — even lightweight models like Grok 4.1 Fast showed dramatic improvements. These hashes serve as easy-to-use anchors for the LLM while acting as structural hallucination blockers on the validation side.

Migration path

Rather than dropping prune/distill entirely in v3 and breaking backward compatibility, a gentler path would be to default prune/distill to off while keeping them available for users who want tool-level granularity. This lets existing users migrate to compress at their own pace, and gives hash-validated prune/distill a chance to prove itself alongside compress without forcing an all-or-nothing choice.

Both tools benefit from hash validation. Both serve different granularities (tool-level vs message-range). They can coexist.

I'd be happy to contribute the hash validation implementation if prune/distill are kept alongside compress in v3.

[motonari728]

By the way, I'd really recommend reading the hashline edit article — it's a cool piece of work: https://blog.can.ac/2026/02/12/the-harness-problem/

One more point about hashes beyond hallucination prevention:

Hashes force the LLM to actually look at what it's operating on.

Even without hallucination, LLMs can get lazy — bulk-selecting tool call IDs without reviewing their content, or specifying compress ranges carelessly. When the model has to recall a hash for each target, it must direct its attention to that specific item in the conversation history and verify what it contains. The hash acts as a forcing function for careful, honest operation.

From the LLM's perspective, hashes add friction — but that friction is productive. For thinking models, the hash recall happens in thinking tokens: the model reads the target, notes the hash, reasons about whether it should be pruned/compressed, then acts. The slight increase in difficulty promotes deliberation rather than shortcuts. The same applies to compress — having to confirm m0042#VK instead of just m0042 means the model actually visits that message boundary before deciding to compress through it.

[BouquetAntoine]

Interesting discussion here! Would be happy to try the hash version to compare both approaches 😊
Let me know if you have an implementation (based on v3) so I can send benchmarks and real results
Not closed to try new versions of prune/distill tools if they doesn't break the whole cache every single time even when not called (using Anthropic automatic prompt caching)