Multi-agent Claude Code orchestration is mostly bookkeeping, and the bookkeeping is the tradeoff

THE THESIS

The expensive part of multi-agent is not tokens, it is state

Public writing on multi-agent Claude Code orchestration converges on three points: it costs more tokens, it can race on file writes, and it works best for parallel exploration. All true. All of it skips the machinery you actually have to build, or buy, or absorb, the moment there is more than one agent in your loop.

The machinery is per-session state. Every session has its own context window, its own MCP servers, its own pending-message queue, its own interrupt flag, its own generation counter for timeouts. A single-agent setup is a single object. A multi-agent setup is a dictionary of objects keyed by session, plus the routing code to make sure inbound messages, interrupts, and timeouts land on the right key. Get the routing wrong and you get cross-session message bleed, the wrong agent getting cancelled, or runaway turns that nobody is watching.

The numbers below are not hypothetical. They come from Desktop/Sources/Chat/ACPBridge.swift inside Fazm, a 1,984-line file with 177 references to the word "session", and from acp-bridge/src/index.ts, the Node-side counterpart with another 498. That ratio is the tradeoff in a single line: most of the code is bookkeeping, not work.

TRADEOFF 1

The ~4 second session/new latency, and what amortizing it costs you

Every Claude Code agent you orchestrate begins with a session/new round-trip. That call loads the system prompt, registers the MCP servers configured for the working directory, and hands back a session ID. On a warm machine, in our measurements, this is roughly 4 seconds per session. Cold, after a process launch, it is longer. If you spawn three agents on demand, that is 12 seconds of dead time before any of them produces a token, unless you parallelize the calls, which then briefly tripled the load on the bridge.

The fix is pre-warming. The literal comment in our bridge: "saves ~4s on the first query by doing session/new ahead of time. Pass multiple models to pre-warm sessions for both Opus and Sonnet in parallel." The pattern is to call warmupSession on app launch with one config per model you expect to route through. The first real user query lands on a session that already exists, and streaming starts in milliseconds.

The cost is honest. Each pre-warmed session pins a process slot, an allocated context window, and any MCP servers it registered, whether a user ever sends a message to it or not. For a desktop app with two warmed sessions, that is acceptable. For a server-side orchestrator spinning up ten agents per request, it is not, and you are back to paying the 4 seconds per call on the cold path.

TRADEOFF 2

Per-session queues, interrupts, and generations: the four dictionaries

Single-agent code is short. Multi-agent code is mostly routing. The minimum bookkeeping for safe parallel sessions is four dictionaries keyed by sessionKey, each of which exists for a reason that will only become obvious the first time you try to omit it.

• sessionContinuations holds the awaiter for the next inbound message on a given session, so two sessions waiting at once do not collide.
• sessionPendingMessages is the queue for messages that arrived before any awaiter was ready. Without it you drop the first chunk of a streamed response.
• sessionMessageGenerations is a per-session monotonic counter that timeouts use to confirm they are cancelling the right turn.
• sessionInterrupted is a per-session boolean so cancelling agent A does not cancel agent B.

// One agent, one session. The whole bookkeeping fits in a few lines.
let session = await provider.request("session/new", { cwd, mcpServers });
const result = await session.prompt(userMessage);   // wait for it
console.log(result);                                  // done

// Cancel? One flag is enough.
session.interrupt();

The right-hand side is the floor, not a complete implementation. Real bridges add reconnection on session loss, phantom-session detection (sessions the SDK never wrote a turn for and that session/resume will reject), per-session token accounting, and a lifecycle hook for when a session is invalidated by a working-directory change. None of that work is glamorous and all of it is load-bearing.

THE LIFECYCLE

Two agents, one bridge, one orchestrator

The shape of a healthy two-agent run on the same bridge process. Note that the interrupt to agent A is scoped, agent B keeps streaming.

TRADEOFF 3

Token spend: the multiplier that everyone names and few quantify

The token math is the well-trodden tradeoff and the right baseline for budgeting is 2x to 5x the single-session spend, not 1.x. Each agent loads its own system prompt and tool catalog. There is no shared cache across sessions for that prefix unless you specifically design for it, which itself is more orchestration code. Each agent then takes its own turns, and the orchestrator typically re-summarizes or re-routes between them, paying again on its own context.

Anthropic's own writeup on building a C compiler with parallel Claudes is the honest reference: parallel agents shipped the compiler faster in wall-clock time but burned dramatically more compute than a single agent doing the same work serially would have. That is the deal. Multi-agent buys latency, not efficiency.

TRADEOFF 4

MCP server proliferation: the cost that does not show up in your token bill

Every Claude Code session registers its own MCP servers based on the working directory it was created with. Three concurrent agents on the same machine, each with four MCP servers (Playwright, filesystem, search, a database client), gives you twelve child processes plus the three agent processes plus your orchestrator. Each holds its own stdin/stdout pipes, its own state, its own file descriptors. None of that is visible in your API bill.

The mitigation is to share MCP servers across sessions where the protocol allows it (stdio servers do not multiplex by design, http ones can). The cost of the mitigation is real: shared servers reduce the per-session isolation that was a reason to run multiple agents in the first place. If agent A leaves the Playwright tab on a logged-in dashboard, agent B inherits it. Sometimes that is fine. Sometimes it is the bug.

TRADEOFF 5

File-system race conditions: a solved problem with a discipline tax

The file-write race is real and it is the one tradeoff with a clean, known answer: one git worktree per agent. Each agent edits inside its own checkout, the merge happens explicitly at the end. You trade a class of correctness bugs for disk space and the discipline of merging. Skip the worktree pattern, let two agents touch the same file, and eventually you ship a bad merge that compiled, passed tests, and silently dropped one agent's intent.

This is the part of multi-agent where the tooling is mature. It is also the part where most teams underspend on tooling because worktrees feel like a developer-environment problem rather than an orchestration problem. They are an orchestration problem.

THE COUNTERARGUMENT

When the bookkeeping is worth it

The pages that currently rank for this topic and Anthropic's own docs all converge on the same three winning shapes, and our experience matches. They are worth naming clearly.

1. Parallel exploration. Several agents investigate different files, modules, or hypotheses in the same codebase, then report back. The orchestrator compares and synthesises. Token spend is bounded by exploration time and wall-clock is what you actually want to optimize.
2. Independent feature work. Each agent owns a separate module on a separate worktree. No file collisions because there are no shared files. The 2x to 5x token spend buys near-linear wall-clock speedup for greenfield work.
3. Competing-hypothesis debugging. Each agent tests one theory about a bug in parallel. First one to confirm or rule out wins. Token spend is the price of not waiting for serial elimination, which on a hard bug can be hours.

What these have in common: the work is independent enough that no two agents will fight, the value of finishing sooner is large enough that paying 2x to 5x in compute is acceptable, and there is a clean point where the orchestrator collects results. If any of those is missing, you are paying for the bookkeeping without getting the speedup.

THE RUBRIC

A short test before you reach for orchestration

Before you write a single dictionary keyed by sessionKey, run the task you have in mind through these four questions. If you cannot say yes to all four, use one session.