One Claude Code session becomes the conductor of the others. You talk only to it; it opens, briefs, reads and messages the rest of your tmux sessions, keeps a board of what is open, and checks the machine's memory before it starts anything new.
Past three or four parallel sessions, the cost is not the work, it is you: which window was waiting for an answer, which one finished an hour ago, which one is about to eat the last gigabyte of RAM. The orchestrator moves that bookkeeping out of your head.
The conductor registers every live session by name, groups them by client or area, and keeps a fixed tmux layout so you always know where to look.
Mechanical jobs go to a cheap model, delicate ones to the strongest, sensitive data to an EU or on-prem provider. Every brief is a file with a goal, sources and limits.
Before every open, and on every sweep, it checks available memory against a floor relative to the machine. On a small host that means fewer sessions, never a frozen box.
Window 1 is the conductor. Window 2 queues the next sessions that will need you. Everything else lives in group windows, at most four panes each.
-2) sit behind these two.main. That name is reserved by the messaging tool, so replies would never reach it.# swap a waiting session into a direct slot tmux swap-pane -s <new> -t <old> # back to its group window tmux join-pane -d -s <pane> -t <group-window> tmux select-layout even-horizontal tmux resize-pane -t <conductor> -x 30%
The launcher defaults to the strongest model, which is exactly why it gets picked without thinking. Decide the row first, then pass the flag. Every brief is a file, never inline text.
| Work | Provider |
|---|---|
| Mechanical, read-only, batch | A cheap model alias through your gateway, or your own GPU when it is on |
| Ordinary: fixes, content, known debugging | A mid-priced model; the mid tier of Claude when it needs Claude tooling |
| The user's own data: mail, chats, fiscal | An EU-hosted provider or on-prem GPU, never pay-per-use outside the EU |
| Delicate: client production, third-party deliverables, architecture | The strongest model |
| Sensitive client data | On-prem GPU or an EU-hosted provider |
A brief always says: who opened the session, the goal, the sources to read first, what not to do, and "report to the conductor in one line when done or blocked". It also names the working mode, meaning the skill to invoke after project and target.
# one session per topic, grouped, with a target and a brief file
session new bug-triage --group client-a \
--project client-a-site --target "fix the checkout 500" \
-m sonnet --brief storage/briefs/bug-triage.md
You follow open problems on a board pane, not in scrollback. Every report from a session goes to the board first; the chat gets one or two lines pointing at the item. The sweep keeps both honest without you asking.
/bye, then /exit on the next sweep: /bye saves but leaves the process running.free -h, always. Below the floor, close before opening.# the board, items go by number 21 [ ] approve supplier reply -> %billing (w1) 22 [ ] staging or production? -> %site-dev (w2) 23 [x] landing page published in direct: invoice review in %billing
On a small machine the rule means fewer sessions at once, and the conductor closes before it opens instead of piling up. Look beyond the tmux panes too: leftover web-terminal processes can hold gigabytes for weeks.
| Total RAM | Floor | Share kept free |
|---|---|---|
| 4 GB | 2 GB | 50% |
| 8 GB | 2 GB | 25% |
| 16 GB | 2.4 GB | 15% |
| 32 GB | 4.8 GB | 15% |
# before every open
free -h
pgrep -c claude
Delegation is only safe with hard edges. These are the ones the skill spells out.
/send, /solo or "deploy" in your own message, for a named item. "Answer each of them" is not a trigger.Three ways, all the same skill. It needs Claude Code sessions running inside tmux.
# 1. as a plugin /plugin marketplace add giobi/claude-skills /plugin install orchestrator # 2. from a terminal, straight into your skills folder curl -sL https://brainprotocol.it/skills/orchestrator/orchestrator.zip -o orchestrator.zip unzip -o orchestrator.zip -d .claude/skills/ # 3. let your agent do it Install the orchestrator skill: read https://brainprotocol.it/skills/orchestrator/install and follow the instructions there.
Make one session the conductor and talk only to it. It opens, briefs, reads and messages the others in tmux, keeps a board of what is open, and tells you which session to move to when a topic needs a long dialogue.
Plan on 0.1 to 0.6 GB per Claude process. The skill keeps available memory above the larger of 2 GB and 15% of total RAM and checks it before every session it opens.
No. Sending, autonomous runs and deploys need the literal word from you, typed in the conductor for a named item. A relayed paraphrase does not count.
The skill is plain markdown, so any agent can read it. The tmux layout and session commands assume Claude Code sessions in tmux.