Hermes agent memory limit: why writes fail at 2,200 characters

The limit is memory.memory_char_limit, it defaults to 2,200 characters, and you raise it in ~/.hermes/config.yaml. That is the whole fix. The part every other page gets wrong is when to apply it: the documented remedy — let the agent consolidate and retry — is itself checked against the same limit, so it stops working exactly when you need it. Raise the limit while there is still headroom, not after your agent has spent four turns failing to consolidate its way out.

At a glance

What the error actually means

Hermes keeps two curated memory stores and injects both into the system prompt on every turn. They are bounded by character count, not by disk: memory_char_limit defaults to 2,200 characters (roughly 800 tokens) and user_char_limit to 1,375 (roughly 500 tokens). Nous Research documents both keys and states the behaviour plainly — memory does not auto-compact, so when a write would exceed the limit the tool returns an error instead of silently dropping entries.

The refusal is quoted verbatim in the upstream issue that asks for larger defaults (hermes-agent #5320, opened 2026-04-05 and still open on 2026-09-02):

Memory at 2094/2200 chars. Adding this entry (X chars) would exceed
the limit. Replace or remove existing entries first.

Two things follow that are worth stating before you go looking for a workaround. First, 2,200 is not a considered ceiling for autonomous work — issue #5320 points out that the defaults were sized for roughly 800 tokens of context, and current models routinely carry 125k or more, so the curated-memory budget is a tiny fraction of what is available. Second, the limit is configurable. It used not to be, and issue #16831 — "Configurable memory character limit (currently hardcoded at 2,200)", opened 2026-04-28 — was closed on 2026-06-10. Any guide still telling you the cap is hardcoded is describing a version that shipped before June 2026.

Why telling Hermes to consolidate stops working

The documented recovery path is that the agent consolidates: it merges overlapping entries with a replace, then retries the write in the same turn. Every third-party guide on this error repeats that advice. It works — until you are close to the cap, at which point it silently stops working, and the failure looks like the agent being stupid rather than the tool refusing it.

We hit this running Hermes agents in production. One agent sat at 2,136 of 2,200 characters and lost 8 of its 9 memory calls in a single session, ending turns with Memory consolidation failed 4 times. The rejection it kept receiving was not the ordinary write refusal:

After applying all 2 operations, memory would be at 3,749/2,200 chars

Read that carefully, because it names the mechanism. The limit is checked against the aggregate total after the whole batch would be applied, and the batch is accepted or refused as a unit. A consolidation that adds a merged entry and removes the two it supersedes gets no partial credit for the removals — if the arithmetic of the combined operation does not land under the cap, all of it is refused. With 64 characters of headroom, essentially nothing but a strict net deletion survives that check, and a model asked to "consolidate" reasonably proposes a rewrite, not a deletion.

So the escape hatch closes precisely when it is needed. This is a property of when the check runs, not of how big the number is — which is why the fix is to raise the limit early, and why "ask it to consolidate again" is the one piece of advice that cannot help a wedged agent.

How to raise the Hermes memory limit

Add a memory section to ~/.hermes/config.yaml:

memory:
  memory_char_limit: 8000

That is the agent's own memory store, which is the one that grows. Raise user_char_limit only if the store that is failing is the user profile — it holds preferences, which do not accumulate the same way, so leaving it at its default is usually correct. Restart the agent so the new configuration is read, then ask it to consolidate: with real headroom, the batch that was being refused now lands.

If your agent is already wedged, raise the limit first. Trying to clean up before raising it is the loop described above.

What raising it costs

The memory file is injected into the system prompt on every turn, so this limit is a standing per-turn token budget, not a disk quota. Going from 2,200 to 8,000 characters adds roughly 2,100 tokens to every request, and it enlarges the cached prompt prefix that has to be rebuilt each time memory changes. On a 125k-context model that is a small share of the window, but it is a real recurring cost rather than a free win, and it is the honest reason the default is conservative.

The practical consequence: size the limit to what your agent genuinely needs to hold, not to the largest number the file will accept. An agent doing long-horizon work accumulates operational knowledge — API body shapes, credential paths, per-issue gotchas — and a few thousand characters of that is worth its prompt cost. Sixty thousand characters of unpruned history is not.

A bigger limit is not "unlimited"

Raising the number buys headroom to consolidate into. It does not remove the need to consolidate, and it is worth being clear about that because the failure recurs at any size. Hermes issue #32064, opened 2026-05-25 and closed 2026-06-08, reports a deployment that had already raised its limits to 8k and 3k characters and still hit the cap, losing operator corrections to failed memory.add calls.

The rule that follows from the mechanism: consolidation is reliable when the store is 40 percent full and unreliable when it is 97 percent full, so treat the fill gauge in the memory header as a maintenance signal rather than a warning light. Consolidate on a schedule, while it can still succeed.

Stop babysitting your OpenClaw box

Fix it once — or stop fixing it for good.

Apply the checklist above and keep self-hosting, or skip the maintenance entirely: run your OpenClaw on managed hosting from $6.90/mo, starting with a 7-day free trial. We handle the stale locks, gateway restarts, version upgrades, and uptime — and you can import your existing instance in a couple of minutes. Cancel anytime.

Managed hosting — from $6.90/mo Your own hosted OpenClaw instance with automatic restarts and version upgrades. Starts with a 7-day free trial — import your current setup, keep your channels, cancel anytime.

$199 managed setup — optional Prefer we do it for you? One workspace configured end-to-end: first-run config, one 30-minute onboarding/debug session, and a 7-day follow-up. Limited weekly slots.

• Managed hosting handles stale .jsonl.lock files, gateway restarts, and version upgrades for you
• Import your existing OpenClaw setup in minutes — keep your channels and configuration
• The optional $199 setup is scoped: no custom development, enterprise/SRE support, or unsupported self-hosting repair

If you would rather compare options first, review OpenClaw cloud hosting or see the best OpenClaw hosting options before deciding.

Run it on managed hosting — from $6.90/mo Prefer we set it up? $199 managed setup Compare the OpenClaw and Hermes runtimes

Hermes memory on managed hosting

We ran into this deadlock on our own hosted agents, so managed Hermes instances on Lobsterland ship with the limit already raised. Since 2026-07-29, every hosted Hermes instance is generated with memory.memory_char_limit: 8000 in its config.yaml, and a backend regression test asserts the generated value stays above 6,000 so it cannot quietly drift back to the upstream default. user_char_limit is deliberately left at the Hermes default, for the reason given above.

That is the whole managed claim, and it is worth being precise about the size of it: it removes one specific wedge, on one specific runtime, before you meet it. It does not make memory unlimited, and everything in this page about consolidation discipline still applies to a hosted agent.

If you want the runtime without the configuration surface, see managed Hermes runtime hosting. If you are still deciding which runtime to run at all, compare the OpenClaw and Hermes runtimes on the things that actually differ, or read the background on what the Hermes agent runtime is, and how it differs from the Hermes models. Already on OpenClaw and curious what carries over? Our guide to migrating an OpenClaw instance to Hermes covers what moves and what does not — and for the other side of that comparison, how QMD memory worked in OpenClaw explains a very different set of trade-offs.

FAQ

What is the Hermes agent memory character limit?

Hermes' curated memory is bounded by two character limits, both configurable in ~/.hermes/config.yaml under a memory section. memory_char_limit defaults to 2,200 characters (about 800 tokens) and covers the agent's own memory file; user_char_limit defaults to 1,375 characters (about 500 tokens) and covers the user profile. When a write would push a store past its limit, the memory tool refuses the write and returns an error rather than silently dropping entries.

Why does asking Hermes to consolidate its memory not fix the limit error?

Because the limit check is applied to the aggregate total after the whole batch would be applied, and the batch is accepted or refused as a unit. A consolidation that has to add a merged entry before the entries it replaces are removed never gets partial credit for the removals, so any batch that is not a strict net reduction is refused entire. Near the cap that leaves almost no room to manoeuvre, and the agent burns turns proposing consolidations that cannot be accepted. Raise the limit instead of asking for another consolidation.

How do I raise memory_char_limit in Hermes?

Edit ~/.hermes/config.yaml and add a memory section with memory_char_limit set to the value you want, for example 8000. Add user_char_limit alongside it only if the profile store is the one failing. The limit used to be non-configurable; the request to make it configurable was filed as hermes-agent issue #16831 on 2026-04-28 and closed on 2026-06-10, so any guide telling you the 2,200 cap is hardcoded is out of date.

What does raising the Hermes memory limit cost?

The memory file is injected into the system prompt on every turn, so the limit is a standing token budget, not a disk quota. Raising memory_char_limit from 2,200 to 8,000 adds roughly 2,100 tokens to every request and enlarges the cached prefix that has to be rebuilt whenever memory changes. On a modern 125k-context model that is a small fraction of the window, but it is a real per-turn cost — raise the limit to the size your agent actually needs rather than to the largest number the file will hold.

Does raising the limit remove the need to consolidate memory?

No. A larger limit is still a limit, and a long-horizon agent will reach it. Hermes issue #32064, filed on 2026-05-25, reports a deployment that had already raised its limits to 8k and 3k characters and still hit the cap, losing operator corrections to failed writes. Raising the number buys headroom to consolidate into; it does not remove the need to consolidate. The practical rule is to raise it well before the store is full, because consolidation is reliable at 40 percent full and unreliable at 97 percent full.

Sources

• Nous Research, Hermes Agent documentation — "Persistent Memory" (memory_char_limit and user_char_limit defaults, configuration location, and the no-auto-compact behaviour).
• NousResearch/hermes-agent issue #5320, "raise/auto-scale memory_char_limit defaults and surface usage pressure" — opened 2026-04-05, open as of 2026-09-02; source of the quoted rejection string.
• NousResearch/hermes-agent issue #16831, "Configurable memory character limit (currently hardcoded at 2,200)" — opened 2026-04-28, closed 2026-06-10.
• NousResearch/hermes-agent issue #32064, "Fix bounded memory: durable unlimited user memory with retrieval" — opened 2026-05-25, closed 2026-06-08; the deployment already at 8k/3k that still hit the cap.
• Lobsterland production observation and the resulting configuration change, 2026-07-29: the measured 2,136/2,200 deadlock, and the generated memory.memory_char_limit: 8000 for hosted Hermes instances.