fix: make context compaction resilient to huge tool logs

[josenaicipa]

Summary

• Digests oversized tool outputs before context summarization so CI/CodeQL logs do not balloon compaction prompts.
• Shrinks oversized protected tool outputs in deterministic fallback compaction when the auxiliary summary model times out/fails.
• Retunes Codex gpt-5.5 compaction behavior from an 85% replacement to a 60% floor that preserves higher user thresholds.
• Updates defaults/docs/tests for protect_last_n: 10 and auxiliary.compression.timeout: 300.

Why

Long Discord/gateway sessions with large tool outputs were reaching ~265K tokens before compaction. The auxiliary compression call could time out, and fallback compaction could still leave ~100K+ tokens because protected tail tool logs survived verbatim.

Test Plan

• python -m pytest tests/agent/test_context_compressor.py tests/agent/test_context_compressor_summary_continuity.py tests/agent/test_tool_result_classification.py tests/agent/test_tool_output_precompaction.py tests/agent/test_arcee_trinity_overrides.py tests/agent/test_auxiliary_client.py tests/agent/test_auxiliary_config_bridge.py tests/agent/test_auxiliary_main_first.py tests/hermes_cli/test_config.py tests/hermes_cli/test_config_validation.py tests/hermes_cli/test_aux_config.py tests/gateway/test_compress_command.py -q -o 'addopts='
• Result: 565 passed

[tonydwb]

Code Review Summary

Verdict: Approved

Substantial fix improving context compression resilience. The changes work together: Codex gpt-5.5 threshold lowered from 0.85 to 0.60 (the old value made summarizer input too large), protect_last_n reduced from 20 to 10, and a new fallback tool-output digest handles huge CI/log output that would otherwise survive compression.

Looks Good

• Root cause clearly documented: at 0.85, the summarizer's input was too large and it routinely hit timeouts, leaving sessions stuck
• New _resolve_compression_threshold helper centralizes threshold resolution logic cleanly
• New _FALLBACK_TOOL_DIGEST_TRIGGER_CHARS (8K) and _FALLBACK_TOOL_DIGEST_MAX_CHARS (4K) provide deterministic shrinking of oversized tool output in fallback path
• Compression timeout raised from 120s to 300s to accommodate larger windows
• Full documentation updates across English and Chinese docs
• No security concerns

Minor Note

• protect_last_n changing from 20 to 10 is a behavioral default change — this is intentional and documented, but worth noting for users who may have tuned their config around the old default

---

Reviewed by Hermes Agent

[canorionen]

This PR is very relevant to a concrete long-session failure mode we just hit.

In one long Hermes Telegram gateway thread, the compression pressure was dominated by recent raw tool outputs rather than ordinary user/assistant prose. Examples from persisted rows / active tail analysis:

• web_extract outputs around ~73K, ~62K, and ~51K chars
• skill_view hermes-agent around ~65K chars
• a large compaction summary around ~51K chars
• terminal/log dumps around ~31K / ~22K / ~17K chars

The important nuance: web_extract itself was not simply broken. The agent had explicitly requested high char_limit values across multiple docs pages, and Hermes allowed those large model-visible outputs to remain in the protected/recent region. Once there, automatic compression had trouble achieving a meaningful reduction.

So the “huge tool logs” problem appears broader than CI logs: it includes docs extraction, skill dumps, session search windows, browser/HTML dumps, and terminal output. The right fix seems to be type-aware protected-tail handling:

• keep full raw tool output in state/cache/artifacts;
• keep only a bounded digest/stub in model-visible protected tail after the tool result has been consumed;
• preserve handles/paths/cursors so the agent can page back into the full result when needed;
• avoid treating raw recent bytes as protected semantic continuity.

Question: does this PR also shrink/collapse oversized protected outputs from web_extract / skill_view / session_search, or is it currently focused mainly on terminal/CI-style logs? If not, those tools may need to be included in the same digest budget path.

This aligns with what we observed comparing Codex compaction locally: Codex appears to replace history with semantic message/compaction items and does not carry raw tool outputs into replacement history, which is why 250K+ contexts can drop to roughly 25K-38K input tokens quickly.

[teknium1]

Thanks for the focused compaction work. The large-tool-output premise still exists on current main, but the patch needs adaptation to current compression behavior.

Problems

• The new test deliberately keeps a giant protected tool result verbatim after a successful summary. That leaves the July 6 reported web_extract / skill_view / browser / session-search protected-tail case unresolved. Current main can retain an oversized tail message under agent/context_compressor.py:2746-2768.
• The timeout/default retune is stale: current main already guarantees a 300-second effective timeout for config-derived compression calls in agent/auxiliary_client.py:6078-6079, while retaining the 120 schema default at hermes_cli/config.py:1599. Current small-context threshold resolution is also raise-only at agent/context_compressor.py:979-993, so the proposed 60% Codex value needs reconciliation.

Suggested changes

• Port the digest work onto current ContextCompressor and add successful-compaction coverage for the oversized protected outputs identified in the discussion.
• Preserve the current timeout-floor mechanism and re-evaluate threshold/default changes against current HEAD.

Automated hermes-sweeper review.

[teknium1]

This test confirms that a successful compaction leaves the giant protected result verbatim. That is the remaining failure mode described in the July 6 review comment for web_extract/skill_view/browser/session-search output; please add the intended post-consumption protected-tail behavior and coverage rather than limiting shrinking to fallback-only compaction.

[teknium1]

Merged via #69830 (commit 18d83b4). The huge-tool-log compaction dead-end is fixed via #69830 (salvage of #61952's targeted demotion). Your config-subsystem approach was broader than the bug needed — the 962-line scope didn't fit a fixes sweep, but the problem you identified was real and is now solved. Thanks!