Hermes `--resume` vs `--continue`: When Each Fits and the Stale-Session Trap

Hermes gives you two ways to re-enter an existing session and one to start a new one. --resume is a precision instrument; --continue is a convenience shortcut. Picking the wrong one wastes a turn or drags stale context into a new question.

The two flags, side by side

Both flags live on the top-level hermes command, so they work with any subcommand. Live output on Hermes v0.18.2 (2026.7.7.2):

  --resume, -r SESSION      Resume session by ID or title
  --continue, -c [NAME]     Resume by name, or most recent session

That short help line is the entire contract.

|| # | Flag | Resolves by | Requires | ||---|---|---|---| || 1 | --resume <SESSION> | Exact session ID (or title match) | The ID you intend, from hermes sessions list or a handoff | || 2 | --continue [NAME] | Most recent matching title; else most recent session for shell/profile/source | A clear “current session” — see the trap section | || 3 | (no flag) | Nothing — fresh session | Nothing; the safe default when the topic changes |

The first row is a coordinate: an exact point on the map. The second is a heuristic: “somewhere recent, named roughly like this.” The third is a reset.

What each flag actually does

hermes chat --resume <id> -q "Continue from where we left off." opens the session DB, loads the row with that id, replays every message into context with original roles and tool results, then appends the -q. The ID is the source of truth — whatever row it points to is the one you re-enter, even if hundreds of other sessions exist. Stable across profile switches, TUI restarts, reboots. Deterministic: no resolver, just a coordinate.

hermes chat --continue -q "..." skips the ID step and asks Hermes “what was I doing last?” — Hermes picks the most-recently-updated row for the current profile and source. If a cron fired two minutes ago, that’s the row. Convenient — no ID lookup — but tied to a resolver that can pick the wrong session silently (more on that below).

When each flag fits

The decision turns on how certain you are about which session you mean, how much the prior context matters, and how much friction the lookup is worth.

Use --resume <id> when the ID is in hand, the prior context is load-bearing (paths, account IDs, constraints, prior decisions), you are crossing a channel boundary (Telegram → CLI, subprocess → parent, cron output inspection), or you want the choice to be auditable. --resume <id> leaves a paper trail; --continue does not.

Use --continue [NAME] when you are still in the same working session, the friction of hermes sessions list exceeds the cost of trusting the resolver, and you named the session well. --continue "project X" matching a session titled Project X — week 3 works; --continue "project" matching whichever project was most recent does not.

Use neither — start fresh — when the topic changes, even a little (five thousand tokens of unrelated history is a tax on every turn), you are about to write to the database, or you are not sure which session you were on. A wrong --continue is worse than a fresh chat because it loads full context you did not ask for.

Mental shortcut: if you can copy an ID with confidence, --resume. If not and the topic is the same, --continue. If the topic changed, no flag.

The trade-off in one sentence

--resume trades a small up-front lookup cost for a guarantee about which session you re-enter; --continue trades that guarantee for zero lookup cost. Corollary: --resume is the write tool and --continue is the read tool. If the new turn produces state (a file, a config change, a deploy), use --resume so you know which session’s context is shaping it.

The three stale-session failure shapes

A “stale session” is any of: the flag resolved, the model responded, and the response was shaped by context that no longer matched the operator’s intent.

Shape A — --resume succeeds, joins the wrong session

You copied an old ID from a note. The ID is real, the row exists, the resume “works” — but the session is weeks old and the model’s first reply opens with based on our earlier discussion... referencing a thread you have not been on in a month.

Signal: the model assumes facts, paths, or commitments from a session you do not remember, or contradicts what you have been doing this hour.

Cheap-first check: hermes sessions list --limit 5 before issuing --resume. Confirm title, source, and Last Active match what you intended. Paste the full ID from that list, not from a copy-buffer note you cannot verify.

Fix: cancel, copy the correct ID, re-issue --resume. If the wrong session was already polluted, hermes sessions archive <wrong-id> and start fresh.

Shape B — --continue resolves to a thread you did not intend

You typed hermes chat --continue expecting the prior turn’s session. The resolver picked a more recent cron run, a Telegram thread, or a subagent handoff started after your last shell command. Your message lands in that thread, the model replies with full context you did not ask for, and the original session never sees your input.

Signal: the reply references events, files, or operators from a source you have not been on; or the title in the response header is unfamiliar.

Cheap-first check: add --continue with a NAME to narrow the resolver. If it pins to one match, you are safe. If it still picks the wrong one, fall back to --resume with an explicit ID.

Fix: archive the wrong thread with hermes sessions archive <id> to prevent future collisions, then re-issue with --resume <correct-id>.

Shape C — the TUI “session not found” 4001

The TUI-specific failure. You had a chat open, walked away for a few minutes, came back, and the next prompt failed with code=4001 "session not found". Root cause (per the tui-session-lifecycle-not-found skill): the TUI’s chat state lives in an in-process Python dict (_sessions in tui_gateway/server.py) wiped on any sidecar restart. The client still holds the previous session_id, and every prompt.submit returns 4001.

Signal: TUI only. hermes chat --resume <id> from the CLI is unaffected — CLI resume reads from /opt/data/state.db. Only the TUI’s in-memory dict is volatile.

Cheap-first check: ps -p <tui-sidecar-pid> -o pid,etime,cmd. An etime of under five minutes during an active chat is the smoking gun.

Fix: the durable TUI fix is to auto-recreate the session on any 4001 (session.create, retry with the new session_id). Until that ships, migrate the chat to Telegram — its sessions survive TUI sidecar restarts. This is technically a client-side --resume failure, but it is the most user-visible “stale session” symptom on ABS-class hosts.

The decision rule, in one line

Resume when you have an ID; continue when you don’t and the topic is the same; start fresh when the topic changes.

Keep that sentence in your shell history or runbook. The failure shapes are what happens when the rule is violated.

Verification checklist

|| # | Command | What it proves | ||---|---|---| || 1 | hermes --help shows --resume SESSION and --continue [SESSION_NAME] | Both flags exist. | || 2 | hermes chat --resume <known-id> -q "ping" | Resume joins by ID; reply uses that session’s context. | || 3 | hermes chat --continue after a recent chat | Resolver picks that chat; reply references the prior turn. | || 4 | hermes sessions list --limit 3 | IDs visible to feed back into --resume. | || 5 | hermes sessions list --source <your-source> | Scoping narrows --continue’s resolver. | || 6 | hermes sessions archive <id> | Cleanup primitive for Shape A / B recovery. | || 7 | ps -p <tui-sidecar-pid> -o pid,etime,cmd (TUI only) | Sidecar etime tells you if Shape C is live. |

If #1–#6 fails, the CLI surface drifted — update the guide. If #7 shows low etime during an active TUI chat, Shape C is live — switch the user to Telegram.

Sources

• Hermes Agent sessions docs
• Hermes Agent CLI reference
• ABS companion: Hermes Agent Sessions: Listing, Searching, Resuming, and Continuing
• ABS companion: Hermes Context Window: Budgeting for Long Sessions
• ABS companion: Hermes Agent Memory vs Skills
• Skill reference: tui-session-lifecycle-not-found — Shape C root cause and the in-memory _sessions dict at tui_gateway/server.py:118.

Last verified: 2026-07-14 against Hermes v0.18.2 (2026.7.7.2), /opt/data/state.db, and the TUI sidecar.