openclaw - 💡(How to fix) Fix [Bug] Embedded agent context overflows 200k limit without auto-compaction firing [1 comments, 2 participants]

Summary

A long-running embedded agent (Anthropic Claude Opus 4.7, 200k context window) reached and exceeded its hard context limit (~300k observed total tokens, 150% of cap) without the documented auto-compaction routine triggering. Result: model responses get silently truncated, completion events do not fire, downstream channel (Telegram) sees partial or no output.

Environment

• OpenClaw runtime: 2026.4.20
• Agent: agent:kusanagi:telegram:direct:<redacted>
• Model: claude-opus-4-7 (200k context)
• Session transcript path: ~/.openclaw/agents/kusanagi/sessions/<redacted>.jsonl
• Observed at: 2026-04-24 21:00 KST

Note to maintainers: This is filed with awareness of #68580 and #67473 (same root: threshold-based auto-compaction not firing). We chose a separate issue because our observations extend beyond those reports — we hit the cliff past the 200k hard limit (≈300k cumulative), in a multi-agent setup where shared-knowledge files compound the load, and we have specific runtime-telemetry questions for the agent-side workaround. Happy to be merged/closed as duplicate if maintainers prefer a single thread.

Repro

1. Run a long-lived embedded agent across many cross-agent + Captain turns
2. Watch totalTokens grow past 200k (in our case, contextTokens=200000 + totalTokens trending toward 300k+ because of cumulative session history)
3. No auto-compaction event fires; no warning surfaced to either agent or operator
4. Subsequent turns produce truncated / empty responses; completion stop reasons appear normal but text is missing or partial

Expected

• Auto-compaction triggers at a documented threshold (e.g., 80% of context window)
• Compaction event is observable: agent sees a system signal, operator sees a metric/log line
• After compaction, agent resumes with summarized history + recent verbatim tail
• If compaction fails, agent is informed (not silent)

Actual

• No compaction event observed
• No warning surfaced
• Agent continues producing turns that silently truncate or fail to deliver
• Operator only discovers via downstream symptom (Telegram output missing)

Impact

• Strategic agents (planning, multi-step) become unreliable past ~150k tokens
• Loss of agent-side strategic context = lost proposals, lost plans, manual recovery cost
• Multi-agent setups amplify this: shared knowledge files loaded per session push every agent closer to the cliff

Diagnostics requested

• What is the documented auto-compaction trigger threshold? Is it per-model or global?
• Is auto-compaction enabled by default for embedded agents, or opt-in?
• Is there a way for the agent itself to query current totalTokens / contextLimit ratio at runtime? (We would use this for self-monitoring per NOW-003 Layer 3.)

Suggested fix direction

• Make compaction threshold a configurable per-agent knob (default 80% of context limit)
• Emit observable compaction events (log + metric)
• On compaction failure or threshold-without-fire, fail loud (not silent truncation)
• Expose context-usage telemetry to the agent itself via a system message or tool

Cross-references

• NOW-003 (b) — telegram in-flight loss (related downstream symptom)
• NOW-003 Layer 3 — agent-side self-monitoring as workaround
• NOW-003 (h) — MemKraft solution evaluation (potential alternative)

Notes

Reported as part of multi-agent operating model hardening (Captain JS, 4-agent setup). The combination of (this issue) + sendChatAction in-flight loss caused a full-cycle context loss this morning (2026-04-25) that took 4 cross-session round-trips to recover. Will share session jsonl excerpts on request.