I spun up a five-subagent orchestration to refactor an auth module. It cost me $11, took twelve minutes, and produced a worse result than just doing it in one thread. Subagents are overrated for solo builders, and the Twitter demos showing beautiful agent swarms are not telling you the part where it gets expensive and weird.
Don't get me wrong. Subagents are a real feature with real uses. But the default advice — "break everything into specialized agents" — is wrong for the person building one product alone. Most of the time you want a flat, single-threaded agent that just does the work. Let me explain why.
What a subagent actually costs
When you spawn a subagent, you're not just delegating a task. You're spinning up a fresh context that knows nothing about your main thread. So you have to brief it. Every subagent needs the relevant files, the conventions, the goal, re-explained from zero. That briefing is tokens. The subagent's work is tokens. Then it reports back, and synthesizing its report into the main thread is more tokens.
For a parallel task with clean boundaries, that overhead is worth it. For a task where the pieces are tangled — which describes most real coding — you pay the briefing tax over and over, and the subagents keep stepping on each other because none of them can see the whole picture.
The single-thread version just... has the context already. It read the files once. It remembers what it did three steps ago. No briefing, no synthesis, no coordination overhead. Often it's both cheaper and better.
The context fragmentation problem
Here's the subtle one. The whole reason agents are good at coding is shared context — the model holds the problem, the files, and its own prior decisions in one place and reasons over all of it. Subagents shatter that. Each one sees a slice.
So subagent A fixes the error handling its way. Subagent B, briefed separately, fixes the validation a different way. Neither knows what the other did. You, in the main thread, now have to reconcile two locally-reasonable changes that don't fit together. I've spent more time reconciling subagent output than the subagents saved. That's the trap.
For a solo builder, your edge is that you hold the whole picture in your head and the agent holds it in context. Fragmenting that to look like a team is cosplaying as an org you don't have.
When subagents genuinely pay off
I'm not saying never. Here's where I actually reach for them:
- Truly parallel, independent work. "Run the test suite while you also lint the codebase." No shared state, no reconciliation. Clean fan-out.
- Context isolation on purpose. When a subtask would flood my main context with junk I don't want polluting the main thread — like reading 40 files to answer one question. The subagent reads the 40, returns the one answer, my main context stays clean. That's a great use.
- Bounded research. "Go figure out how this library's auth works and report back." The exploration is messy; I only want the conclusion.
Notice the pattern: subagents earn their keep when the subtask is independent and summarizable. When the value is in keeping mess out of the main thread, not in pretending to be a team.
The orchestration fantasy
There's a genre of content that sells the multi-agent dream — a planner agent, a coder agent, a reviewer agent, a tester agent, all coordinating like a tiny company. It looks incredible in a diagram. For a solo builder it's mostly a way to turn one $0.50 task into a $6 one.
The planner re-explains the task to the coder. The coder produces work. The reviewer, with its own fresh context, re-reads everything to review it. The tester re-reads it again. Every handoff re-processes the same code. You've recreated the inefficiency of a big team — all the communication overhead — without the benefit, because it's still just you and the model.
A single capable agent in one thread plans, codes, and self-checks while holding everything in context. You read the diff at the end. That's your reviewer. You're the org chart.
My rule
Default to flat. One thread, one agent, full context. Reach for a subagent only when I can answer yes to: is this subtask independent, and do I only want the summary back?
# The question I ask before spawning:
# - Independent of the main work? (no shared state to reconcile)
# - Summarizable? (I want a conclusion, not raw output)
# Both yes -> subagent. Otherwise -> keep it flat.
Everything else stays in the main thread, where the context is whole and the bill is small.
The agent swarm looks like the future. For one person shipping one product, it's usually a costume. Take it off and just do the work in one thread. Your token budget will thank you, and so will the code.