Fix: token reduction ignored as compression progress
NousResearch/hermes-agent · cluster 39548 · agent
Data as of
Nothing open on GitHub. Fix merged in #50726. Check it covers your case.
The short answer
- Known?
- Yes. 9 related items grouped here, 2 issues already closed.
- Fix event
- A fix was merged to main in PR #50726. Check it covers your case. No release data is tracked.
- Tracker
- The maintainers' tracker marks this
resolved, deciding PRs #50726, #50740. That is separate from the fix event. - Still open
- Nothing open on GitHub.
Multiple fixes and bug reports addressing a flaw where compression was considered unsuccessful if message count stayed the same, even when token count decreased. The criterion for compression progress was updated to include token reduction, not just row count.
Open issues0
Open PRs0
Fixes on record
-
#50726 fix(agent): count tokens, not just message rows, as compression progress (#23767, #39550)
files:
agent/conversation_loop.py,tests/run_agent/test_413_compression.pyShow the diff
-
agent/conversation_loop.py@@ -2983,6 +2983,7 @@ def _perform_api_call(next_api_kwargs): agent._buffer_status(f"⚠️ Request payload too large (413) — compression attempt {compression_attempts}/{max_compression_attempts}...") original_len = len(messages) + original_tokens = [redacted:secret-assignment] messages, active_system_prompt = agent._compress_context( messages, system_message, approx_tokens=[redacted:secret-assignment] task_id=effective_task_id, @@ -2992,8 +2993,18 @@ def _perform_api_call(next_api_kwargs): # messages to the new session, not skipping them. conversation_history = None - if len(messages) < original_len: - agent._buffer_status(f"🗜️ Compressed {original_len} → {len(messages)} messages, retrying...") + # Re-estimate tokens after compression. Same-message-count + # compression (tool-result pruning, in-place summarization) + # can materially reduce request size without reducing the + # message array. (#39550) + new_tokens = [redacted:secret-assignment] + approx_tokens = [redacted:secret-assignment] # update for downstream logging + + if len(messages) < original_len or (new_tokens > 0 and new_tokens < original_tokens * 0.95): + if len(messages) < original_len: + agent._buffer_status(f"🗜️ Compressed {original_len} → {len(messages)} messages, retrying...") + else: + agent._buffer_status(f"🗜️ Compressed ~{original_tokens:,} → ~{new_tokens:,} tokens, retrying...") time.sleep(2) # Brief pause between compression retries _retry.restart_with_compressed_messages = True break @@ -3139,6 +3150,7 @@ def _perform_api_call(next_api_kwargs): agent._buffer_status(f"🗜️ Context too large (~{approx_tokens:,} tokens) — compressing ({compression_attempts}/{max_compression_attempts})...") original_len = len(messages) + original_tokens = [redacted:secret-assignment] messages, active_system_prompt = agent._compress_context( messages, system_message, approx_tokens=[redacted:secret-assignment] task_id=effective_task_id, @@ -3148,9 +3160,18 @@ def _perform_api_call(next_api_kwargs): # messages to the new session, not skipping them. conversation_history = None - if len(messages) < original_len or new_ctx and new_ctx < old_ctx: + # Re-estimate tokens after compression. Same-message-count + # compression (tool-result pruning, in-place summarization) + # can materially reduce request size without reducing the + # message array. (#39550) + new_tokens = [redacted:secret-assignment] + approx_tokens = [redacted:secret-assignment] # update for downstream logging + + if len(messages) < original_len or (new_tokens > 0 and new_tokens < original_tokens * 0.95) or (new_ctx and new_ctx < old_ctx): if len(messages) < original_len: agent._buffer_status(f"🗜️ Compressed {original_len} → {len(messages)} messages, retrying...") + elif new_tokens > 0 and new_tokens < original_tokens * 0.95: + agent._buffer_status(f"🗜️ Compressed ~{original_tokens:,} → ~{new_tokens:,} tokens, retrying...") time.sleep(2) # Brief pause between compression retries _retry.restart_with_compressed_messages = True break @@ -3159,13 +3180,13 @@ def _perform_api_call(next_api_kwargs): agent._flush_status_buffer() agent._vprint(f"{agent.log_prefix}❌ Context length exceeded and cannot compress further.", force=True) agent._vprint(f"{agent.log_prefix} 💡 The conversation has accumulated too much content. Try /new to start fresh, or /compress to manually trigger compression.", force=True) - logger.error(f"{agent.log_prefix}Context length exceeded: {approx_tokens:,} tokens. Cannot compress further.") + logger.error(f"{agent.log_prefix}Context length exceeded: {new_tokens:,} tokens. Cannot compress further.") agent._persist_session(messages, conversation_history) return { "messages": messages, "completed": False, "api_calls": api_call_count, - "error": f"Context length exceeded ({approx_tokens:,} tokens). Cannot compress further.", + "error": f"Context length exceeded ({new_tokens:,} tokens). Cannot compress further.", "partial": True, "failed": True, "compression_exhausted": True, -
tests/run_agent/test_413_compression.py@@ -440,6 +440,48 @@ def test_413_cannot_compress_further(self, agent): assert result.get("partial") is True assert "413" in result["error"] + def test_413_retries_on_token_only_compression(self, agent): + """Same message COUNT but fewer TOKENS must count as progress and retry. + + Regression for #39550/#23767: tool-result pruning / in-place + summarization can shrink request size without dropping the message + count. The old gate (len(messages) < original_len) treated that as + 'cannot compress further' and aborted; the fix re-estimates tokens and + retries when they drop materially. + """ + err_413 = _make_413_error() + ok_resp = _mock_response(content="OK after token-only compaction", finish_reason="stop") + agent.client.chat.completions.create.side_effect = [err_413, ok_resp] + + # 3 large messages in, 3 much smaller messages out (same count, far + # fewer tokens) — exactly the token-only-progress case. + prefill = [ + {"role": "user", "content": "x" * 4000}, + {"role": "assistant", "content": "y" * 4000}, + {"role": "user", "content": "z" * 4000}, + ] + + with ( + patch.object(agent, "_compress_context") as mock_compress, + patch.object(agent, "_persist_session"), + patch.object(agent, "_save_trajectory"), + patch.object(agent, "_cleanup_task_resources"), + ): + # Same message count (3) but ~10x smaller content → token drop. + mock_compress.return_value = ( + [ + {"role": "user", "content": "x" * 300}, + {"role": "assistant", "content": "y" * 300}, + {"role": "user", "content": "z" * 300}, + ], + "compressed prompt", + ) + result = agent.run_conversation("hello", conversation_history=prefill) + + mock_compress.assert_called_once() + assert result["completed"] is True + assert result["final_response"] == "OK after token-only compaction" + class TestPreflightCompression: """Preflight compression should compress history before the first API call."""
-
-
#50740 fix(agent): count tokens, not just rows, as preflight compression progress (#23767, #39548)
files:
agent/turn_context.py,tests/agent/test_compression_progress.py
5 PRs closed without merging
From the close comments: done elsewhere 4 · merged via another change 1
-
#39673 fix(agent): improve context compression success criterion to include token reduction · done elsewhere →
33efff0,#50726,#50740,#39550,#39548 -
#39900 fix(agent): continue preflight compression when tokens decrease but message count is unchanged · done elsewhere →
33efff0,#50726,#50740,#39550,#39548 -
#41001 Fix #39550: Compression token savings ignored when message count unchanged · done elsewhere →
33efff0,#50726,#50740,#39550,#39548 -
#46987 fix(agent): detect token reduction in 413 path even when message count is unchanged · done elsewhere →
47b6b4c,#50726 -
#49579 fix #39550: detect token-only compression success when message count unchanged · merged via another change →
33efff0,#50726,#39574,#39673,#39900
Closed issues · 2
How this cluster was grouped
-
Link evidence (
structural links throughout): every member is connected by structural evidence: shared changed files, or a closing/superseded reference. -
Pairwise link density
0.26: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36.1.00means every pair is linked.
Pick up a Lab task
Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.
Open the Lab