Published: 2026-09-07
Deep dive

Running agent swarms with hard spend caps, and why the answer is a sandbox

Chapters / key moments (click to jump — plays here on the page)

The warning is delivered before the demo, and it is the right order. Agent swarms are described as experimental, expensive, dangerous and advanced work that requires understanding sandboxing, prompt, context and harness engineering — and the whole thing runs on an isolated Mac Mini for exactly that reason. What makes this usable rather than a spectacle is that every swarm is launched with a hard dollar ceiling and a named model, and the UI exposes swarms, message threads, individual agents and a full trace. The stated lesson from the incident that prompted the video is simple: the engineers scaled agents up and then looked away.

Source video

"Are Agent Swarms USEFUL? OpenAI's GPT-6 Astra SWARM Takeaways" by IndyDevDan — Watch on YouTube →

Step-by-Step Breakdown

Start with a one-agent hello world
The simplest possible swarm: a single agent, one model, a spend limit of ten cents, and one prompt. It returns a greeting. The point is not the output — it is establishing that the structure (swarm → threads → agents → trace) works before any scale is added.
Run it on hardware you are willing to lose
The swarms run on a dedicated Mac Mini, observed from a separate machine over the local network. This is stated as a deliberate containment choice rather than a convenience, and it is the single most important setup decision in the video.
Pin a model and a budget per swarm
Each swarm is launched with both, explicitly. The demonstrated runs: 10 agents on GLM 5.3 with a $50 ceiling; 20 agents on DeepSeek V4 Pro with $40; 30 agents on Gemini 3.7 Flash with $30. Pinning the cheaper models for larger swarms is the cost strategy, and the ceiling is what makes an unattended multi-agent run something you can walk away from.
Keep the message threads visible
The UI exposes messaging threads between agents alongside tool calls and a full trace. This is flagged as the most important element and as precisely what was missing in the incident being discussed — agents coordinating through a channel nobody was watching.
Give it a falsifiable task
The three parallel runs are given concrete, checkable goals rather than open-ended ones: a known visual benchmark, a raytracer as an HTML5 canvas application, and rebuilding an animation from a live website (with the honest note that the target site's protections may defeat it).

Gotchas & Caveats

Experimental and expensive by the presenter's own description. The dollar figures here are per-run ceilings on single demonstrations, not a sustainable operating cost.
The swarm system shown is the presenter's own early build; nothing here is a product you can install today.
Discussion of the incident that prompted the video is second-hand reporting of a widely covered event. The demonstration is first-hand; the incident narrative is not.
Running many agents against a live third-party website — as one of the three demos does — is the kind of thing to think about before copying, both for the target's sake and yours.

Key Takeaways

Spend ceilings per swarm are the control that makes this practical. $0.10 for a hello world, $30–$50 for real runs, set at launch.
Cheaper models scale wider. The largest swarm uses the cheapest model — 30 agents on a Flash-tier model for $30 — which is the same expensive-planner/cheap-executor economics that shows up across multi-agent setups.
Visible message threads are the safety feature. The failure being discussed is agents coordinating unobserved; a swarm UI without a trace reproduces it.
Sandboxing is a prerequisite, not an enhancement. The video is explicit that this needs a machine you have isolated deliberately.
The interesting question is framed as engineering, not spectacle: can swarms be directed to produce valuable outcomes without simply burning tokens?
This is a V1 demo of the presenter's own swarm system, shown running rather than described.