Background Sessions as Parallel Work

+15 Mana ✨
Background Sessions(DOCUMENTATION)

Introduction

Some tasks are not part of your main conversation but you still want them done. "Summarize last week's commits", "check the test suite while I plan the next refactor", "draft the release notes in parallel". Hermes' /background command spawns a separate, isolated session that runs alongside the current one. It inherits your runtime (model, provider, tools, reasoning) but has no shared history. The current session keeps going. The background session reports back when it is done.

Key Concepts

  • /background <prompt> (aliases /bg, /btw): Launch a parallel isolated session.
  • Inherited runtime: Same model, provider, tools, reasoning as the current session.
  • No shared history: The background session does not see your conversation; the current session does not see its work.
  • Numbered IDs: Each background session gets an ID like bg_143022_a1b2c3 so you can refer to it.
  • Non-blocking: Your foreground session is fully interactive while the background runs.

Real World Context

A developer is deep in an architecture discussion with Hermes about refactoring a service. They remember they need to draft release notes for the last sprint. Instead of switching context, they type /bg draft release notes for the past two weeks of commits on main. A background session spins up, the foreground discussion continues, and ten minutes later a panel pops up with the drafted notes. The developer reviews, copies, and never had to leave the architecture conversation.

Deep Dive

A /background invocation starts a new daemon session in the same Hermes process:

text
> /background draft release notes for the past two weeks of commits on main
[bg_143022_a1b2c3 spawned]

> ... continues the foreground conversation, fully interactive ...

[later, the background completes]
[bg_143022_a1b2c3 complete, open panel? (y/N)]

The background session:

  • Inherits your runtime settings: Same model, provider, tools, reasoning, and SOUL.md.
  • Does NOT inherit your conversation history: It starts fresh. You cannot say "continue from where we were" because there is no shared "we".
  • Has its own session ID: Used internally for tracking and resumption.
  • Reports back via terminal panels: When complete, the output appears as a distinct panel you can open or dismiss.

You can run several background sessions at once. Each has its own ID, its own context, its own work. Track them with /agents (alias /tasks):

text
> /agents
  Active background sessions:
    bg_143022_a1b2c3   draft release notes...               running   2m
    bg_143055_d4e5f6   summarize last week's commits...     running   1m
    bg_143100_g7h8i9   run pnpm test and report any...      done      30s

Stop a background session with /stop (kills all backgrounds) or its specific control. Background output never automatically merges into your main conversation; you read it in the panel and decide whether to act on it.

When to use background

  • Detached one-shot tasks: "Draft these release notes". You do not need to discuss; you need the output.
  • Long-running checks: "Run the full test suite and tell me what failed". The current conversation can continue.
  • Parallel exploration: "Try the refactor a different way over there" while you continue the architecture discussion here.

When NOT to use background

  • Conversational tasks: If the work requires back-and-forth, you want the main session, not background.
  • Tasks that depend on current context: Background does not see your conversation. If the task needs to know what you discussed, give it that context explicitly in the prompt, or do not use background.
  • Stateful workflows: Each background session is one-shot. For multi-step background work, prefer scheduled cron-style automation (a later course).

Common Pitfalls

  1. Expecting background to remember the main conversation: It will not. The two are isolated by design.
  2. Spawning too many simultaneously: Each background session consumes its own tokens and runtime. Three to five running at once is reasonable; thirty is a mess.

Best Practices

  1. Make the background prompt fully self-contained: Include any context it needs, because it cannot see your conversation.
  2. Use /agents to keep track: Especially in longer sessions, the background panel can be easy to forget.
  3. Reach for /bg for genuinely detached tasks: Architecture-discussion tangents that deserve their own session, not /steer or interrupt territory.

Summary

  • /background (aliases /bg, /btw) spawns a parallel isolated session.
  • It inherits runtime settings but not conversation history.
  • Each background session gets a numbered ID; track them with /agents.
  • Use for detached, self-contained tasks; not for conversational or stateful work.

Code Examples

text
# Spawn three parallel background sessions while keeping the main conversation alive

> /bg draft release notes for the past two weeks of commits on main
[bg_143022_a1b2c3 spawned]

> /bg run pnpm nx test backend and summarize any failures
[bg_143055_d4e5f6 spawned]

> /bg list every file in src/auth that imports lodash, group by file path
[bg_143100_g7h8i9 spawned]

# Foreground conversation continues uninterrupted...

> /agents
  Active background sessions:
    bg_143022_a1b2c3   draft release notes...   running   2m
    bg_143055_d4e5f6   run pnpm nx test...      done      45s
    bg_143100_g7h8i9   list lodash imports...   done      12s
✓ Completed