Yeda AI Tips · #213

Español

Parallel Agents Cost Seven Times More

Running several agents at once feels like the efficient choice: more work happening, less waiting. The token bill disagrees, and the reason is worth understanding precisely — because the widely-repeated version of this warning points at the wrong feature.

The number, and its condition

The documented figure is that agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode. The stated reason is structural: each teammate maintains its own context window and runs as a separate instance.

Both halves of that sentence matter. The multiplier is attached to a condition — teammates running in plan mode — rather than being a flat tax on any parallel work. And the mechanism explains the shape of the cost: it scales with the number of active teammates, roughly proportionally, because each one is a whole separate session paying its own context costs.

A teammate isn't a lightweight worker. It loads the rules file, MCP servers, and skills like any regular session, then holds its own conversation. Five teammates is closer to five people each running their own session than to one session doing five things.

The correction: teams are not subagents

Here is where the advice usually goes wrong. That 7x figure gets repeated as a warning about delegation in general, or specifically about subagents. It isn't. Agent teams and subagents are different features with opposite cost profiles.

The same documentation that reports the 7x multiplier for teams recommends subagents as a way to reduce token usage. Delegating verbose operations — running tests, fetching docs, processing log files — to a subagent keeps the noisy output in the subagent's context, and only a summary returns to your main conversation. The comparison table makes the split explicit: subagents are the lower-cost option because results are summarised back; agent teams are higher because each teammate is a separate instance.

So the two shapes are:

Being told "parallel agents are expensive" and concluding you should stop delegating research is exactly backwards. Delegating the reading is the cheap move.

When a team actually earns it

Teams are worth the multiplier when the work genuinely parallelises and the agents benefit from challenging each other. The documented strong cases are research and review across independent aspects, new modules where each teammate owns a separate piece, debugging with competing hypotheses, and cross-layer changes.

The competing-hypotheses case is the most interesting, because the value isn't speed. A single agent investigating a bug tends to find one plausible explanation and stop — classic anchoring. Several investigators actively trying to disprove each other produce a surviving theory that's much more likely to be the real cause. You're buying independence of judgement, not throughput.

Teams are a poor fit for sequential work, edits to the same file, or anything with heavy dependencies between the pieces. There, coordination overhead eats the parallelism and you've paid the multiplier for nothing.

Keeping the cost down when you do use one

One more thing that spawns teams by accident

Agent teams are experimental and off by default, enabled with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. But once enabled, they change ordinary delegation: a subagent that gets named launches as a teammate. Names get assigned automatically so agents can message each other, which means teams can form during delegation you never framed as team work — and you can be paying team economics without having asked for a team.

If you see that happening, setting the variable to 0 restores normal subagent behaviour, and it applies to the next spawn without needing a new session.

The takeaway

Parallel isn't free — you pay rent on every context window, and with teams in plan mode that's roughly seven times a single session. But aim the caution correctly: teammates are the expensive shape, subagents that read and summarise are the cheap one. Use subagents to look at things. Use a team only when the work really splits into pieces that need to argue with each other.

Building an AI feature? Yeda AI designs, audits, and ships production LLM systems.

Talk to us · Read the blog