Swarming
Swarming is the practice of giving several focused workers one coherent outcome. The best swarm is not the biggest one. It is the smallest structure that creates useful parallelism while keeping ownership, dependencies, and review clear.
Consider swarming only when necessary, such as for escalations or rapid design iterations. Do not hand off your understanding to the Swarm. Its agents mean well, but the outcome is still yours to own.
Model selection
These are our preferred recommendations, not universal rules. Every Swarm provider includes sensible defaults selected for a strong out-of-the-box experience.
A strong default for implementation. Moving to a slower, more capable model can help with unusually difficult work, but the extra wait is not always the best trade: a faster first pass plus focused review and correction may reach a reliable result sooner.
Balance: implementation depth × turnaroundFinder benefits from speed, a large working context, and low-cost inspection. It can scan separate areas of a codebase, compress the evidence, and return a focused map so the primary model spends fewer expensive tokens rediscovering the same ground.
Balance: coverage × compression × costA practical default for fast visual exploration. For demanding motion and animation work, stronger frontier models, such as Gemini 3.7 or Claude Opus 5 when available, may produce more refined results, but usually with higher cost or latency.
Balance: visual quality × iteration speedFast or Priority mode is intentionally off by default, leaving you free to decide when to use it. Try different models and settings, then judge the whole loop: generation time, token cost, review effort, and the quality of the final integrated result. Our recommendations are a starting point. The best setup depends on your individual workflow.
Choose the pattern
Start with the shape of the work, not a target agent count. Swarm can handle a cohesive task directly, delegate one dependency-ready wave, explore alternatives through an Iteration Swarm, or coordinate dependent stages through a Task Program.
Use for one cohesive change where delegation would add more handoff cost than value.
Use for bounded assignments that can start from the same known state and finish independently.
Meet the agents →Use when you want fast ideas, implementation trials, design directions, or generated image alternatives.
Explore iterations →Use when foundation work must integrate before downstream jobs or a fresh-context audit can begin.
Build a program →Shape the work
Tell Swarm exactly what you want to accomplish, including the important constraints and what success looks like. You usually do not need to divide the work or write a distinguished assignment for every worker. Swarm should decide whether delegation will help, choose the right agents, and give each one a focused job.
Start the session in Plan mode before sending your request. This gives the more powerful planning model time to reason through the work and prepare better prompts for subagents. When running a larger swarm, use worktrees to keep concurrent changes isolated.
Run a good swarm
Lock the user-facing goal, constraints, likely files, and what evidence will prove the work complete.
Run independent jobs together. Wait for integration before launching consumers that rely on their output.
Review the integrated behavior, fix known gaps, and report one recommendation instead of a stack of raw child notes.
More workers are useful only when they reduce wall-clock time or produce meaningful alternatives. Overlapping scopes, vague prompts, and dependent jobs launched together make a swarm slower and harder to trust.
Own the outcome
A swarm can explore more ground, complete independent work in parallel, and help you reach an end goal faster. It does not replace your judgment. Treat every handoff as progress toward the outcome, not proof that the outcome works.
Speed creates leverage. Review turns it into confidence.
State the goal, constraints, boundaries, and evidence that will count as done.
Ship only when the evidence matches the outcome you asked for.
You can run the checks yourself or ask AI to help design and run focused tests. Keep the loop open until the evidence is convincing.
Do not expect to hand off everything and return to a perfect result. Pay close attention to what you delegate: a small, careless instruction can send well-intentioned agents in the wrong direction and waste hours of work and credits. Review the plan, watch the handoffs, and redirect early when the work no longer matches your goal.
Choose the right work
Swarms are strongest when several workers can explore or change distinct parts of a problem at the same time.
Match the work to the kind of attention it needs.
Several workers can own distinct angles without losing the thread.
Workers can take separate API boundaries, update them in parallel, and bring the results back together around one shared contract.
Independent directions can be explored at the same time, making it faster to compare real alternatives and choose what works.
Finders can inspect different attack surfaces independently, then combine their evidence to expose gaps one pass might miss.
Continuity and one coherent point of view matter more than breadth.
Extra handoffs can interrupt concentration and multiply review work when the task depends on noticing small, connected details.
Foundational tradeoffs benefit from sustained context, consistent judgment, and a clear owner who can carry decisions forward.
Dividing the prose often fragments its voice and narrative; one writer is better placed to make the whole explanation feel intentional.
Don’t be afraid to stop in the middle of a task and redirect or start over.