HHermes Explained

Runtime

Compression

The process that keeps long sessions usable by reducing accumulated context into durable summaries.

Importance 4/52 backlinks1 source refs

Compression

What it is

The process that keeps long sessions usable by reducing accumulated context into durable summaries.

In plain terms

It’s a bit like how a long meeting’s minutes get written up afterward: the secretary doesn’t erase the first two hours once new discussion piles up — they boil that stretch into a short summary while writing the most recent exchanges out in full. Compression does the same thing to a growing conversation, folding older exchanges down instead of deleting them outright.

Why it matters

Sessions that run for days accumulate history fast enough to threaten context limits, and compression is what keeps that growth manageable by folding older turns into durable summaries instead of simply discarding them. This matters most for VPS-deployed agents that stay in one long-running session, where an uncompressed transcript would eventually make every subsequent model call slower and pricier. Tune it too aggressively, though, and the agent starts forgetting details a user assumed were still ‘in context.’

How it works

ContextCompressor.should_compress (agent/context_compressor.py) checks accumulated tokens against a threshold sized to the active model’s context window, with a guard that backs off if the last couple of compressions barely helped. When it fires, compress() first prunes old tool outputs down to one-line summaries — “ran npm test → exit 0” rather than the full log — then protects the system prompt plus a token-budgeted tail of the most recent exchanges, and hands everything in between to a separate summarization call through agent/auxiliary_client.py. By default that call reuses the very same model already running the conversation — Hermes deliberately avoids quietly switching side tasks to a cheaper model — though an operator can configure a dedicated summarization model instead. Re-compressions update that summary iteratively rather than starting over. The result is spliced back in labeled explicitly as reference-only background, so the model can’t mistake an old summarized request for something it still needs to act on.

A concrete example

A VPS-hosted session has been running for four days straight, and the transcript has ballooned past the model’s comfortable context size. On the next turn, Hermes prunes dozens of old tool-call logs down to single lines, protects the last stretch of real conversation untouched, and runs a summarization call over everything older than that, folding it into a few structured paragraphs. That turn takes a little longer than usual, since the summarization call runs before the actual reply — but the model then works from a summary of day one plus the full detail of what happened an hour ago, instead of choking on four days of raw transcript.

How it connects

This note belongs to the Runtime family. Its closest neighboring concepts are: Retry And Fallback, Session State, Personal OS.

Source evidence

  • vendor/hermes-agent/agent/conversation_loop.py:593-603#run_conversation — Verified Source Map evidence for run_conversation. The conversation loop injects the active prompt, plus any ephemeral prompt, as the first system message, builds provider request kwargs from api_messages, and sends the representative streaming branch through LLM execution middleware to _interruptible_streaming_api_call.

Workflows

  • No first-pass workflow mapping yet; this concept still appears in the vault graph through articles and source evidence.
  • Inside Hermes: How the Agent Loop, Context, Memory, Gateways, and Cron Jobs Work Together