Bug Description

When running Hermes as a Telegram gateway bot in a group chat with frequent messages, the gateway becomes unresponsive after context compression is exhausted. The agent compresses context twice, emits a warning, but then has no fallback — the session remains in an oversized state, and subsequent messages trigger the same compression-fail loop until the gateway effectively stalls and stops responding.

Environment

• Hermes: latest main branch (installed from source)
• Platform: Telegram gateway (group chat with multiple participants including another bot)
• Model: claude-opus-4.6 via GitHub Copilot provider
• OS: Ubuntu 22.04 ARM64 (Oracle Cloud)
• Config: compression.threshold: 0.50, compression.target_ratio: 0.20

Steps to Reproduce

1. Run hermes gateway run with Telegram configured
2. Add the bot to an active group chat with frequent messages
3. Let the conversation accumulate over several hours
4. Eventually context exceeds compression threshold

Observed Behavior

Gateway log output before becoming unresponsive:

⟳ compacting context…
⟳ compacting context…
⚠️  Session compressed 2 times — accuracy may degrade. Consider /new to start fresh.
💾 Memory updated

After this, the gateway stops responding to messages entirely. The gateway_state.json shows:

{
  "gateway_state": "stopped",
  "platforms": {
    "telegram": {
      "state": "disconnected"
    }
  }
}

This happened 3 times in a single day during normal group chat usage. Each time I had to have a co-located agent (OpenClaw) restart the gateway with hermes gateway run --replace.

Expected Behavior

When compression is exhausted and context is still over threshold, the gateway should gracefully handle the situation rather than becoming unresponsive. Possible behaviors:

• Auto-reset the session (equivalent to /new) with a summary carried forward
• Gracefully degrade by dropping oldest context beyond the summary
• At minimum, remain responsive to new messages even if the oversized session is abandoned

Analysis

I traced the code path:

1. run_agent.py preflight compression (~line 7970): Runs up to 3 compression passes, but if tokens are still over threshold after 3 passes, it just breaks and sends the oversized context to the API anyway
2. API returns 413/400 → max_compression_attempts reached → agent returns {"completed": False, "error": "max compression attempts reached"}
3. Gateway receives the error but the session state is not reset — next incoming message hits the same oversized session, creating a fail loop
4. The ⚠️ Session compressed N times warning at run_agent.py ~line 6818 is informational only — it suggests /new but does not trigger any automatic action

The compression mechanism itself is well-designed (iterative summaries, tool pair sanitization, token-budget tail protection). The gap is specifically in the "what happens when compression is not enough" fallback path.

Suggested Fix Direction

Add a compression-exhaustion fallback that auto-resets the session when compression cannot bring context below threshold:

1. In the preflight compression loop: if 3 passes fail to get under threshold, trigger an automatic session reset preserving only the latest summary + last user message
2. In the gateway error handler: when agent returns "max compression attempts reached", mark the session for reset so the next message starts fresh instead of replaying the oversized context

Happy to contribute a PR if you think this is worth fixing and agree with the general direction. This is a real production issue for anyone running Hermes as a long-lived gateway bot in active group chats.

Filed by a Hermes user running dual-agent setup (Hermes + OpenClaw) on the same machine.