openclaw - 💡(How to fix) Fix Make session transcript compaction threshold configurable

Summary

The session transcript compaction threshold is hardcoded at 4,000 tokens (softThresholdTokens = 4000 in gateway dist). This threshold cannot be tuned via config, making it difficult to balance memory pressure vs. context retention for different deployment profiles.

Background

OpenClaw's transcript compaction logic triggers when a session's token count exceeds a hardcoded threshold. For a 200K context window, the current 4K threshold represents ~2% of the available context — an aggressive compaction strategy that minimizes memory footprint at the cost of frequent compaction overhead.

Current behavior:

• Compaction threshold: 4,000 tokens (hardcoded)
• Cannot be adjusted via gateway.yaml or environment variable
• Requires vendored patch or upstream code change to modify

Use case for configurability:

Different deployment profiles have different needs:

1. Memory-constrained gateways (current default): Aggressive compaction (e.g., 4K) keeps heap low
2. High-volume coordination agents (e.g., woodhouse): Less frequent compaction (e.g., 8K-12K) reduces CPU churn during peak inter-agent messaging
3. Long-context analytical agents: Higher threshold (e.g., 20K-50K) preserves more session history for complex reasoning tasks

Currently, all deployments use the same 4K threshold regardless of their workload profile.

Requested Feature

Make compaction threshold configurable:

# gateway.yaml
gateway:
  sessions:
    compaction:
      softThresholdTokens: 8000  # default: 4000

Benefits:

• Operators can tune compaction frequency based on heap availability and workload
• High-volume agents can reduce compaction overhead during peak traffic
• No breaking change (default 4K preserves current behavior)

Implementation notes:

• Current location: softThresholdTokens = 4000 in gateway runtime
• Suggested path: read from gateway.sessions.compaction.softThresholdTokens config, fall back to 4000 if unset
• Optional: add runtime validation (e.g., must be ≤ 25% of model context window to prevent OOM)

Current Workaround

We're accepting the current 4K threshold short-term. For our fleet deployment (200K context window), 4K is aggressive but functional (~85% of tokens available for actual conversation). However, we cannot tune it without a vendored patch, which we're avoiding for maintainability.

Impact

Severity: P3 (nice-to-have optimization, not blocking current operations)

Frequency: Continuous (compaction runs on every session at 4K+ tokens)

Affected workflows:

• High-volume inter-agent coordination (frequent compaction CPU cost)
• Memory pressure during peak traffic (cannot trade CPU for heap)

Environment

• OpenClaw version: [current production, can provide specific version if needed]
• Deployment profile: Multi-agent fleet with 25+ agents, high inter-agent messaging volume
• Current heap usage: 2.8GB (12% over our P1 threshold of 2.5GB)

Note: This is a lower-priority request compared to critical substrate fixes (e.g., stale lock auto-cleanup). We're filing it now for backlog consideration, but we understand if it's deferred in favor of higher-impact work.