| name | orca |
| description | Spawn and manage parallel AI coding agents via tmux. Use when you need to orchestrate workers, delegate sub-tasks, run multi-agent improvement loops, or manage agent lifecycles with orca CLI commands like spawn, list, kill, steer, logs, and daemon. |
Orca — Agent Orchestrator
One-time setup: see references/SETUP.md if orca is not already on your PATH.
You are the orchestrator. Use the orca CLI below. You never need tmux knowledge.
Identify yourself
Before using Orca, determine which agent you are and jump to your section:
--spawned-by rules
Every orca spawn must include --spawned-by so the daemon knows parent → child links and where to route notifications.
OpenClaw (L0 orchestrator):
--spawned-by openclaw — OpenClaw is the only true L0 orchestrator. It lives outside tmux and receives notifications via openclaw system event.
cc / cx / cu (always in tmux):
- Check
ORCA_WORKER_NAME in your environment.
- If set: you are a worker —
--spawned-by "$ORCA_WORKER_NAME" (the plain name from orca list, e.g. fin, mud), NOT the emoji label, NOT openclaw.
- If not set: you are the L0 orchestrator —
--spawned-by self. Orca auto-detects or generates your L0 pane name.
Workers spawning sub-workers:
- Same rule:
--spawned-by <your-worker-name> from ORCA_WORKER_NAME or orca list.
OpenClaw (L0 orchestrator)
You are an OpenClaw agent — the only true L0 orchestrator. Notifications go via openclaw system event, not tmux. The user only sees results if you route them explicitly via openclaw message send.
orca spawn "fix the login bug" -b cc -d ~/proj --orchestrator openclaw \
--reply-channel slack --reply-to C0AGZA4178Q --reply-thread 1234567890.123456 \
--spawned-by openclaw
| Flag | Required? | Notes |
|---|
--orchestrator openclaw | Yes | |
--spawned-by openclaw | Yes | L0 orchestrator marker |
--reply-channel | Yes | slack, telegram, discord, etc. |
--reply-to | Yes | Channel ID or user ID for delivery |
--reply-thread | Yes, if in a thread | Set to the topic_id from the inbound message metadata. Required when the user is in Slack thread mode — omitting it causes the completion notification to land in the DM/channel root instead of the thread. |
--session-id | No | OpenClaw session ID for scoped killall/gc |
--pane | No | Not used — OpenClaw delivers via system events, not tmux panes |
Without --reply-channel and --reply-to, orca spawn will fail. Set ORCA_ALLOW_OPENCLAW_WITHOUT_REPLY=1 only for automation.
Thread mode rule: If the inbound message metadata contains a topic_id (Slack thread), always pass --reply-thread <topic_id>. The topic_id is the root message's thread_ts. Note: --session-id and --reply-thread are separate concerns — --session-id controls which OpenClaw session gets woken on completion; --reply-thread controls where the completion notification is delivered.
When you receive the completion event:
- Run
orca logs <name> to review the output
- Summarize the results (include PR links if any)
- Send the summary via
openclaw message send --channel <ch> --target <target> [--thread-id <thread>] --message <summary> (include --thread-id if spawned from a thread)
- Do NOT reply in-session — the user won't see that. Use
openclaw message send.
Claude Code (cc / claude)
You must be running inside a tmux pane. Orca auto-detects your tmux pane for notification delivery — this does not work outside tmux. If a human launched you as the orchestrator, they must have started your session inside a tmux window first.
Check ORCA_WORKER_NAME in your environment:
- If set: you are a worker —
--spawned-by "$ORCA_WORKER_NAME"
- If not set: you are the L0 orchestrator —
--spawned-by self
orca spawn "fix the login bug" -b cc -d ~/proj \
--orchestrator cc --spawned-by "$ORCA_WORKER_NAME"
orca spawn "fix the login bug" -b cc -d ~/proj \
--orchestrator cc --spawned-by self
| Flag | Required? | Notes |
|---|
--orchestrator cc | Yes | Tells the daemon to send completions to your tmux pane |
--spawned-by <name> | Yes | $ORCA_WORKER_NAME if set, or self if L0 |
--pane | No | Auto-detected from your current tmux pane — omit unless overriding |
--depth | No | Auto-resolved from your parent's depth |
Codex (cx / codex)
You must be running inside a tmux pane. If a human launched you as the orchestrator, they must have started your session inside a tmux window first.
Check ORCA_WORKER_NAME in your environment:
- If set: you are a worker —
--spawned-by "$ORCA_WORKER_NAME"
- If not set: you are the L0 orchestrator —
--spawned-by self
orca spawn "add unit tests" -b cx -d ~/proj \
--orchestrator cx --spawned-by "$ORCA_WORKER_NAME"
orca spawn "add unit tests" -b cx -d ~/proj \
--orchestrator cx --spawned-by self
| Flag | Required? | Notes |
|---|
--orchestrator cx | Yes | |
--spawned-by <name> | Yes | $ORCA_WORKER_NAME if set, or self if L0 |
--pane | No | Auto-detected |
Cursor (cu / cursor)
You must be running inside a tmux pane. If a human launched you as the orchestrator, they must have started your session inside a tmux window first.
Check ORCA_WORKER_NAME in your environment:
- If set: you are a worker —
--spawned-by "$ORCA_WORKER_NAME"
- If not set: you are the L0 orchestrator —
--spawned-by self
orca spawn "refactor auth" -b cu -d ~/proj \
--orchestrator cu --spawned-by "$ORCA_WORKER_NAME"
orca spawn "refactor auth" -b cu -d ~/proj \
--orchestrator cu --spawned-by self
| Flag | Required? | Notes |
|---|
--orchestrator cu | Yes | |
--spawned-by <name> | Yes | $ORCA_WORKER_NAME if set, or self if L0 |
--pane | No | Auto-detected |
Sub-workers (worker spawning further workers)
If you are a worker spawning sub-workers:
- Always pass
--spawned-by <your-worker-name> — the plain name from ORCA_WORKER_NAME or orca list (e.g. fin, mud), NOT the emoji label.
- Only OpenClaw uses
--spawned-by openclaw. If you are a worker, you must use your own worker name.
- Orca fails closed if you omit
--spawned-by or pass the wrong name.
orca spawn "sub-task A" -b cx -d ~/proj --orchestrator cc --spawned-by fin
orca spawn "sub-task B" -b cc -d ~/proj --orchestrator cc --spawned-by fin
Max depth is 3 (ORCA_MAX_DEPTH). Max 10 running workers per orchestrator (ORCA_MAX_WORKERS). At max depth, do the work yourself.
Headless / scripts (not interactive agents)
To use --orchestrator none, set ORCA_ALLOW_SPAWN_WITHOUT_ORCHESTRATOR=1.
CLI reference
orca spawn "fix the login bug" -b cc -d ~/proj --orchestrator openclaw --spawned-by openclaw
orca spawn "add unit tests" -b cx -d ~/proj --base-branch develop --orchestrator cx --spawned-by fin
orca spawn "refactor auth" -b cu -d ~/proj --orchestrator cu --spawned-by ace
orca list
orca status <name>
orca logs <name>
orca steer <name> "also add tests"
orca kill <name>
orca killall --mine
orca killall --force
orca gc --mine
orca gc --force
orca daemon start|stop|status
orca hooks install|uninstall
orca report -w <name> -e done
Backends
| Flag | Agent |
|---|
-b cc | Claude Code |
-b cx | Codex |
-b cu | Cursor Agent |
Cleanup responsibility
- Do NOT kill or gc workers automatically. The human decides when to kill/gc — they may want to inspect logs, review branches, or cherry-pick work first.
- If the human explicitly asks you to clean up, use
orca gc --mine (safe, scoped to your workers only).
Recovering work after orca kill / gc
When a worker is killed or garbage-collected, Orca auto-stashes uncommitted changes before removing the worktree. Stashes attach to the main repo, not the deleted worktree path.
From the project root (-d directory):
git stash list
git stash show -p stash@{n}
git stash pop
- Committed work on a branch is unaffected by stash; detached commits still need branches per normal Git rules.
- Pass
--no-stash to kill, killall, or gc to skip stashing (automation escape hatch).
- Debugging:
$ORCA_HOME/audit.log has KILL, GC, and STASH_PRESERVE entries; events/<worker>.jsonl has lifecycle events; logs/<worker>.log has terminal output; daemon.log has daemon diagnostics.
DO
- Spawn workers for independent tasks that can run in parallel
- After spawning, stop and wait silently -- the daemon notifies you when workers finish
- Use
orca list / orca status only when the user asks what's happening
- Do NOT kill or gc workers yourself — the human decides when to clean up
- Always pass
--orchestrator with the correct value for your agent type
DON'T
- NEVER run
orca kill, orca killall, or orca gc unless the human explicitly asks -- killing workers can destroy in-progress work and kill orchestrator panes
- Don't sleep or poll -- no
sleep, no orca list loops, no periodic checks. Just stop and wait for the daemon notification.
- Don't use tmux commands directly -- always go through
orca
- Don't spawn more than 4-5 workers at once unless explicitly asked
- Don't steer workers with huge messages -- spawn a fresh worker instead
- Don't spawn sub-workers if you're at max depth -- do the work yourself
- Don't stop the daemon (
orca daemon stop) -- other orchestrators share it