Overflow compaction produces incomplete summaries in tool-heavy sessions

[jphpeete]

When a session primarily uses tool-based interactions (e.g. the question tool) rather than direct user messages, overflow compaction produces a summary that only covers the beginning of the conversation.

Steps to reproduce:

1. Start a session and send one message
2. Interact extensively through tool calls (question tool, etc.) — the model loops many times creating assistant messages, but no new user messages are created
3. Hit the provider's context limit (e.g. 200K tokens on GitHub Copilot) so overflow compaction triggers

Expected: The summary covers the full session including all tool interactions.

Actual: The summary only covers the very beginning of the session. All tool interaction context from after the initial user message is lost.

Root cause:
The replay-point search in processCompaction (packages/opencode/src/session/compaction.ts) walks backward looking exclusively for role === "user" messages. In sessions where interactions happen through tool responses (stored as tool parts on assistant messages), user messages are rare. The search skips over all assistant turns and lands on the initial user message, causing messages.slice(0, i) to either produce an empty array (triggering the fallback) or a tiny prefix of the session.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• bug: control user messages are treated as real user history #19319: Also describes how role === "user" checks in compaction/history logic incorrectly handle synthetic or sparse user messages — the root cause overlaps with what you describe in processCompaction's replay-point search.

[alario-tang]

This feels related to how replay-point selection and compaction fallback interact in tool-heavy sessions.

If the summary is incomplete in tool-heavy history, one likely reason is that the current compaction flow has limited options once the summarize set becomes awkwardly large or noisy:

• strip media
• summarize
• replay a prior user turn if possible
• stop if compaction itself still overflows

A more robust path here may be:

• aggressively prune older completed tool output before summary generation
• if compaction still overflows, retry compaction with progressively less early history
• preserve stronger continuity metadata for the immediate next turn

That would probably improve both compact quality and continuation quality in tool-heavy sessions.

[jphpeete]

Agreed on the pruning and retry ideas — those would help with compaction quality regardless of how the split point is chosen.

The PR (#20247) addresses the immediate split-point issue: in tool-heavy sessions the backward walk only matches role === "user" messages, so it jumps over all assistant turns and slices at the start of the conversation. The fix checks for finished assistant turns first, which finds a split point close to the overflow and keeps most of the session in the summary.

The pruning/retry improvements you describe would be good follow-ups on top of this — especially for sessions where even with a good split point, the summarization input is still large.