Multiple Sessions or Multi-Agent?
I ran 27 agents to answer that

TL;DRThe conclusions, up front

1. Parallelism doesn't produce quality; contracts do. Same setup, 5 agents writing 5 modules in parallel: the group with a contract produced 6 files with zero interface errors and assembled on the first try; in the group without one, 2 of the 5 assembly attempts went straight to a blank screen, throwing a module-load-time SyntaxError — not the kind of runtime bug you can debug your way out of.
2. Without a contract, agents burn enormous compute guessing at their teammates' interfaces. The slowest agent in the no-contract group ran for 831 seconds and 104K tokens — it built itself a set of fake teammate modules and 18 assertions just to verify its own guesses. The fastest agent in the same group took only 169 seconds.
3. Naming disagreements aren't evenly distributed; they cluster on the one interface with the most complex semantics. Across 5 developers who never talked to each other, named imports hit 24/26 (92%) — but the core physics stepping function alone got three different names from three people (stepPlayer / updatePhysics / stepPhysics), and that happens to be the single most critical call in the whole thing.
4. A subagent doesn't get your conversation history, user memory, or preference settings. Confirmed by probe: all it gets is the system prompt, the task message, CLAUDE.md, git status, environment info, and the tool/skill list. All that background you assume it "knows" — it doesn't.
5. A subagent can't ask you a question. The probe showed no AskUserQuestion and no SendUserMessage in its tool list. It can push files and notifications to you one-way, but it can't ask "does this feel right?" and wait for your answer. For game development that's a dealbreaker.
6. worktree isolation doesn't eliminate conflicts, it just defers them. Two worktrees each cleanly edited the same line with zero interference at runtime — and the instant you merge, CONFLICT (content).
7. The payoff from "parallelism" is hard-capped by the host's concurrency. This cloud sandbox has only 2 cores, and 8 "parallel" agents actually ran as batches of 2, four batches deep. The fan-out you pictured when writing the workflow is a queue here.

Part 1The mechanics: there are four, not two

Framing it as "multiple sessions vs multi-agent" flattens the options. Dig through the official docs and you'll find four ways to run things in parallel today, and they differ along three dimensions: who coordinates, whether the workers can talk to each other, and how files are isolated.

Part 2Probing it for real: where exactly is the isolation boundary

Plenty has been written about subagents having "their own context," but nobody spells out how independent "independent" really is. I spun up 6 sets of probe agents to just ask and just try. Here's what came back. Everything tagged as measured came out of this run

Probe 1 · Parallel subagents share the filesystem, and see each other live measured

Two agents started at the same time, each wrote a file, each slept 30 seconds and then listed the directory. Both saw the other's file, and the time windows confirm the overlap (A: 1785147960382→1785148004867, B: 1785147960821→1785148006985).

Probe 2 · What a subagent inherits, and what it doesn't measured

I asked an agent to report, without using a single tool, exactly what context it received at startup.

The probe agent's own words are worth copying down:

The only thing it can do is reason backwards from the environment: it saw the working directory was called probe-repo, saw the installed skills leaned toward iOS game development and Chinese HTML documents, and guessed "this account usually cares about those areas." That's a guess, not knowledge.

Probe 3 · A subagent cannot ask you anything measured

I had an agent go through its own tool list line by line:

Probe 4 · worktree isolation: flawless at runtime, explosive at merge time measured

Two agents each created a worktree, each changed the same line of config.js — SPEED = 100 — to a different value and committed, with a 20-second sleep in between to force overlap.

Runtime behavior was flawless: the main repo's working tree stayed clean throughout (SPEED still 100), the two branches advanced independently from the same base, and there was no index.lock contention and no git error at all. A even watched B's worktree appear out of nowhere during its own sleep, with zero effect.

Then I merged the two branches:

$ git merge feat-a
Fast-forward

$ git merge feat-b
Auto-merging config.js
CONFLICT (content): Merge conflict in config.js
Automatic merge failed; fix conflicts and then commit the result.

Probe 5 · Real concurrency: the parallelism you were promised is actually a queue measured

I launched 8 agents, each doing exactly one thing: stamp the time, sleep 15 seconds, stamp the time again. The timestamps came back in a clean pattern of four batches, two at a time:

The host has nproc = 2, and the measured maximum concurrency is exactly 2. The 8 agents took 109 seconds to finish; with real parallelism it should have been about 20 seconds. On top of the 15-second sleep, each agent also carries roughly 5 seconds of startup and model overhead.

Part 3Three-Arm Controlled Experiment

The probes answered "what the mechanism is." This section answers "how much difference it makes."

The design

One SPEC.md (a 640×360 canvas platformer, hard-split into seven files: physics / input / level / render / hud / main / index.html), built once under each of three orchestration modes:

The numbers

How Arm C actually broke

The 5 developers each wrote their own main.js. Once I had all 5 modules, I assembled the project once with each of them and ran it in headless Chromium:

Naming convergence: higher than I expected, but wrong in exactly the worst place

Cross-checking the five developers' named imports against what the real authors exported:

Named import hit rate: 24 / 26 = 92%

Hits (everyone converged on their own):
  input.js  : createInput      ✓ all three guessed right
  level.js  : getPlatforms     ✓
  render.js : render           ✓
  hud.js    : drawHUD          ✓

Misses (all on one and the same interface):
  physics.js actually exports : stepPlayer / stepBody
  dev2 guessed                : updatePhysics   ✗
  dev4 guessed                : stepPhysics     ✗

What the three builds look like

I screenshotted all three PASS builds (headless Chromium, 2.5 seconds in, holding Right + Space):

Arm A · 1,057 linesstarfield, distant hills, rounded platforms, a character with eyes, life pips, control hints

Arm B · 657 linesstrictly to the contract, not one pixel of improvisation

Arm C · 1,628 linesthe richest visuals and the most bloated; 2 of the 5 assemblies give a blank screen

Why this happens

Read through what the 5 agents in Arm C say about their own work and the mechanism gets very clear. With no contract, a rational developer does three things, every one of which burns money:

1. Abandon named imports for namespace imports plus a candidate-name table. dev3's own words: "With named imports, if a teammate's name is off by a single letter, the browser gives you a link-time SyntaxError and a blank screen." So it prepared a list of candidate names for every symbol and tried them one by one.
2. Hedge shared state with property aliases. Several agents used Object.defineProperty to point state.vy and state.player.vy at the same storage, and threw in w↔width and onGround↔grounded while they were at it — purely because they had no idea which name a teammate would use.
3. Build a set of fake teammates to verify the guesses. dev3 created a .selftest inside its own directory, wrote three sets of fake modules in completely different styles (one deliberately contradicting its own guesses), and ran 18 assertions. That step alone is why it was 4× slower than the rest of its arm.

It even left this line in its report, which says it all:

— Defensive programming can block naming divergence; it can't block semantic divergence. And a contract that takes 250 seconds to write makes all three of these unnecessary.

Part 4Seven Conclusions

1 · A contract is a precondition for parallelism, not an optional extra

Arm B spent 256.6 seconds writing the contract and got back zero interface errors, an assembly that worked on the first try, and the smallest codebase. Arm C skipped those 256.6 seconds and paid for it with double the total work time, 40% of its assembly attempts ending in a blank screen, and two modules implementing the same function twice. A contract isn't overhead, it's leverage.

2 · Parallelism doesn't reduce total work, it only compresses the critical path

Arm A serial: 885.6s. Arm B contract-first parallel: 849.5s of total work — almost identical. Parallelism didn't make the work smaller, it just squeezed out a 512.5-second critical path (42% faster than serial). So: if you don't care about wall-clock time, parallelism buys you nothing and burns 3x the tokens.

3 · The ceiling on parallel gains is set by your machine, not by your script

This machine has 2 cores, and the measured concurrency ceiling was exactly 2. Arm B's ideal critical path was 512.5s, but the measured wall clock was 1012.7s — the effective parallelism was cut by more than half. Check nproc before you write the workflow.

4 · subagents are "dumb": no background, and they can't ask

They don't get the conversation history, the memory, or your preferences, and they can't ask you a question. Put those two together and it means: any decision that comes down to "you decide" cannot be handed off to a subagent. They're only good for work with a clear goal, objective criteria, and a conclusion at the end.

5 · worktrees govern "writing at the same time", not "writing different things"

Two worktrees wrote concurrently with zero conflicts, and the merge CONFLICTed immediately. An isolation boundary solves physical conflicts; semantic conflicts can only be settled by a contract or by a human.

6 · "It's the same model, it should line up" is a dangerous intuition

A 92% naming convergence rate is exactly what creates that illusion. But the remaining 8% lands precisely on the most critical interfaces, and the failure mode is a hard failure (blank screen), not a soft degradation.

7 · Contracts suppress flair — don't use them to manage creative work

Arm B's output was the most orderly and also the plainest. For infrastructure that's a good thing; for the parts that need flair — game feel, level pacing, art style — you shouldn't force them through the same parallel pipeline.

Part 5The decision SOP

Decision tree

Pre-parallel checklist

Follow this one as written. The first four are hard gates — miss any one of them and don't go parallel.

Hard gates

• The contract is written and on disk. Precise down to: every field name + type + default value + who is allowed to write it for shared state; every module's exported function names + parameter order + parameter types + return values; and call order. A vague contract is no contract.
• File ownership is settled. One file, one owner. Whatever you can't divide cleanly stays in the serial path.
• The unclaimed work has been named. In Arm C, none of the five wrote index.html — anything that sits in nobody's remit is something nobody does. List it out and assign it to a person.
• Verification already runs automatically. Parallel output has to have an objective test (compiles / tests pass / starts with no errors). Without an automatic check you will drown in manual review.

When writing prompts

• Manually restate the key constraints from the main session into every agent's prompt — they can't see your conversation.
• Any rule you can pin down goes into CLAUDE.md: it's the only thing that reaches every subagent's context automatically.
• Spell out what an agent is not responsible for, not just what it is. drawGameOver got written twice, once in each module, precisely because nobody was told it wasn't theirs.
• Forbid agents from reading into anyone else's directory — otherwise what you're measuring isn't parallelism, it's serial work in a parallel costume.

Scale and cost

• Check nproc first. Your concurrency ceiling is roughly the cores the machine can give you, not the number written in your script.
• 3–5 workers is the sweet spot (the official recommendation matches what I saw here); past 8, coordination overhead starts eating the gains from parallelism.
• Budget: parallel costs about 3× the tokens (A→B was 3.2× here). The published official numbers are ~15× for multi-agent versus chat, ~4× for a single agent.
• If what you're trying to save is your own time rather than wall-clock time, don't go parallel.

When merging

• Before merging a worktree branch, run the automated verification once; don't wait until the conflicts are resolved to discover the interfaces don't line up.
• When interfaces disagree, let the contract decide whether the caller or the callee changes — not "whoever merges first wins".
• Re-run the full verification after merging — two modules that are each correct on their own aren't necessarily correct together.

How to split sessions

Part 6iOS / SpriteKit deep dive

On Xcode projects, everything above gets one extra amplifier: project.pbxproj.

Why iOS projects are especially hostile to parallelism

.pbxproj is a single monolithic plist, and every time you add, remove, or move a file, both the file references and the group references get updated. Two sessions each adding one Swift file means two writes to adjacent regions of the same file — git's auto-merge does a poor job on this kind of structure. And that is exactly the operation parallel development performs most often.

Three tiers of mitigation, ordered by effort

Tier 1 · Don't touch the project structure (doable today)

• Keep exactly one coding session. Lowest cost, highest payoff of anything here. Every other session only does work that never touches .pbxproj: assets, research, copy, balance tables.
• If you really must write code in parallel, agree that nobody adds a new file this round — only edit the contents of existing files. Editing contents doesn't touch .pbxproj, and conflict risk drops by an order of magnitude.
• Funnel new files through one person, add them in a batch, then hand them out.

Tier 2 · Use Xcode 16+ filesystem-synchronized groups

• Right-click a group → Convert to Folder, swapping hand-maintained groups for folders that stay in sync with the filesystem. From then on, adding a file no longer writes to .pbxproj.
• Align your local directory structure with your Xcode group structure before converting, or you'll get one enormous diff in a single shot.

Tier 3 · Generate the project file / modularize

• XcodeGen or Tuist: describe the project in a YAML/Swift DSL, match source files with a Sources/**/*.swift glob, and .pbxproj becomes a build artifact that never enters version control — the conflicts disappear at the root.
• Split by domain into local Swift Packages: Gameplay / Rendering / Audio / UI, one package each, one owner each. The cost is slower compilation and indexing.

Suggested session layout for a SpriteKit game

Part 7What I Didn't Verify

To give you the full picture, here's what this round didn't test or didn't test cleanly. Don't extrapolate these conclusions:

• Real multiple sessions were never measured directly. I couldn't open a second Cowork session in this environment. Arm C simulated it with "separate directories + no cross-reading + no shared contract," which reproduces the information isolation of multiple sessions but not the across-days, human-in-the-loop, context-repriming dimensions.
• Arm C's isolation is self-reported. All 5 agents claimed they didn't read each other's directories, and I didn't go through the transcripts line by line to falsify that.
• The wall-clock numbers are polluted by the concurrency cap. This machine has 2 cores, and the three arms were also competing with each other. The "ideal critical path" in the table is a modeled value recomputed from each agent's measured duration, not measured wall clock.
• n = 1. Each arm ran once. No repeats, no variance estimate. That 831-second outlier may not be reproducible.
• The task was on the small side. A 600–1600 line mini-game is an order of magnitude away from a real iOS game project. The value of a contract probably rises with project size, but I didn't test that here.
• Context decay over long sessions went untested. One of the biggest payoffs of multiple sessions — breaking past the total context ceiling — got no direct measurement at all this round; I can only cite outside research (see sources).
• Agent teams / background agents: docs only, no actual runs. They're Claude Code CLI capabilities and weren't available in this environment.

AppendixSources

Experiment artifacts (generated in this run)

• Probe workflow: 14 agents, 419,907 tokens, 369.7s
• Three-arm workflow: 13 agents, 755,388 tokens, 2266.2s
• Verification tooling: Playwright + Chromium headless, 7 runs; static cross-analysis of ES module imports and exports

Official documentation

• Create custom subagents — the context inheritance checklist, the three limits on concurrency / total count / nesting, the fork mechanism, the resume mechanism
• Run agents in parallel — the official comparison table of the four parallelization modes
• Orchestrate agent teams — teammates talk to each other, a shared task list, no automatic file isolation, the 3–5 recommendation
• Manage agents with agent view — independent background sessions, automatic worktree isolation, linear quota consumption
• Run parallel sessions with worktrees — --worktree, .worktreeinclude, the desktop app assigning every session its own worktree automatically
• How we built our multi-agent research system — multi-agent beats single agent by +90.2%; roughly 15× / 4× the tokens; token usage explains 80% of the performance variance; and it explicitly notes that most coding tasks are less parallelizable than research tasks

Practice and research

• The Code Agent Orchestra — the 3–5 sweet spot, one owner per file, "the bottleneck has shifted from generation to verification"
• From Conductor to Orchestrator — the Ralph loop, approve the plan first, one reviewer for every 3–4 builders
• Context Rot — all 18 models degrade as length grows; accuracy on mid-context information drops 30%+; agents start degrading past 35 minutes, and doubling the duration quadruples the failure rate
• Strategies to avoid merge conflicts in Xcode Projects — synchronized groups, XcodeGen/Tuist, splitting the project into per-module packages
• Run Multiple Claude Code Sessions in Parallel With Git Worktrees — community practice for parallel worktrees