Run agents in parallel

Three projects, three chats, three agents — no state collision, no terminal babysitting.

The single most useful thing NightMe gives you isn't "control from your phone" — it's that each chat is an isolated shell against the same daemon. Once you internalise that, the bottleneck on "how many AI tasks can I run at once" stops being "how many laptops do I own" and starts being "how many chats do I want to scroll through".

The mental model

A NightMe session has exactly four independent axes:

That table is the whole architecture. Everything else — /steer, /stop, /diff, /gtw — is a thin command on top of "switch one of those four axes, then send the next message."

A parallel-session template

Pick three problems you actually have, not LLM-benchmark problems. For example:

• Chat A — refactor src/parser.rs to use nom.
• Chat B — write integration tests for cmd/nightme/config.go.
• Chat C — investigate a flaky test in pkg/daemon/dispatch_test.go.

Open three DMs (or group chats) with the bot — call them parser-refactor, config-tests, flaky-test. In each:

/cwd ~/code/project-a
/use claude

(then send the actual task)

Each chat runs its own agent. Each agent sees its own CWD. Each agent's tool calls are independent — Claude Code in chat A cannot Read a file in chat B's CWD because that file isn't even in chat A's CWD.

You can /steer chat A from your phone while you're staring at chat B's diff on your laptop. The two agents don't know about each other.

Per-chat status, in one glance

When you open the chat list on your phone, the last message in each chat is the status card from the most recent agent run. You'll learn to read the card the way you'd read an email subject line:

• Card shows "Agent: claude · Running · 12k tokens" → it's working, leave it.
• Card shows "Agent: claude · Done · patch in /cwd" → tap, read the diff, reply.
• Card shows "Agent: claude · Error: cargo test failed" → tap, see the trace, /steer with the fix.

That's it. Three chats become a Kanban board that lives in your pocket.

Sharing agents across chats

Sometimes you want two chats to talk to the same agent session — for example, a long-running migration where you'd like to think aloud in one chat and steer in another. NightMe supports this with /share <chat-id>:

/chat list
1. parser-refactor
2. config-tests
3. flaky-test

(in chat 4)
/share 1

Chat 4 now operates against the same Claude Code process as chat 1. The history is merged (interleaved by timestamp), and tool calls are visible to both. /unshare reverses the link.

Use this sparingly — the moment you share, the "one CWD = one project" mental model gets fuzzy. It's great for a long migration; it's a footgun for everyday work.

Token budgets per chat

By default each chat has no explicit budget — the underlying agent's context window applies. To cap spend on a noisy exploratory chat:

/budget 200k

The card starts showing a percentage used next to the token field. At 100% the daemon refuses further tool calls for that chat and asks you to /compact (which asks the agent to summarise its context) or /reset (which clears history but keeps the CWD/agent binding).

When not to parallelise

• Tasks that share state — if chat A's edits depend on chat B's, you're better off sequencing them in a single chat. Parallel runs of competing edits to the same files are guaranteed merge hell.
• Tasks where you don't know what "done" looks like — parallel agents are an answer to throughput. They're not a substitute for a clear spec. If you can't articulate the acceptance criteria, fix that first; one chat, full attention.

What's next

• Use /gtw for one-shot fixes — the next step beyond parallel chats: each chat runs in its own git worktree, so you can /gtw close and ship the branch without disturbing main.
• Write your first /gtw config — when you want every worktree to auto-run npm install before the agent starts typing.