Parallel swarms
One request in.
Sixteen workers out.
Split any decomposable job across up to 16 sandboxed workers — run them in parallel or as a pipeline — and get back one merged answer, streamed live, under one hard budget.
curl https://api.swarms.dev/api/v1/swarms \ -H "Authorization: Bearer $SWARMS_KEY" \ -d '{ "objective": "Tear down pricing for our 8 largest competitors", "tasks": ["acme", "northwind", "…"], "aggregatorTask": "Merge into one comparison table with a verdict", "budgetUsd": 2.00 }' # → 201 { "swarmId": "swm_4c1…", "workers": 8, "status": "running" }# Eight readers. One table. One bill.Serial is a habit, not a law. A job with eight independent parts does not need one worker for eight hours — it needs eight workers for one. Swarms makes the fan-out a single request: parallel workers, one shared budget, one merged answer, and your afternoon handed back.
Parallel or pipeline
Shape the team to the job, not the job to the team.
Some jobs shard cleanly — one worker per competitor, per file, per section. Others are assembly lines, where the edit needs the draft. Swarms runs both: up to 16 workers per run, fanned out in parallel or chained as a pipeline.
Bigger shapes compose from the same parts. DAG workflows wire stages into arbitrary graphs, and any run can be replayed later — same structure, same inputs, new answer.
one call · four workers · one answer
The aggregator
Many outputs in. One answer out.
Sixteen raw outputs are not an answer — they are homework. So an optional aggregator worker gets every result and one job: merge it all into a single deliverable — a memo, a table, a verdict.
You never poll in the dark. Progress streams over SSE as each worker finishes, and signed webhooks notify your systems the moment the merged answer lands.
GET /api/v1/swarms/swm_4c1…/events # SSE event: worker.completed {"worker":3,"costUsd":0.19}event: worker.completed {"worker":7,"costUsd":0.22}event: aggregator.startedevent: swarm.completed {"answer":"…","costUsd":1.74} # or register a webhook — signed, retried until# your endpoint acknowledges itOne shared ceiling
Sixteen workers. One budget. Zero surprises.
The swarm shares a single hard ceiling, reserved before anything runs. If one worker rabbit-holes, it is stopped at the line — the run degrades gracefully instead of the bill multiplying by sixteen.
Underneath the cap, every worker is metered on its own. Each line of the bill names the worker that incurred it, so you know which part of the job cost what.
budgetUsd: 3.00 — a physical ceiling
Stop thinking “a smarter agent.” Start thinking “a team — assembled per request, sized to the job, disbanded the moment the answer merges.”
What that unlocks
Afternoons become minutes
Eight competitors, eight workers, one comparison table. The wall-clock time is the slowest worker, not the sum of all of them.
Pipelines without glue code
Draft, edit, fact-check as sequential stages. The platform handles the handoffs — no queue you maintain, no cron duct tape.
Runs you can replay
The competitor teardown that worked in March runs again in April — same DAG, same tasks, fresh data, one call.
A bill itemized per worker
Per-worker metering under one shared cap. When finance asks why Tuesday cost $1.74, the answer is eight labeled line items.
Keep exploring
Give your agent a workforce.
Start free. Spawn your first swarm in minutes. Pay only for the GPU-seconds you use.