Compaction: Pruning/soft compaction and selective tool-output deletion

[riatzukiza]

Epic: #46

Summary

Use pruning/soft-compaction to reclaim tokens by deleting stale tool outputs instead of resorting to full compaction.

Problem

• Most tokens accrue in tool outputs between recent user turns.
• Current pruning protects the exact region with heavy tool output; premature full compaction follows.

Proposal

• Tune PRUNE_* thresholds; prefer deleting earlier completed tool outputs.
• Consider soft-compaction: mark tool calls with IDs, let model propose safe deletions, then drop those parts and add a soft-compaction note.
• Provide a manual /prune command and improve auto-triggering heuristics.

Code Refs

• packages/opencode/src/session/compaction.ts:50 (prune function)
• packages/opencode/src/session/compaction.ts:43-45 (PRUNE_* constants)

Tasks

• Adjust prune strategy to favor pruning old completed tool outputs
• Add logs: pruned tokens, protected tokens, decisions
• (Optional) Implement soft-compaction workflow
• Add /prune command or integrate into /status

Acceptance Criteria

• Token usage reduced via pruning without harming recency.
• Fewer full compactions during long BUILD sessions.

[riatzukiza]

Related Issues & Context

This Pruning/Soft Compaction issue has important relationships with other compaction improvements:

Complementary Relationship:

• Compaction: Smarter boundary selection and cross-session guard #47 - Boundary Selection: Better pruning reduces pressure on boundary selection. When pruning effectively removes old tool outputs, there's less need for aggressive compaction boundaries.
• Compaction: Structured BUILD-mode handoff summary prompt #49 - Structured Handoff: Pruning is the FIRST line of defense. Better pruning = fewer expensive handoff generations.

Cost & Performance Impact:

• Compaction: Provider options flow and accurate usage accounting #51 - Usage Accounting: Pruning decisions directly impact token usage and cost. Need accounting for pruned vs compacted tokens.
• Compaction: Configurable preserved turns and prune thresholds #55 - Configurable Options: This issue implements tunable PRUNE thresholds for optimization.

Strategic Benefits:

• Epic: Subagent State Handoff & Context Boundary Resilience #56 - Subagent State Handoff: Pruning techniques developed here can be applied to subagent sessions. Subagents also accumulate tool output tokens that need selective cleanup.

Technical Dependencies:

• Compaction: Telemetry and /status for context + decisions #52 - Telemetry: Pruning decisions need visibility - what was pruned vs protected, why, and token counts
• Compaction: Tests – boundary, rules, pruning, integration #54 - Tests: Pruning logic is a critical unit test case
• Compaction: Concurrency/locking robustness and retries #53 - Concurrency: Pruning must be safe under concurrent operations

Implementation Sequence:

Pruning should be implemented BEFORE full handoff (#49) because:

1. Cost Efficiency: Reduces expensive AI-generated summaries
2. Frequency Reduction: Fewer full compactions = fewer handoff generations needed
3. User Experience: Smoother experience with fewer disruptive context resets

Cross-Cutting Impact:

The soft-compaction concept (AI-proposed safe deletions) could extend to:

• Subagent sessions - clean up tool outputs in long-running subagents
• Parent sessions - clean up after subagent tool calls complete

This makes pruning improvements HIGH LEVERAGE - they benefit both immediate compaction AND future subagent state management.