Google wants you to stop working with one AI coding agent and start running a team of them. On November 10, 2026, the Antigravity team rolled out /swarm in preview, alongside Gemini 4 Carbon. Type the command and a coordinator agent spins up parallel workers and a verifier that post to a shared message board. Our news write-up of the /swarm preview covers the features and limits.
My view: agent swarms are a real tool, but the choice to use one is a budget decision first and an intelligence upgrade second. The best evidence for that comes from the companies that build these systems.
Google's own fine print says it
The most honest line in Google's launch post sits in parentheses. After describing five weeks of internal use, the team adds: "As a fair warning, even with zero-token idle waits and dynamic model hot-swapping, parallel multi-agent systems consume quota much faster than a standard chat."
That is a fair warning, and I credit Google for printing it. But it should be the headline, not the footnote. A swarm is many agents reading, thinking and writing at once. Each one spends tokens. On a subscription with quotas, that means you hit the ceiling sooner. On a pay-per-token API, it means a bigger bill.
Google's design does try to soften this. Agents park "at zero token cost when idle", and each agent can be pinned to a different model. The post pitches Carbon, which it says runs "extended verification loops using more tokens", for coordinator and verifier roles, while "lighter, faster models handle the parallel file edits and routine implementation tasks." That is sensible cost control. It is also an admission that the default is expensive.
Anthropic measured the cost
The clearest public numbers come from Anthropic, which in June 2025 wrote up how it built the multi-agent system behind Claude's Research feature. Its findings cut both ways.
On the upside, Anthropic reports that a multi-agent system with Claude Opus 4 as the lead and Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval." That is a large gain, though on Anthropic's own internal test.
On the cost side, the same post says: "In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." Note the hedges: "typically" and "about". Even so, 15 divided by 4 is 3.75, so by those figures a multi-agent run uses nearly 4x the tokens of a single agent.
Then comes the line that I think explains the whole category: "Multi-agent systems work mainly because they help spend enough tokens to solve the problem." In Anthropic's analysis of the BrowseComp browsing test, token usage by itself explained 80% of the performance variance.
Read that plainly. A big part of what a swarm buys you is permission to spend more compute on a problem. That is worth paying for on hard problems. It is waste on easy ones.
Coding is the harder case
Anthropic also flags where this does not fit. It writes that "most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time."
Cognition, the company behind the Devin coding agent, went further. In a June 12, 2025 essay titled Don't Build Multi-Agents, Walden Yan set out two principles: "Share context, and share full agent traces, not just individual messages" and "Actions carry implicit decisions, and conflicting decisions carry bad results." His example is two subagents building parts of a Flappy Bird clone that end up in clashing styles because neither could see the other's work. His advice: "the simple architecture will get you very far."
Google's design reads like a reply to that critique. Google's blog says workers run in "isolated git worktrees so edits never collide," though the /swarm docs say workers share your workspace by default and get their own working copy when several edit at once. Every agent collaborates on "a shared, append-only message board." Whether that is enough to fix the context problem is the open question. A shared board helps agents see each other's messages. It does not guarantee they make the same unstated choices.
Who wins, and what I would do
In my view, the clear winner is the platform. A feature that burns quota faster gives heavy users a reason to buy more of it, and Google says Gemini 4 Carbon in Antigravity starts with Google AI Ultra subscribers, while the /swarm docs list Google AI Pro and Ultra plans. That is not a scandal. It is how usage-based products work, and buyers should see it clearly.
The other winner is the team with a genuinely wide job. Google's own examples are "multi-package migrations, cross-subsystem root-cause investigations, and complex architectural redesigns." Google says a single agent works well for scoped tasks but "breaks down when a change spans dozens of files and test suites." I believe that.
What I think is underrated in /swarm is not the parallel workers. It is the verifier: agents "dedicated to running tests and challenging diffs." Spending extra tokens on checking work is a better trade than spending them on producing more of it. If I tried /swarm, I would start with a single worker plus a verifier before scaling to a crowd.
My rule of thumb is short. If the work splits cleanly into parts that do not depend on each other, a swarm can earn its cost. If every step depends on the last one, one agent with good context is cheaper and often safer. That fits the case I made earlier: start with a workflow, not an agent, and reach for a small model before a big one. A swarm is the next step up that ladder, not the first rung.
