Troubleshooting Hermes Agent When It Runs Out of Context — Discard the Half-Done Work and Restart Clean

You’ve got a loop running: hand Hermes Agent an issue, and it produces the PR. Just as the implementation gets interesting, this comes back and everything stops.

Context length exceeded (301,411 tokens). Cannot compress further.

You try /compress. Nothing. Run it again and the same line comes back, the conversation not one token shorter. So you save your state and open a fresh session, and now the context you painstakingly built up is gone. Anyone who runs Hermes Agent on long tasks hits this wall eventually.

This post is a troubleshooting tip for exactly that: taking Nous Research’s Hermes Agent from that stuck state (context exhausted, compression dead) all the way to finishing the half-written PR and closing the issue. There’s really only one point to it: what you actually need to lean on isn’t the conversation history, it’s the progress you’ve committed and the issue, which live outside the context window. If you want to run Hermes Agent locally, I’ve written that up separately.

The short version

If you’re just here to get unstuck:

1. Try /compress first. If the context frees up, keep working
2. If it’s locked with Cannot compress further, don’t fight it, run /new. Discard the half-done changes with git restore . (or git clean -fd to remove untracked files too) and switch to a clean session
3. In the new session, hand it the same issue again and have it continue. Hermes Agent picks up the committed diff and the issue on its own. Finish the PR, and as long as it’s linked with Closes #123, merging it closes the issue

The trick is not to try to keep the overflowed conversation alive. The state worth relying on (your committed progress and the issue) already lives outside the context, so it’s faster to throw the conversation away and rebuild clean. The rest of this post is why that’s enough. If you’re not in a hurry, read on.

Why Cannot compress further happens

First, let’s be precise about what Cannot compress further actually is. It isn’t the simple story of “the context filled up.” It’s the state where the compression machinery has switched itself off.

Hermes Agent runs two layers of compression. One is the Agent ContextCompressor, which operates inside the agent’s loop, looks at the accurate token counts the API reports, and fires by default when the context hits 50% (threshold: 0.50). The other is Gateway Session Hygiene, a safety net that fires at 85% to keep long-lived sessions on chat platforms like Telegram or Slack from ballooning overnight and failing the API. In normal conversation, it’s the former doing the work.

Compression itself runs in four phases. It replaces long tool outputs (over 200 characters) with stubs, decides the boundaries of a protected head (system prompt and first exchange) and a protected tail (the most recent protect_last_n: 20 messages), folds the middle into a structured summary via an auxiliary LLM, then reassembles head, summary, and tail. That summary carries Goal, Constraints, Progress (Done / In Progress / Blocked), Key Decisions, Relevant Files, Next Steps, and Critical Context. In other words, compression is the act of folding a conversation down into the handoff notes you’d need to continue it.

The trouble comes when folding stops shrinking anything. Hermes Agent has an anti-thrashing lock: if compression fires twice in a row and each pass saves less than 10% of the tokens, should_compress() permanently returns False until you run /new to reset the session. There’s no timeout and no decay. When the conversation has already been condensed to the point where only the essentials remain, running compression again saves nothing meaningful, so the lock engages. /compress doing nothing isn’t a bug, it’s the designed consequence. Use a long implementation session that pushes context to the brim and you land here fairly naturally.

/save doesn’t dissolve a full context

Here’s the move people reach for next: /save. Hermes Agent does have a /save command, and it “saves the current conversation.” On top of that, Hermes Agent writes every conversation to ~/.hermes/state.db (SQLite, with FTS5 full-text search) as it goes. The session ID, model configuration, a snapshot of the system prompt, and the full message history with per-message token counts all persist automatically. So the means to save a conversation and pull it back later is generously provided.

The catch is that being saved is not the same as being able to continue. What /save saves, and what auto-persistence keeps, is the same enormous conversation you just overflowed. Read it back with /resume or hermes --continue and you’re simply standing at the starting line again, holding a full context, with no room for the next move. “Saving the conversation” and “distilling out the state you need to the far side of the context” are two different jobs. This post is about the second one.

/new does not carry your context forward

So should you just start over with /new? Here’s the trap that’s easy to miss. /new genuinely begins a blank session, and it carries neither the memory nor the context of the previous conversation. The moment you type /new payments-refactor, a separate thread spins up with no access whatsoever to what came before.

Turn that around and it means: the only things the agent knows right after /new are the things persisted outside the context window. In Hermes Agent, what survives across sessions is this:

• Memory: it remembers facts and preferences about you, recalled automatically by relevance
• Skills: it remembers procedures and steps, reused on similar tasks
• Past sessions: full-text searchable via the session_search tool, so the agent can pull up old conversations on its own
• And above all, the repository itself: branches, commits, PRs, issues, and the working-tree files

This is the crux. For the task of a half-written PR, the state most reliably parked outside the context window is not the agent’s memory, it’s the git branch and the PR. The work you’ve committed is etched into history, and the intent is written in the issue. Both cross over to the far side of /new without spending a single token. So designing the re-anchor is the same as designing how you lean on the state that already lives outside the context, rather than trying to rescue what’s inside the conversation.

The re-anchoring pattern: finish the PR, close the issue

With that in place, recovering from Cannot compress further turns out to be almost anticlimactically blunt. Rather than trying to keep the current conversation alive, it’s usually faster to throw it out and rebuild.

flowchart TD
    A["Context length exceeded"] --> B{"Does /compress help?"}
    B -- "Yes" --> H["Context frees up<br/>keep working"]
    B -- "No, it's locked" --> C["Cannot compress further"]
    C --> C2["Discard the half-done changes<br/>git restore ."]
    C2 --> D["/new: a clean session"]
    D --> E["Re-read the issue and committed diff"]
    E --> F["Re-implement the rest cleanly and commit"]
    F --> G["Finish the PR<br/>merging closes the issue"]

The actual move is refreshingly simple: the half-finished changes left in the working tree, you don’t try to carry forward. You throw them away.

An agent that has burned through its context usually leaves the working tree in an unstable, half-edited, half-reverted state. Wrapping all of that in a WIP commit and having it write handoff notes to pass carefully to the next session is a lot of effort for little gain in handoff quality. It’s faster, and the result is cleaner, to discard the half-done diff with git restore . (or git clean -fd to remove untracked files too), get back to a clean working tree, and re-implement from a fresh session.

The state worth relying on is already sitting outside the context: the progress you’ve already committed (the branch and the PR) and the goal written in the issue. These survive even when the conversation is gone, so when you hand the /new session the same issue, it picks up the committed diff and the issue on its own and grasps “how far along we are and what’s left” from a clean slate. From there, have it implement the rest, commit, and finish the PR; as long as the PR is linked to the issue (a Closes #123 line), merging it closes the issue on its own, and you arrive at the goal you set out with. The half-done diff you threw away, rewritten with a clear head, usually comes back as more straightforward code anyway.

One aside: if you’re before the Cannot compress further lock and don’t yet want to throw away the conversation’s memory, instead of /new you can switch to a larger-context model with /model. The history is preserved while only the container widens, and it often lets you run straight through. The lock is only a declaration that “no more folding is possible in this container”; it doesn’t close off the option of swapping the container.

The more fundamental fix: don’t overflow the context in the first place

Having a re-anchoring pattern on hand matters, but doing this every time is a chore. Fundamentally, it’s more effective to lean toward designs that never burn through the context in a single session.

• Cut tasks small: rather than clearing one whole issue in one session, break it into investigation, implementation, and testing, and land a clean commit at each seam. If you commit often, then even when the context overflows mid-way, the only thing you discard and redo is the most recent seam
• Offload to subagents: Hermes Agent can delegate tasks to a subagent with its own conversation and execution environment. Run token-hungry steps like investigation in an isolated context and only the result returns to the parent, leaving the main context intact
• Rein in tool output: as the fact that compression’s first phase prunes long tool outputs suggests, dumping huge logs or entire files whole is what eats context fastest. Simply getting into the habit of reading only the range you need extends the lifespan
• Size the container up front: if you can see a long haul coming, pick a large-context model from the start via --model or the config context_length

The root of all of these is the same: treat context as a finite, precious resource. The longer the work you give an agent, the more it pays to keep landing valuable state as clean commits outside the conversation rather than hoarding it inside. The conversation may evaporate, but committed progress survives. This stance isn’t specific to Hermes Agent; it’s shared by any coding agent with a context window.

Wrapping up

Context length exceeded. Cannot compress further. is a designed endpoint, the moment the agent can no longer fold the conversation any further into essentials. Here’s how the recovery lays out:

1. /compress doing nothing is the consequence of the anti-thrashing lock, not a fault. /save and auto-persistence can preserve the conversation, but reading a saved conversation back just returns you to a full context, so saving alone doesn’t get you unstuck
2. /new carries forward neither memory nor context. What you rely on is the state already outside the context window: the progress you’ve committed (the branch and the PR) and the goal in the issue. Don’t try to rescue the half-done working tree, discard it
3. In a fresh, clean session, re-read the issue and the committed diff, re-implement the rest, and finish the PR; with the PR linked to the issue, merging it closes the issue automatically
4. The upstream fix is to not overflow the context at all: cut tasks small, offload to subagents, rein in tool output, and size the container up

The longer and heavier the work you delegate to an agent, the more the principle earns its keep: the conversation is volatile, so put durable state outside. An overflowed session isn’t a failure; treat it as the signal to push your state out.

That’s a field note from someone who has handed AI agents long implementations and hit the context wall more than a few times, on how to live with Cannot compress further.