Is a Multi-Agent Coding Squad Worth the Tokens It Costs?

Is multi-agent AI coding worth it, or just fast?

A lead agent ran overnight with three helpers, working a backlog that had sat for a week. Every task is finished by morning, and the usage page shows a token total far bigger than one night of work should cost, enough to make you wonder whether one agent, working the same hours, would have gotten most of the way there for less.

That has a real answer, not a vibe. A squad costs measurably more than a single chat reply, and whether it was worth it depends on what came back for that cost. It is like hiring a team for an afternoon instead of working alone: the team costs more total hours, even when it finishes faster. Nobody is shocked a team costs more. The surprise with agents is that nobody told you the multiplier first.

• Finishing a backlog overnight is not proof a squad was the cheap option.
• The real comparison is tokens spent against the value of finishing sooner, not against zero.

The multipliers, measured by the people selling you tokens

Anthropic published its own numbers from running a multi-agent research system in production. A single agent working alone uses roughly four times the tokens of a chat reply, reading files, running tools and keeping history. A multi-agent system, a lead directing several workers, uses roughly fifteen times a chat reply, because each worker carries its own history and tool calls at once.

Gartner's analysis, as reported by CRN Asia, puts agentic workflows more broadly at five to thirty times the tokens of a single chatbot query, a wider range covering more kinds of agents and work. Both figures say the same thing: coordinating more than one agent costs real, countable tokens before any useful work gets done.

Anthropic found token usage explained about 80 percent of the difference in how well its system performed, and the multi-agent version beat a single Opus 4 agent by 90.2 percent on its research evaluations. The spend bought something real there; whether it buys something real in your job is the question.

• About four times a chat's tokens for one agent, about fifteen times for a multi-agent system, per Anthropic.
• Five to thirty times a single chatbot query, per Gartner as reported by CRN Asia.

Why the bill climbs even while the price per token falls

The price of a token has been falling. Per CRN Asia's reporting of Gartner's analysis, the cost per million tokens dropped from about ten dollars to about two dollars fifty in a year. A falling unit price should mean a falling bill, for a fixed amount of work.

Multi-agent work is not fixed. It is five to thirty times more work for the same task, by Gartner's estimate, or fifteen times by Anthropic's. Cut the unit price by three quarters and multiply the volume by fifteen or thirty, and the total still rises. Enterprise token bills have kept climbing for that reason: volume, not price, drives the spend, and a squad is the volume, since every helper added is a new agent with its own context, tool calls and tokens.

• Cost per million tokens fell from about ten dollars to about two dollars fifty in a year, per Gartner via CRN Asia.
• Enterprise bills rose anyway, because volume outran the price drop.

The rule that decides whether a squad pays for itself

One rule covers it. A squad pays off when a job splits into pieces that do not depend on each other, and finishing sooner is worth more than the extra tokens burned to get there. Both halves have to be true: a job that splits but is not urgent does not need to be faster, and an urgent job that does not split just turns into agents getting in each other's way.

Anthropic says the same from inside its own product. Its engineering writeup names heavy shared context between agents, or many dependencies between steps, as a bad fit for its multi-agent system, because the lead waits for a batch of workers before handing out the next one, a bottleneck paid for in time on top of tokens.

Name the value before you start, even roughly: what is an hour saved worth, is someone blocked on this. Without a named value, a squad is probably running because it was available, not because the job needed one.

• Pays off: independent pieces, and finishing sooner is worth more than the extra tokens.
• Anthropic names heavy shared context and many dependencies as a bad fit for its own multi-agent system.

Where it loses: one tightly coupled change

Cognition, the company behind Devin, makes the opposite case, and it deserves a fair hearing. Its piece Don't Build Multi-Agents argues for a single, linear agent as the default, because every action carries an implicit decision, and agents that cannot see each other's context make conflicting decisions without knowing it. A function renamed by one worker and relied on, unrenamed, by another is exactly that failure.

The argument lands hardest on one tightly coupled change: a refactor touching the same files from several angles, a bug whose cause and fix sit in the same function, a migration where step two only makes sense in light of step one. None of that splits into independent pieces, so a squad buys parallel tokens and serial problems at once. One agent, seeing the whole change, is the cheaper and better call there.

Vendor features that delegate inside one agent are real and worth using on work that fits. Claude Code's subagents give a worker a fresh, isolated context in one session, and its experimental Agent Teams puts a lead and teammates on a shared task list. Codex CLI ships subagent workflows on by default, recommended for read-heavy work, warning that write-heavy parallel work can create conflicts. Each lives inside one vendor's session; none changes the rule above.

• Cognition's argument: implicit decisions plus no shared context between agents equals conflicting decisions.
• A tightly coupled refactor, bug fix or migration does not split, so a squad adds cost without adding speed.

A checklist before you start a squad

Run through this before a lead agent is turned loose on helpers, not after the bill arrives.

• Can this job split into pieces that do not touch the same files or depend on each other's output? If not, stop here.
• Is finishing sooner worth something specific: a deadline, a blocked teammate, a release window? Name it, do not assume it.
• Would one agent, working the pieces in sequence, actually take meaningfully longer, or just feel slower?
• Is there a way to see what each helper is doing without asking it?
• Is there a way to stop a helper that has stalled, before it keeps running on your account?

Cheap habits that cut the waste without cutting the squad

A squad does not have to spend at its worst case. A few habits bring the bill down without giving up what a squad is good for.

Give the lead a job that is only planning. A lead that also writes code fills its own context with diffs and test output, the same bloat that makes a long session expensive.

Put a cheaper model on bounded, well-specified work. Claude Code resolves a subagent's model in order: a per-invocation parameter, then the frontmatter field, then an environment variable, then the main conversation's model. A small, boxed task does not need the model doing the planning.

Cap how many helpers can run at once, as a feature, not a limitation. Claude Code's default concurrent-subagent limit is 20, and Anthropic has reported its own early failure: a system that once spawned 50 subagents for a query that needed nowhere near that many.

Stop a stalled worker as soon as it is noticed rather than waiting to see if it recovers. A stuck worker may be retrying or re-reading the same files, and each costs tokens while it waits.

• A lead that only plans stays lighter than one that also writes code.
• A cap on concurrent helpers, treated as a feature: it is usually the number you can actually review.

What Forkbench actually changes: visibility, not the bill

None of the habits above are something a tool does for you, and nothing here claims a tool lowers a token bill. Forkbench, a desktop app for running coding agents in a real terminal on your machine, does not choose or route models, does not set a token budget, and does not meter tokens. A lead agent can suggest a helper, but nothing starts until a human approves it, the moment to ask whether the task needs one.

What a squad on Forkbench's board changes is whether the spending can be seen and acted on before it compounds. Each helper's claimed task shows beside its own terminal, so you know what it is doing without asking, and the board is written to disk, surviving context compaction, a closed pane, quitting the app and a reboot. A claim is a lease: closing a pane releases it at once, a 120-second heartbeat backstops a stuck helper, and a stall alert fires once a Thread's board goes quiet too long.

The other half is the acceptance gate. A helper can report a task finished, moving it to awaiting acceptance, but only a human accepting it makes it done. No agent can verify its own work or raise its own rank, and a disagreement becomes a discussion that keeps the task open. That gate does not prove the work correct; its value is reviewing it before the next task is built on it.

• The board is written to disk and survives context compaction, a closed pane, quitting the app and a reboot.
• Only a human accepting a finished task makes it done; no agent can accept its own.