Hermes Context Window: Budgeting for Long Sessions

The budget

The Hermes context window has a per-conversation token budget. For long sessions (multi-hour, multi-skill), the budget is the limiter. The operator’s discipline is to keep the budget lean — keep what’s needed, compress what’s stale, drop what’s noise.

What this looks like in practice: a session that opens with one task, then pivots to another, then a third is three different conversations sharing one window. The first two have earned their keep up to the pivot; the moment the new task starts, the prior turns should be summarised and the originals dropped. The window is not a journal — it is the model’s working memory for right now.

A rough guide: 50 turns of full history plus a loaded skill plus the core toolset is enough to make a model slow, repeat itself, and start citing tool output from 20 turns back. None of that is the model getting dumber — it is the model working harder to find the relevant signal inside a noisy context.

Three sources eat the budget:

1. Tool definitions — every tool in the loaded toolsets consumes tokens. Loading the full toolset (shell, file_edit, browser, etc.) costs ~6k tokens; loading only the relevant subset saves it.
2. Skills — every skill_view loads the skill’s full text into context. A skill that gets loaded twice costs double. A skill that’s no longer relevant can be unloaded.
3. Conversation history — every prior turn costs tokens. A 50-turn session with full history consumes more budget than a 50-turn session with periodic compaction.

What to keep

• The current task’s working memory: variables, paths, the operator’s key constraints.
• The skill that the operator is currently using.
• The recent (last 5-10) turns of conversation history.

A simple test: if the operator types “now do the same thing for X” five turns later, what does the model need in context to do it? That is what stays. Everything else is a candidate to summarise or drop.

Working memory deserves care. Any path, hostname, account ID, or constraint the operator mentioned early and reused later is load-bearing — losing it forces a re-ask and a re-search, which costs more than keeping it would have.

What to compress

• Verbose tool outputs: trim to the decision-relevant line.
• Repeated citations: keep one, drop the rest.
• Long explanations: summarize to the operator-relevant takeaway.

The model itself can do compression — ask it. “Summarize the last 20 turns to 5 bullet points” is a legitimate instruction that saves budget going forward.

A useful pattern: the moment a long tool output arrives (ls -la, cat, JSON dumps), decide whether the next operator message needs it verbatim or just the takeaway. If the takeaway, store the takeaway and let the rest drift naturally. The model is good at “we don’t need that long ls anymore, just remember there are 14 files including a sitemap.xml” — let it.

What to drop

• Debug traces that resolved.
• Failed approaches that the operator won’t retry.
• Tool outputs the operator never responded to.
• The first 30 minutes of a session if the task is in a different lane now.

A “resolved debug trace” is any tool output whose problem has since been fixed — the trace is now noise. Same for a failed approach that has been ruled out.

The “lane drift” case is the easiest to miss. A session that opened as “help me install hermes on a Mac” might end at turn 60 writing a memory note about the deployment. Summarise the first 30 minutes explicitly when the lane switches. The model has no implicit signal that the topic changed.

The per-tool budget

Loading toolsets:

hermes chat --toolsets shell,file_edit -q "..."

Or in the gateway’s config. Most operators keep shell, file_edit, process loaded at all times (8k tokens); add browser or web only when needed (~5k tokens each).

For the gateway, the same discipline applies under tools: in config.yaml. The gateway loads every enabled tool for every session — an idle Telegram chat still pays for code_execution and browser if they are enabled. A practical pair: core (shell, file_edit, process) always-on, web only when an outbound fetch is in flight, browser only when something genuinely needs a browser session. Toggle a tool mid-session via /tools if the model suddenly needs something it doesn’t already have.

The tradeoff is real: turning a tool off saves tokens every turn, but adds a round-trip the first time the operator asks for it. The habit that earns its keep: enable a tool only when the next 30 turns are likely to use it.

The per-skill budget

# Loaded once at session start
skill_view name=hermes-agent-skill-authoring

# Re-loaded later when the operator goes to use it
skill_view name=hermes-agent-skill-authoring

Each skill_view is one read; skills stay in context until the conversation ends or the model unloads via a clear “we don’t need this anymore” turn. The operator can’t manually unload.

Two practical levers are available to the operator. The first is progressive load: do not preload all relevant skills at session start. Preload only the one or two the operator will definitely need within the first 20 turns; load the rest on demand. The second is explicit unload: tell the model in plain English that the skill is no longer in scope (“we are done with the marketing-writeup skill for this session, drop it from context”).

A loaded skill that is no longer relevant is the cheapest budget to recover. The model will not drop it on its own — the cost of carrying it is too small to cross an internal threshold.

What not to do

• Don’t load all toolsets just because they might be useful — pick the working subset.
• Don’t load every relevant skill at the start of a 6-hour session — load as you go.
• Don’t keep failed exploration in history — close that chapter out explicitly.
• Don’t push the operator to type “summarize what we’ve done” at the start of every turn — but do it at major task transitions.

The most common operator failure mode is the opposite of the rules above: the operator treats the context window as free real estate, loads everything, lets everything accumulate, and only notices the budget is gone when the model starts misbehaving. By that point the session is too long to compact cleanly and the operator is forced into a fresh hermes chat with a hand-written recap. The habit that avoids this is frequent small compactions, not heroic last-minute rescues.

The second failure mode is treating /compress (or its equivalent) as a one-time big red button rather than a routine. The slash command is fine; triggering it at every pivot, every 20 turns, or whenever a long tool output lands is what actually keeps the session tractable.

The trigger pattern

The operator’s signal that a session is getting heavy is when:

• The model starts repeating itself verbatim.
• The model cites tool output from 20 turns ago.
• The model gets confused about which file path is canonical.

Each is a budget signal. The first two mean the model is searching its context and not finding what it needs cleanly. The third means the model’s working memory has lost the canonical path — it is now guessing from the last path-shaped string it saw. None of these are model-quality problems; they are window-quality problems.

Run a compaction:

hermes chat --new-session --resume-from <previous_sha> -q "Continue <task>; recap: <operator-pasted summary>"

A new-session + resume keeps the operator’s working memory but trims the long tail. A typical worked example: a 6-hour session cycling through install, configure, smoke-test, write-a-guide. The trigger fires on the smoke-test step — the model cites the install transcript from 90 minutes ago and contradicts itself on what --toolsets was set to. The operator’s move: capture the current state in 8 bullets, open a new hermes chat with --resume-from, paste the recap as the first message, and continue from the smoke-test result.

Verification checklist

#	Signal	Action
1	Model repeats itself	Compact
2	Model cites old output	Compact
3	Model confused on paths	Compact + explicit paths in user message
4	Session >30 minutes	Compaction as a habit

Sources

• Hermes Agent memory docs
• Hermes Agent skills docs
• ABS companion: Hermes Protocol: The System Prompt, the Context Window, and the Rule Boundary
• ABS companion: Hermes Agent Memory vs Skills

Last verified: 2026-07-14 against Hermes v0.18.2 (2026.7.7.2).