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.
• /dcp decompress/recompress commands.
• DCP in subagents (!!!) with experimental.allowSubAgents config setting.
• Allow users to customize prompts used by DCP with experimental.customPrompts config setting
• Added compress.flatSchema config option for models more likely to fail tool use
• Strengthened manual mode, compress can no longer activate without a manual trigger

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

If you want the config schema for IDE autocomplete / whatever else, replace the existing one in dcp.jsonc with:
https://github.com/Opencode-DCP/opencode-dynamic-context-pruning/refactor/one-tool-to-rule-them-all/dcp.schema.json

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://github.com/Opencode-DCP/opencode-dynamic-context-pruning/master/dcp.schema.json",
instead of
"$schema": "https://github.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)

[manorit2001]

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

I wonder if non SOTA models would just get in a loop with the additional complexity ( and not sure on SOTA models behaviours either ), though even with gpt-5.3-codex i've seen that it just ends up going with invalid tool ids sometimes during prune/distill, with hashing I can wonder that it's just gonna get more complex for those models itself. But yeah, hopeful for future set of models that are just cracking the AGI benchmarks left and right.

[Tarquinen]

These are some very interesting ideas, and most of what you said is accurate @motonari728 (other than a few things like hallucinated message IDs passing validation, they don't that's not how the code works), but I think the core idea here that extra complexity from forcing the model to think more about what it chooses to prune is the wrong direction. This process is already inherently a very complicated one, the model has to understand how each tool from the list just from the short tool name applies to the current task, and consider each for pruning. With multiple tools it also has to determine the best of 3 ways to handle the task. The best SOTA models already struggle doing this well, and with the rise of Chinese exceptionally performing agentic models but low general intelligence like kimi k 2.5 the average performance of DCP probably decreases as SOTA general intelligence models are no longer necessary for coding. Also, remember the core task of opencode is to code agentically, not to spend a ton of tokens thinking about how to manage its context.

The other thing is this idea still does not address my other issue with #411, when a model chooses to use a DCP tool it should have all the information that it needs to use the tool successfully. Tool use failing should not be an expected outcome at any point. If you gate the list of available tools for pruning injection behind a certain checkpoint, models will still follow the system/tool prompt and choose to use them when they think it's a good time, regardless of if there's a tool list available, leading to hallucinated hashes and an errored tool. They might also decide that a tool used after the injected list is one they want to prune, and hallucinate it as well.

I think you can probably get this approach to a "good enough" level, especially if you only use one model, but as far as I can tell it opens the door to a lot of issues considering there are thousands of users on all kinds of models.