Claude Code orchestrator: running many agents from one

The ways Claude Code runs agents at once

Anthropic’s guide to running agents in parallel lists five: subagents, agent view, agent teams, dynamic workflows and Projects. Dynamic workflows are scripts that run many subagents inside one session, so for an orchestrator the choice is among the other four and the plain separate sessions they are built from. What separates them is how long a worker lives and whether you can reach it yourself. As of October 2026:

Subagents suit an orchestrator that only needs answers: research, a review, a search across the codebase. They end when they report, so they cannot carry a task for days.

Agent teams are the closest thing to a built-in orchestrator: one lead, several teammates, a shared task list. You turn them on with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. The limits decide where they fit: one team per session, no teammate can start its own, the lead is fixed for the session’s life, and in-process teammates are not restored when you resume. Anthropic suggests starting with three to five teammates. They are good for an afternoon of parallel work you watch, less so for an orchestrator that runs for a week.

Projects is Anthropic’s own orchestrator, in public beta on Pro and Max. You tell one conversation what needs doing and it starts a thread for each task. Code has to live on GitHub, and a project can’t take in a session you started yourself on your machine. Its threads run in Anthropic’s cloud or on your own computer, and the second only “while that computer is awake with Remote Control turned on.”

Agent view keeps a session alive after you close the terminal, without tmux. A restart of the machine stops it, and a session left idle and unattached for about an hour has its process stopped until you reply. It is a research preview.

The orchestrator you assemble yourself

Separate sessions with one of them in charge is the arrangement that holds up for long-running work. Each worker is a full Claude Code session with its own context and its own model, it outlives any single turn of the orchestrator, you can open any of them yourself, and a stuck orchestrator can be restarted without losing the workers. Every piece is documented:

• A worktree per session, so two agents never edit the same checkout. claude --worktree <name> makes one under .claude/worktrees/ on a new branch, or you use git worktree add yourself.
• tmux, so the session keeps running after your SSH connection drops. tmux is what Anthropic’s own Remote Control docs tell you to use on a remote machine.
• A Remote Control name, so the session appears under that name in the Claude app’s Code list and you can open it from your phone.
• Messages between sessions. Since Claude Code 2.1.224, sessions on one Mac or Linux machine find and message each other with nothing to turn on. A message to an idle session starts a turn there, and a session can be asked to send back one notice when it next goes idle. Messages travel over a local socket, not through Anthropic’s servers.

Starting one worker looks like this:

cd ~/code/app
git worktree add ~/code/app-billing -b billing
tmux new-session -d -s billing -c ~/code/app-billing "claude --remote-control billing"

The first time Remote Control runs on a machine it asks a one-time confirmation, and a folder you have not trusted asks too, so start the first session attached, answer, then detach. After that the orchestrator runs the same lines through its own shell for each task it hands out, then sends the task to billing as a message. What makes this work is the orchestrator’s CLAUDE.md: which repositories it works in, how it names and starts a session, what every first message must carry (the goal, where the work lives, what to report back), and which decisions it brings to you rather than making. A worker does not inherit the orchestrator’s conversation, so whatever it needs to know has to be in that first message or in files it can read.

Remote Control’s server mode is the other way to start workers. claude remote-control --spawn worktree serves up to 32 sessions from one process by default, each new one in its own worktree, and you start them from the phone or claude.ai. It is also how a Projects thread reaches your own computer. Run it inside tmux like the rest, and restart it after a long network outage: server mode exits after about ten minutes without a connection.

Codex in the same arrangement

Codex runs beside them in its own tmux window. It has subagents of its own, on by default in current releases: ask for parallel agents in the prompt and switch between their threads with /agent. For a task that should run to the end without anyone, codex exec is the non-interactive mode, and an orchestrating Claude session can call it like any other command. Claude Code’s messages reach other Claude Code sessions only, so an orchestrator reads a Codex worker’s result from its output or its worktree. Codex’s own phone route goes through a Mac or Windows computer running the ChatGPT desktop app, which can work on a Linux machine over SSH but has to stay awake itself; the Codex remote control guide has the details.

What runs without you, and what should not

Since Claude Code 2.1.283, auto mode is where an interactive session starts: it works without asking while a classifier checks its actions in the background, and the classifier also checks each message one session sends another before it is delivered. A message from another session can’t approve anything on your behalf, and permission prompts still fire. A prompt in a session nobody is watching waits; with Remote Control on, Claude Code can push it to your phone (“Push when actions required” in /config).

Parallel sessions also spend in parallel. Anthropic’s docs say running several at once “multiplies token usage,” and on a subscription every session draws on the same plan’s limits, which Anthropic’s legal page for Claude Code says “assume ordinary, individual usage.” What that allows on a server is its own question, answered in using your Claude or ChatGPT subscription on a server.

What is worth keeping for yourself: a merge into the branch that deploys, anything that spends money or deletes, and the call on whether a task is finished. Written into the orchestrator’s instructions, those become the questions it brings to you, which on a phone is a short list instead of a stream of prompts.

Where the orchestrator should run

Anthropic’s own docs draw the line. Remote Control is a window into a session on your computer, so “your computer has to stay on and the claude process has to keep running.” After the computer sleeps it reconnects, but nothing ran in between. Agent view’s sessions stop at a restart. A Projects thread on your computer pauses while it sleeps. The cloud options keep going after you close the laptop, but they work against a GitHub repository on a machine that does not stay yours: a cloud session’s machine is reclaimed after a period of inactivity, and a Projects thread’s sandbox pauses between turns and can come back as a fresh clone.

A laptop is fine for an afternoon. For an orchestrator that keeps work moving overnight and that you check from your phone, the sessions need a computer that stays on: a desktop that never sleeps, a server, or a cloud computer of your own. Whichever it is holds your code and your sign-ins, and Remote Control needs the full claude auth login (a setup-token login can’t start it), so it should be a machine only you can log in to. Everpod’s developer pod is that machine ready made: a cloud computer that is yours, always on, with Claude Code, Codex or both installed, reached only through your own private network, for $24 a month.

How much machine it takes

We read the memory of three Claude Code sessions doing ordinary development work on one Linux machine with eight cores, on 5 October 2026 (Claude Code 2.1.289): once a minute for 45 minutes, and every two seconds through production builds and a browser test run.

• A session is light. Each Claude Code process held between 330 and 490 MB, whatever it was doing.
• What a session starts is not. A production build of a mid-sized web app peaked at about 1.8 GB across its processes, cold or cached. A headless browser running a test suite against the app peaked at about 1.4 GB, with 0.4 GB for the app’s server and 0.2 GB for the test runner: about 2 GB for the run. The most any one session’s tools held at once was 3 GB.
• The processor mostly waits. A session spends most of its time waiting on the model. The load average’s median was under one, and it peaked near three during the browser test run.

The arithmetic from those figures, not a test of any one size: an orchestrator and five workers take about 3 GB with the system’s own share. On 8 GB, the size of the developer pod, that leaves room for a build and a browser test run at the same time, with little to spare, and not for a third heavy job. The pod has 4 cores where we measured on eight, so heavy jobs running together also take longer there. Your own builds are the number to check: run one under /usr/bin/time -v and read its maximum resident size, which counts the largest single process (ours read 1.57 GB of the 1.8).