Bug Description

In a long-lived Discord gateway DM, Hermes auto-compacted the session even though /usage showed only 34% context usage (360,077 / 1,050,000).

The compaction turned out to be triggered by gateway session hygiene's hard 400-message safety valve, not by token pressure. In my case the session had 406 messages, so the gateway compacted it before the next turn.

The surprising part is that this is effectively invisible from the user-facing gateway UX:

• /usage reports low context pressure, so the user expects the session to be safe
• there is no warning that message-count-based hygiene is about to fire
• the auto-compaction can interrupt an important ongoing workflow and abruptly change the session's continuity shape

This may be intentional behavior for gateway survivability, but if so it still needs explicit visibility, documentation, and configurability.

Steps to Reproduce

1. Run Hermes via a gateway platform (observed on Discord DM).
2. Keep using one long-lived session until the transcript reaches 400+ messages.
3. Check /usage shortly before the next inbound message. In my case it showed:
   • Context: 360,077 / 1,050,000 (34%)
4. Send the next normal user message.
5. Observe that gateway session hygiene auto-compacts the session even though token usage is still far below the reported context threshold.
6. Check /usage again after the response. In my case it dropped to:
   • Context: 50,007 / 1,050,000 (5%)

Expected Behavior

If gateway session hygiene can compact based on message count independently of token pressure, users should be able to see that clearly.

At minimum, Hermes should do one or more of the following:

1. Expose hygiene triggers in /usage and /status

   • current message count
   • hard message limit (if enabled)
   • whether the next inbound turn is likely to trigger hygiene compaction

2. Warn when auto-compaction is triggered by message count rather than token pressure

   • e.g. “Gateway session hygiene compacted this session because it exceeded the 400-message safety limit, even though token usage was still below the model threshold.”

3. Make the hard message limit configurable

   • config key and/or environment variable
   • personal DM workflows may prefer a much higher limit than public/group gateways

4. Document this behavior explicitly

   • if this is intended design, it should still be discoverable in docs and status commands

Actual Behavior

Gateway session hygiene silently compacts based on message count, while /usage only shows the last prompt-token-based view of context pressure.

This makes the compaction feel random from the user side.

Observed user-facing /usage snapshots:

📊 Session Token Usage
Model: gpt-5.4
Input tokens: 11,275,580
Cache read tokens: 2,227,840
Output tokens: 27,100
Total: 13,530,520
API calls: 42
Cost: $0.0000
Context: 360,077 / 1,050,000 (34%)

📊 Session Token Usage
Model: gpt-5.4
Input tokens: 13,088,788
Cache read tokens: 2,279,040
Output tokens: 30,556
Total: 15,398,384
API calls: 48
Cost: $0.0000
Context: 50,007 / 1,050,000 (5%)

Relevant log evidence:

2026-04-20 01:45:04,833 INFO gateway.run: Session hygiene: 406 messages, ~365,433 tokens (actual) — auto-compressing (threshold: 85% of 1,050,000 = 892,500 tokens)
2026-04-20 01:47:10,331 INFO gateway.run: Session hygiene: compressed 406 → 7 msgs, ~365,433 → ~8,346 tokens

Affected Component

• Gateway (Telegram/Discord/Slack/WhatsApp)
• Agent Core (conversation loop, context compression, memory)
• Configuration (config.yaml, .env, hermes setup)

Messaging Platform (if gateway-related)

• Discord

Debug Report

I ran hermes debug share --local and am including the relevant environment summary here instead of a paste link:

version:          0.10.0 (2026.4.16) [d0e1388c]
os:               Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
python:           3.11.15
profile:          default
model:            gpt-5.4
provider:         openai-codex
terminal:         local
memory_provider:  holographic
platforms:        discord
compression.threshold: 0.95

Operating System

Ubuntu 24.04.4 LTS (Noble Numbat) under WSL2

Python Version

3.11.15

Hermes Version

Hermes Agent v0.10.0 (2026.4.16)

Root Cause Analysis

From local investigation:

• /usage renders context_compressor.last_prompt_tokens / context_length, i.e. the last prompt-token-based view of context pressure.
• gateway/run.py also has a separate session hygiene path that runs before the agent turn.
• That hygiene path uses its own thresholding and includes a hard _HARD_MSG_LIMIT = 400 safety valve.
• So a gateway session can auto-compact at low token percentage if it crosses the message-count limit.

This is understandable as a survivability mechanism (see related issue #2153), but it is not surfaced clearly enough to users.

Proposed Fix

I think the safest and least disruptive improvement would be:

1. Keep the safety valve, but make it visible
2. Add message-count / hygiene state to /usage and /status
3. Emit a post-compaction reason when hygiene fired due to message count
4. Add a config/env override for the hard message limit, for example:
   • gateway.session_hygiene.max_messages
   • or HERMES_GATEWAY_HARD_MSG_LIMIT
5. Document that gateway continuity may compact on message count even when token pressure looks low

Related Context

This is related to, but not the same as:

• #2153 — gateway context-compression death spiral; contributor added the 400-message hard safety valve
• #7317 — gateway-visible context/compression observability gap
• #10617 — proposal to expose richer context composition / usage information

My issue here is specifically the user-facing surprise / observability / configurability gap: a gateway session can be compacted in the middle of important work even though /usage appears to say “only 34% used.”