fix: cap context pressure percentage at 100% in display by teknium1 · Pull Request #3480 · NousResearch/hermes-agent

teknium1 · 2026-03-28T04:03:14Z

Summary

The context pressure display functions (format_context_pressure and format_context_pressure_gateway) didn't cap the percentage text, so users could see "109% to compaction" when the forward-looking token estimate overshoots the threshold in a single step (e.g. a large tool result).

The progress bar was already capped via min(), but pct_int was not.

Fix

Cap pct_int at 100 in both CLI and gateway display functions.

Tests

Updated test_over_100_percent_capped to verify text is capped (not just bar)
Added gateway equivalent test for >100% capping

Reported by @JoshExile82.

The forward-looking token estimate can overshoot the compaction threshold (e.g. a large tool result pushes it from 70% to 109% in one step). The progress bar was already capped via min(), but pct_int was not — causing the user to see '109% to compaction' which is confusing. Cap pct_int at 100 in both CLI and gateway display functions. Reported by @JoshExile82.

github-actions · 2026-03-28T04:03:24Z

⚠️ Supply Chain Risk Detected

This PR contains patterns commonly associated with supply chain attacks. This does not mean the PR is malicious — but these patterns require careful human review before merging.

⚠️ WARNING: Install hook files modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py

Automated scan triggered by supply-chain-audit. If this is a false positive, a maintainer can approve after manual review.

Replace the rough chars/3 estimation with actual prompt_tokens + completion_tokens from the API response. The estimation was needed to predict whether tool results would push context past the threshold, but the default 50% threshold leaves ample headroom — if tool results push past it, the next API call reports real usage and triggers compression then. This removes all estimation from the compression and context pressure paths, making both 100% data-driven from provider-reported token counts. Also removes the dead _msg_count_before_tools variable.

github-actions · 2026-03-28T04:28:36Z

⚠️ Supply Chain Risk Detected

This PR contains patterns commonly associated with supply chain attacks. This does not mean the PR is malicious — but these patterns require careful human review before merging.

⚠️ WARNING: Install hook files modified

These files can execute code during package installation or interpreter startup.

Files:

hermes_cli/setup.py

Automated scan triggered by supply-chain-audit. If this is a false positive, a maintainer can approve after manual review.

PR NousResearch#3480 capped context pressure at 100% in agent/display.py but missed the same unclamped pattern in 4 other files. When token counts overshoot the context length before compression fires, users see >100% in /stats, gateway status messages, and memory tool output. Apply min(100, ...) at all 5 remaining unclamped percentage sites.

Follow-up to PR #3480 which capped display.py but missed 5 other sites. Applies min(100, ...) to all remaining unclamped percentage calculations: - agent/context_compressor.py: get_status() usage_percent - cli.py: /stats command context percentage - gateway/run.py: gateway /stats handler - tools/memory_tool.py: _success_response() and _render_block() Includes 15 tests covering over-limit clamping, normal percentages, zero-denominator safety, and source-line verification.

…ol (#3599) Salvage of PR #3533 (binhnt92). Follow-up to #3480 — applies min(100, ...) to 5 remaining unclamped percentage display sites in context_compressor, cli /stats, gateway /stats, and memory tool. Defensive clamps now that the root cause (estimation heuristic) was already removed in #3480. Co-Authored-By: binhnt92 <binhnt92@users.noreply.github.com>

…#3480) * fix: cap context pressure percentage at 100% in display The forward-looking token estimate can overshoot the compaction threshold (e.g. a large tool result pushes it from 70% to 109% in one step). The progress bar was already capped via min(), but pct_int was not — causing the user to see '109% to compaction' which is confusing. Cap pct_int at 100 in both CLI and gateway display functions. Reported by @JoshExile82. * refactor: use real API token counts for compression decisions Replace the rough chars/3 estimation with actual prompt_tokens + completion_tokens from the API response. The estimation was needed to predict whether tool results would push context past the threshold, but the default 50% threshold leaves ample headroom — if tool results push past it, the next API call reports real usage and triggers compression then. This removes all estimation from the compression and context pressure paths, making both 100% data-driven from provider-reported token counts. Also removes the dead _msg_count_before_tools variable.

…ol (NousResearch#3599) Salvage of PR NousResearch#3533 (binhnt92). Follow-up to NousResearch#3480 — applies min(100, ...) to 5 remaining unclamped percentage display sites in context_compressor, cli /stats, gateway /stats, and memory tool. Defensive clamps now that the root cause (estimation heuristic) was already removed in NousResearch#3480. Co-Authored-By: binhnt92 <binhnt92@users.noreply.github.com>