Ever kept one chat open from Monday to Friday, watched the context grow heavier and pricier with every reply — yet Hermes never seemed to get smarter, or even remember the preference you told it last week? A developer shared his own version of that story this week (I think I used the Hermes Agent wrong), and his conclusion is worth a close look: the problem may be that he almost never ended a session.

Running Hermes on a Raspberry Pi with Telegram, he went 18 days on just 5 sessions — every evening the Pi shut down, every morning Hermes quietly resumed the previous session. The result: across 1,990 messages, Hermes proactively used session_search (the cross-session recall tool) only 9 times, and the memory files barely changed. The reason is not that the agent got dumber. Everything important was still sitting in the context window, so there was nothing to remember. Hermes’ long-term memory, though, is explicitly designed around the assumption that sessions do end.

How Hermes memory actually works

Hermes keeps two kinds of persistent memory, and understanding each one explains why boundaries matter.

The cross-session notes: MEMORY.md and USER.md. Every profile holds these text files (plus optional SOUL.md): USER.md stores facts about you, MEMORY.md stores notes and preferences Hermes has accumulated. At the start of a new session both files are injected into context so Hermes “remembers” who you are and what you learned. But they are size-capped — the source defaults are memory_char_limit: 2200 and user_char_limit: 1375, roughly 800 and 500 tokens. Near the cap, Hermes must use its memory tool to merge, trim, and prioritize — keeping what matters most.

The full transcript store: state.db. Every message lives in a local SQLite database. session_search is the tool that lets Hermes look outside the current session — “how did I fix that CI failure last time?” That is the other half of the design: when context cannot hold everything, retrieval brings old details back.

And when does writing happen? Besides explicit memory-tool use mid-conversation, Hermes runs background review: after a turn it asynchronously revisits the conversation and distills what is worth persisting — lessons, corrections, preferences. That loop only works properly when sessions have natural endpoints: settle a batch at the end, inject it at the next start, rinse and repeat.

What happens when you never end a session

Map that design onto an 18-day single session and the failure mode is obvious:

• Memory files become decoration. MEMORY.md/USER.md inject at session start — in a mega-session their content is already in context, so Hermes never needs the files to “recall” anything, and background review sees nothing worth updating. They quietly go stale.
• session_search rarely fires. The tool exists for “not in context, but in history.” In an endless session, last week is still in the window, so retrieval has no job. Nine uses per 1,990 messages is not stupidity — it is a tool with nothing to do.
• Cost and latency climb. Every turn resends the ever-growing history to the model; the token bill scales with session length. Near the window limit, compression kicks in and folds old content into summaries — lossy summaries, where details quietly evaporate.
• You lose memory layering. The mega-session blurs short-term context and long-term memory into one pot. Remembering everything means remembering nothing precisely: long-lived preferences that belong in a note, and one-off details that belong in search, all stew together.

When to start fresh, when to resume

The good news: the rule is simple. Is the task still in progress?

Resume the session when:

• The same task is unfinished — just paused (you stepped away mid-way through a long doc);
• Transient context (a file path, the exact code you are debugging) is needed in the very next step and not worth re-explaining;
• You are toggling between tasks in one terminal and want each thread’s history intact.

Start a new session when:

• The last task is delivered or clearly done — even “done for now” counts;
• The topic changed and the two tasks share no context you must carry over;
• Context is already large (watch token usage in the status bar or hermes status-style views) and the new task will not use the old content;
• You want Hermes to actually remember this conversation — ending it lets background review distill the takeaways.

The right way to switch: before starting something new, ask Hermes to write any keep-worthy conclusions into memory, or archive the conversation with the /save command we covered earlier. When you do resume, the hermes chat -c per-terminal resume trick keeps each terminal on its own thread. And if session data ever misbehaves, our session-incident field guide walks through diagnosis and recovery.

Make session boundaries a habit

The developer’s story is worth sharing because he did not hit a bug — he hit a usage mismatch, using a memory system built for many sessions as if it were one endless thread. You do not need to end sessions on a timer; just open a fresh one naturally when a task wraps up. That lets file injection, background-review settling, and session_search retrieval each do their job. Sessions with boundaries give memory a cycle — and a Hermes that actually remembers you is the one you installed it for.