[Bug]: Compress keeps re-triggering in webfetch-heavy sessions

[dhaern]

Bug Description

In long OpenCode sessions with heavy webfetch usage, DCP successfully runs compress and reports large reductions, but it still tends to trigger compress again on later turns instead of settling down.

The problem is especially noticeable when the session contains many large webfetch outputs, because they do not remain only as tool results. After subsequent turns, their contents often get carried forward into normal assistant messages and later compression summaries. Once that happens, the original fetched content is no longer just easy-to-prune tool output; it becomes part of the regular conversational context.

This is most noticeable in sessions that include:

• many webfetch tool calls (main issue)
• large fetched documents
• long assistant replies that summarize or reuse fetched content

In these cases, older webfetch content seems to stop behaving like tool output that can be cheaply pruned and instead survives indirectly through large assistant text and compression summaries. Once the session reaches that shape, DCP can keep trying to compress again and again.

Expected Behavior

After a successful compression in a long webfetch-heavy session, DCP should reduce enough stale context to stop repeatedly pushing another compression on the next turns.

Large previously fetched content should not keep the session stuck in a near-constant “compress again” state after compression has already succeeded.

Debug Context Logs

[
   {
     "role": "assistant",
     "tokens": {
       "input": 286229,
       "output": 4,
       "reasoning": 0,
       "cache": {
         "write": 0,
         "read": 0
       }
     }
   },
   {
     "role": "user",
     "parts": [
       {
         "type": "text",
         "text": "Hola estas?"
       }
     ]
   }
]


2026-04-08T03:24:12.866Z INFO  persistence: Saved session state to disk | totalTokensSaved=679707
2026-04-08T03:24:13.217Z INFO  prune: Injected compress summary | summaryLength=22855
2026-04-08T03:24:13.217Z INFO  prune: Injected compress summary | summaryLength=104944
2026-04-08T03:24:13.217Z INFO  prune: Injected compress summary | summaryLength=3536
2026-04-08T03:24:13.317Z INFO  hooks: Attached compression time to blocks | blocks=1 durationMs=16626
2026-04-08T03:24:59.183Z INFO  prune: Injected compress summary | summaryLength=22855
2026-04-08T03:24:59.183Z INFO  prune: Injected compress summary | summaryLength=104944
2026-04-08T03:24:59.183Z INFO  prune: Injected compress summary | summaryLength=3536


This seems to show that compression summaries are being injected successfully, but the session still does not converge well afterwards and DCP keeps re-entering compression pressure in large webfetch-heavy sessions.

Relevant context snapshot observation:

After compression, the transformed context still contained very large assistant text blocks, and one assistant turn still showed:

- input: 286229
- output: 4

Tool Call Details

This tends to happen after /dcp compress in long sessions with large webfetch history.

Compression succeeds and reports large removals, but later turns still tend to push toward compress again. In the affected sessions, the remaining context appears to be dominated by large assistant text blocks rather than fresh tool outputs.

/dcp sweep helps very little in this state, which suggests that the issue is no longer mainly about live tool outputs, but about large fetched content having already been carried into assistant messages and compression summaries.

DCP Version

3.1.9

Opencode Version

1.4.0

Model

Other (specify in description)

Additional Context

This seems especially problematic in documentation-heavy or research-heavy sessions where webfetch is used repeatedly on large pages.

The issue does not look like compression completely failing. Compression summaries are clearly being injected, but the session still does not converge well afterwards and DCP keeps re-entering compression pressure.

Model
gpt-5.4-high

[Tarquinen]

I don't really understand the problem here, if you're using webfetch tools with large outputs, yea dcp will compress frequently, thats kind of the point? I'm not sure what you mean by DCP should settle down... What is the bug here?

[dhaern]

I don't really understand the problem here, if you're using webfetch tools with large outputs, yea dcp will compress frequently, thats kind of the point? I'm not sure what you mean by DCP should settle down... What is the bug here?

The problem is not that DCP compresses frequently in large webfetch sessions.

The problem is that after successful compression, those sessions still do not stabilize well. Large old webfetch-heavy content does not seem to get reduced enough from the active context, so DCP quickly falls back into compression pressure again (sometimes on nearly every message).

What I would expect is that once old webfetch-derived content is no longer actively needed, it should be getting compressed away effectively enough that the session actually settles down. In my case, that does not seem to be happening reliably. A lot of webfetch-derived content appears to survive in the real conversational context after later turns, even though much of it is low-value bulk content that seems like it should be getting compressed away much more effectively.

I think much of that old webfetch-derived content should be reduced much more aggressively instead of effectively being preserved in active context.

[MeydanOzeri]

I don't know if its the same issue, but since recent OpenCode versions (i think 1.3.1) the compress doesn't work anymore.. it gets triggered but the actual context doesn't shrink at all.

[Tarquinen]

That's different and was fixed recently, your dcp version is outdated #491 @MeydanOzeri . I still don't understand what the bug is here, this is just how DCP works. What you're asking for is a setting behavior specific for your workflows, and also not one I have a lot of control over as ultimately its the LLM that decides when to use any of the tools it has available. What model are you using?