← Sim-Maker Kit
Sim-Maker Kit

When to use a swarm

Pointing several AI agents at a job in parallel is powerful — and the fastest way to burn through a metered plan. Here's the rule for when it pays off, and when it just costs you.

The rule

Default: don't.

Building one sim is a one-agent job — always. A swarm can't build a single HTML file faster: there's only one file, so the agents collide, duplicate work, and you pay N times for one result. One agent, one file.

The cheap-first ladder

Stop at the first rung that works.

  1. One agent. Almost everything — building, fixing, or explaining one sim.
  2. One agent, several steps. "First do X, then Y." Cheaper than a swarm, and you can course-correct between steps.
  3. A swarm — only when the work is both broad and independent: many separate items, no shared state, each agent finishing without waiting on the others.

If the pieces depend on each other, it's not a swarm job — it's rung 2.

When a swarm actually pays off

Not building — gathering.

Decide what to build

"Research 8 topics students struggle with and rank them" — 8 agents, one topic each.

Audit many at once

"Check these 20 sims for the same bug" — one agent per file.

Find references

"Search for open-source examples across these sources" — one agent per source.

The test

Could you hand each agent its slice on a separate sticky note and never have them talk? If yes → swarm. If no → one agent.

The catch: swarms make things up

⚠ Verify before you build

Parallel research agents confidently invent citations, stats, and "facts" — a real, measured failure mode. Never trust swarm research output as-is. Spot-check the load-bearing claims against a primary source first. One fabricated "students struggle with X" sends you building the wrong sim.

Before any swarm — the token gate

Rule of thumb: swarm to find out what to build, never to build it.
Built for studying with AI · MIT-licensed — free to use and adapt.
Source: WHEN-TO-USE-A-SWARM.md