Multi-Agent vs Single Session: How a Solo Dev Can Benchmark It

Whether a multi-agent setup beats a single session is something you can only answer with your own task and your own codebase, not someone else's video. This post lays out how a solo developer can run that experiment: what to prepare, in what order, what to measure, and where it goes wrong. Full disclosure up front: I have not finished this comparison myself yet. So this is "here is how you could try it," not "here is what I found."

Why I started wondering

A Korean YouTube video titled roughly "Don't use multi-agent.. (real test results)" from the channel 챗대리의 AI연구소 (19K subscribers) has been making the rounds with 14K views. The title sounds like a verdict. It made me ask the opposite question instead. "What would happen on my task?"

Anyone deciding whether to build an agent team wants the same three things. How much time does it save or cost. How many more tokens, which means money, does it burn. Is the output actually better. You can measure all three yourself. The setup is smaller than it sounds.

The three setups

• Single session. One Claude Code window gets the whole task. The most common way to work, and the baseline.
• 5-agent team. One session acts as lead and five teammates with split roles each run in their own session. The Claude Code docs call this "agent teams."
• Builder plus reviewer (2 sessions). One session implements, one session only reviews. Closer to pair programming than to a team.

The real difference between them is how many pieces you split the context into. A single session carries one long memory to the end. A team splits memory across several sessions and pays for keeping them aligned. The pair keeps one memory and adds a second pair of eyes.

What the official docs already tell you

It helps to know the cost structure before you start, so your expectations are calibrated.

The agent teams page in the Claude Code docs says teams use significantly more tokens than a single session because of coordination overhead, and usage scales with the number of active teammates. It recommends using Sonnet for teammates, keeping teams small, and shutting teammates down as soon as their work is done, because each one keeps consuming tokens until it exits.

Subagents, the helpers you spin up inside one session, cost less than a team because their results come back summarized into the main context. They still spend their own tokens while running.

The docs' conclusion is plain. For research, review, and new features with many branches, the extra tokens are usually worth it. For routine work, a single session is cheaper. So the official position is not "multi-agent good" or "multi-agent bad" but it depends on the task, which is exactly why measuring your own task is worth doing.

What you need

• Claude Code in a terminal. Enable the team feature by following the agent teams page.
• Three copies of the same task. Make three git branches from the same commit. If you run the setups one after another on one branch, the second one starts with the first one's work and the comparison is ruined.
• One task spec. A prompt you paste into all three setups without changing a character.
• A scorecard. The tests that must pass, or a checklist like "the feature passes if it behaves this way." Write it before the experiment. Written afterward, it bends toward whatever you saw.
• A stopwatch and a notes file. Nothing fancy.

Pick a task that takes about an hour and touches three or four files. Too small and setting up the team takes longer than the task, so the team loses by default. Too big and three runs eat more than a day. Something like "add a dark-mode toggle to settings, persist it, and make two tests pass."

The order

Running the three-setup comparison

1. Freeze task and scorecardOne prompt, one list of pass criteria, written first
2. Make three branchessingle / team5 / pair from the same commit
3. Run the single sessionRecord start and end time, tokens, interventions
4. Run the 5-agent teamClock starts at team setup. Teammates on Sonnet
5. Run builder + reviewerOne implementing session, one reviewing. Count round trips
6. Score with the same cardTests passed, lines you fixed by hand, retries

The important part is that steps three through five happen on the same day, by the same person. Change the day and both the model's conditions and your own attention change with it.

Four numbers per setup are enough.

1. Wall-clock time. From pasting the prompt to the moment you judge it done. For the team, include setup time, because that is time you actually waited.
2. Tokens. Inside Claude Code, open /usage; the Session block at the top shows the current session's token usage (see the costs page). For a team, check each teammate's window and add them up.
3. Human interventions. How many times you stepped in to redirect. This is really "your time."
4. Scorecard result. Tests passed, lines you had to fix by hand.

How to set up the builder-plus-reviewer pair

This is the simplest of the three and the most realistic for a solo developer, so it gets its own section.

Open two windows. The first gets the task prompt as is. The second gets a pinned role: "You write no code. Read the diff the first session produces and list only problems, judged against the scorecard." Each time the first window finishes a chunk, show the diff to the second and feed its notes back to the first. The number of round trips is the key figure for this setup.

You can do roughly the same with one window and a subagent. Define a "reviewer" subagent as the sub-agents page describes and call it after each implementation step. That version costs fewer tokens.

The three setups side by side

The numbers are blank on purpose. Your experiment fills them in.

Traps that ruin the comparison

• The first run always loses. Whatever you run first, your hands are clumsiest. Run the set again in a different order (team, pair, single) to cancel the order effect.
• Never conclude from one run. The same prompt gives different results each time. Two runs per setup is the minimum before you trust a lucky one.
• Don't generalize from one task. As the docs say, branching tasks and narrow tasks give different answers. Try one of each and your conclusion becomes far more useful.
• Let the scorecard decide "done," not the agent. If you stop the clock when an agent says "finished," the team will always look fast.
• Don't mix models. Opus for the single session and Sonnet for teammates means you no longer know whether you compared setups or models. Keep the lead or builder session on the same model across all three. Teammates can be on Sonnet as the docs recommend, but write that in the results table.

This is as far as I know

I haven't run it yet, so I don't know the result. It may come out like the video's title, or the team may earn its keep only on certain tasks. One thought did settle while writing this. A solo developer uses a "team" to save their own time. If setting up and babysitting the team takes longer than the time it saves, that is not a team, it is a hobby. Half a day is enough to find out with numbers, so I'll run it and write again.

Which setup are you working in these days?

Sources

• Claude Code docs — Orchestrate teams of Claude Code sessions: https://code.claude.com/docs/en/agent-teams
• Claude Code docs — Create custom subagents: https://code.claude.com/docs/en/sub-agents
• Claude Code docs — Manage costs effectively: https://code.claude.com/docs/en/costs
• Reference video (Korean) — "Don't use multi-agent.. (real test results)," 챗대리의 AI연구소: https://youtu.be/cIGRF-acSzs