Benchmarking 100 Parallel AI Sessions: The Century Run
What does it actually cost to run a swarm of 100 autonomous AI sessions building standalone HTML/Canvas dashboard components targeting 60fps animation on a single machine? Over 3 days of dogfooding, we went from breaking at 50 agents with a $72 exploration loop to orchestrating 100 sessions across a 10-wave parallel cadence for under $10 ($0.0997/artifact), with 1.21 GiB peak daemon RAM and zero deadlocks.
Gemini Flash 3.6
Fast frontier model running with native tool calling, low thinking, and deterministic prompt caching via the official API.
100 Real Canvas Apps
Build 100 standalone HTML/Canvas dashboard cards with zero CDN dependencies and live 60fps telemetry loops on one PC.
100 Sessions for $9.97
100% autonomous delivery without retry scripts. Cost plunged to $0.0997/app, errors fell 96.7%, and RAM capped at 1.21 GiB.
The Century Run was not a single 100-agent gamble. It was an empirical 5-stage progressive stress ladder measuring how daemon memory, token economics, and error rates scale under increasing concurrency on a single 12-core Linux PC. Below is what each tier represents, how the initial benchmark compared to the final run, and how hardware scaled over time:
Single Session
Baseline cold launch. Tests daemon startup, Pebble KV initialization, and clean tool dispatch without multi-process interference.
Multi-Session
Sequential process reuse. Proves daemon buffer pooling; marginal RAM plummeted 80% once daemon caches primed.
Swarm Wave
First parallel swarm wave. Goroutine stack pooling and parallel Pebble LSM writes kept daemon RSS under 1.1 GiB.
Mega Swarm
Where baseline collapsed into 752 retry loops from markdown ambiguity. Candidate's direct tool calls killed the loop completely.
Century Run
100 simultaneous autonomous agents building 100 canvas apps on 12 cores for $9.97 with 1.21 GiB peak RAM and 0 deadlocks.
Asking for markdown code blocks tricked models into conversational streaming instead of calling tools, triggering 50–80 turn schema exploration loops that burned 94% of wasted tokens.
Turn 2 repairs ran delete-then-create sequences on draft files. Under high concurrency, sequence numbers drifted, causing cascading CAS conflicts and requiring manual retry scripts.
8KB handoff code ceilings choked large 12–25KB canvas components; plan_manage hard check-off lockouts trapped models in circular refusal cycles when closing subtasks.
Explicit prompt contracts to publish directly via manage_artifact create with stable <main id="..."> region tags killed exploration loops completely.
In-place artifactV3Author.Edit on repair turns eliminated draft collisions and sequence drifts, delivering 100% verified interactive components without human intervention.
Expanded handoff code blocks to 64KB and decoupled subtask lifecycle gates, letting models mark tasks done cleanly without prematurely closing checkpoints.
We Just Wanted to See What a Swarm Would Cost
The premise was simple: we wanted to benchmark how much it would actually cost to run a swarm.
To run an authentic benchmark, agents can't just spit out chat summaries or mock text. They have to build something real. So each agent was tasked with authoring a standalone HTML/Canvas dashboard component targeting 60fps animation and visualizing synthetic systems telemetry with zero external CDN dependencies.
We originally set out to measure hardware limits: CPU and memory consumption across 1 → 5 → 25 → 50 → 100 sessions (structured across 5 tiers with sequential and multi-session parallel waves) on a single machine.
Then we saw the bill: $139.65. Tier 4 alone (50 agents) cost $72.60—more than the other four tiers combined! Agents were stuck in 80-turn exploration loops frantically re-reading Go schemas.
In daily development, agent error recoveries feel completely normal. A model hits a validation error, searches a file, self-heals, and you move on. But when 100 agents run simultaneously, those “normal” microbugs compound exponentially into thousands of wasted tokens, sequence desyncs, and runaway bills.
This was the first time Swarm was stable enough functionally—with model switching, video choreo, and system agents working smoothly—that we could finally focus on the finer runtime mechanics.
The 3-Day Dogfood Story: Microbugs, Broken Features & The Fix
A fast, 4-beat timeline of the bottlenecks we hit and the Go runtime fixes that turned a $139 benchmark into an autonomous $17 run.
Functionality First, Benchmarks Second
Before running benchmarks, we just needed Swarm to work—wiring multi-model switching, video choreo, and dynamic system agent roles. Once core plumbing ran, we asked the real question: What happens when 100 agents run simultaneously on local hardware?
The Concurrency Wall & The $72 Loop
At 50 agents, Tier 4 exploded to $72.60 alone as agents entered 80-turn tool exploration loops. Turn 2 draft CAS collisions and checklist lockouts pushed the baseline bill to $139.65 with 1,467 tool errors, requiring manual retry scripts.
Hunting Microbugs in the Go Daemon
We audited the root causes with Finders and patched swarm-go: in-place CAS draft edits, decoupled subtask checklist gates, 64KB handoffs, and headless preview timer freezes. We hardened prompt contracts to publish directly via manage_artifact create.
The Century Run Re-Born: 100 Sessions for $9.97
Re-running Tier 5 delivered 100/100 dashboard components targeting 60fps animation for $9.97 total (under 10¢ ($0.0997) per component). All 181 candidate sessions completed without manual re-prompts or external retry scripts, recording 49 tool-error events (down 96.7%) and capping peak daemon RAM at 1.21 GiB.
Before & After: The Concurrency Ladder
Clear empirical comparison across all 5 tiers (1 → 5 → 25 → 50 → 100 concurrent agents).
Progressive Concurrency Scaling & Error Eradication
VERIFIED LOCAL TELEMETRY| Tier | Concurrency Structure | Baseline Cost | Candidate Cost | Cost Delta | Errors (Base → Cand) |
|---|---|---|---|---|---|
| Tier 1 | 1 session | $0.72 | $0.12 | -83.5% | 4 → 0 |
| Tier 2 | 5 sessions (sequential) | $3.92 | $0.42 | -89.4% | 19 → 0 |
| Tier 3 | 25 sessions (5 waves × 5) | $13.85 | $3.03 | -78.1% | 179 → 16 |
| Tier 4 | 50 sessions (10 waves × 5) | $72.60 | $4.23 | -94.2% (17.1x) | 752 → 7 |
| Tier 5 (Century Run) | 100 sessions (10 waves × 10) | $48.56 | $9.97 | -79.5% (<10¢/app) | 513 → 26 |
| Totals | 181 Completed Sessions | $139.65 | $17.77 | -87.3% | 1,467 → 49 (-96.7%) |
* Scheduling structure: Each tier ran as sequential waves of concurrent sessions (e.g. Tier 5 dispatched 10 waves of 10 concurrent sessions). Daemon RSS and storage contention were measured continuously across all sessions in the tier.
What Did Each Agent Actually Build?
Zero placeholders. Zero mockups. Zero CDN dependencies. Every single one of the 181 autonomous sessions authored and validated a standalone HTML/Canvas dashboard component targeting 60fps animation and visualizing synthetic systems telemetry. All 181 candidate artifacts were checked for Canvas 2D context creation and requestAnimationFrame usage.
Autonomous single-agent baseline deliverable. Features animated dual-radial dial gauges, synthetic thread load generator, and rolling telemetry sparklines.
- ✓ Zero CDN dependencies
- ✓ Pure Canvas 2D context
- ✓ requestAnimationFrame loop
- ✓ Cyberpunk dark theme (#0B0F1A / #00E5FF)
The Prompt Evolution: Clarifying Tool Contracts
At single-agent concurrency, models often absorb ambiguous instructions. At 50 sessions, underspecified tool contracts and validation failures led to repeated exploration loops. The combined runtime and prompt changes reduced recorded tool-error events by 96.7% and the reported cost of the full ladder by 87.3%. Below is the prompt evolution that aligned tool parameters with daemon validation.
Prompt Hardening: Killing the Markdown Trap
In our initial baseline, asking for a markdown code block tricked agents into conversational streaming instead of direct tool execution—igniting 50-turn schema exploration loops. Here is the exact contract fix.
manage_artifact. When the engine prompted for tool publication, models panicked, probed schemas, and looped for 50-80 turns.Replaced delete-then-create on draft files with in-place repair edits, killing CAS conflicts.
Relaxed plan_manage hard check-off lockouts that trapped models in refusal cycles.
Expanded handoff limit from 8KB to 64KB so full 12-25KB single-file canvas apps passed validation.
Why Swarm Scales: The 4 Systems Pillars
Autonomous agent concurrency introduces classic systems engineering challenges around memory sharing, storage durability, and prompt caching. Here is how Swarm's runtime architecture handles high-density session workloads.
Sub-Linear Memory Sharing
Swarm runs natively inside a compiled Go daemon where goroutine stacks, shared memory arenas, and tool schema buffers are pooled within a single process. Across the benchmark ladder, peak daemon resident set size (RSS) was capped at 1.21 GiB (1,213.7 MiB) at 100 sessions—compressing marginal RAM to 11.12 MiB per pipeline (~12.1 MiB daemon RSS per session), down from 484.8 MiB marginal RAM in single-agent initialization.
Pebble Key-Value Storage
Swarm persists session event logs and artifact state using Pebble, a LevelDB/RocksDB-inspired key-value store implemented in Go with an LSM tree architecture. Unlike relational stores using SQLite in WAL mode—which allows concurrent readers but serializes writes through a single writer lock—Pebble's append-only write-ahead log and background memtable flushes accommodated the multi-session write load without observed write-lock stalls during the benchmark.
Deterministic Prompt Caching
Swarm strictly determinizes context assembly: system tools, agent profile prompts, and workspace policies are ordered identically across sessions. This enabled an average 80.2% to 91.4% prompt cache hit rate across prompt tokens (80.2% candidate overall average, 80.9% in the 100-agent Century Run). Together with runtime tool improvements that curtailed repetitive loop turns, the combined changes reduced total ladder cost by 87.3%.
Independent Artifact Publishing
Each agent published an independent artifact, avoiding shared-file edits and Git merge conflicts in this workload. This benchmark did not test shared-repository integration or security isolation; rather, it evaluated agent session stability and daemon throughput when sessions produce independent, self-contained deliverables.
Next Steps: Scaling Real Coding Tasks
Authoring standalone HTML/Canvas dashboard components targeting 60fps animation was an effective coding task to stress-test concurrency, storage durability, and token economics without git merge noise. Now that the runtime foundation is benchmarked, here is where we are focusing next.
Methodology & Verification Harness
All benchmarks were executed on bare-metal Linux hardware under isolated, reproducible conditions adhering to Swarm's automated capture standards.
Execution Environment & Host
- Host Hardware: 12-Core AMD Ryzen 9 7900X x86_64 (24 threads), 32GB DDR5 RAM, NVMe Gen4 Storage.
- Operating System: Ubuntu 24.04 LTS (Kernel 6.8, low-latency CPU governor).
- Daemon Runtime:
swarmdv3 compiled Go binary running natively on host (no containerization overhead). - Virtual Display: Headless X11 virtual frame buffer (
Xvfb :98at 1920×1080×24). - Resource Sampling: Linux kernel
/proc/<pid>/status(VmRSS, VmSize) and/proc/<pid>/statpolled every 500ms.
Runtime Commits & Storage
- Baseline Engine (`swarm-go` commit
a327abac): Unoptimized engine with delete-then-create CAS draft authoring (causing sequence desyncs under concurrency), rigid subtask completion lockouts, 8KB handoff code block ceiling, and ambiguous markdown prompt requests. - Candidate Engine (`swarm-go` commit
014275e7): Remediated engine featuring in-place CAS draft edits (artifactV3Author.Edit), decoupled subtask lifecycle gates, 64KB handoff code block ceiling, and directmanage_artifact createprompt contracts with stable region tags. - Storage Engine: Embedded Pebble key-value store in Go with LSM-tree architecture, write-ahead logging, and background memtable flushes.
- Execution Structure: 5 progressive tiers (Tier 1: 1; Tier 2: 5 sequential; Tier 3: 25 in 5 waves; Tier 4: 50 in 10 waves; Tier 5: 100 in 10 waves).
Model Provider & Accounting
- Model & Provider: Google Gemini Flash (
gemini-3.6-flash, thinkinglow) via official Google Generative Language API (native function calling, deterministic context caching). - Cost Accounting Scope: Measured in real time by Swarm's durable V3 session usage accounting store directly from upstream provider token usage metadata across every execution turn. Token accounting encompasses prompt tokens, provider prompt cache reads, and generated output tokens.
- Local Host Exclusion: Token cost reflects API provider usage only; amortized local hardware, NVMe wear, and host electricity are excluded.
- Prompt Caching Structure: Strict deterministic context prefixing across system tools, workspace instructions, and agent profile headers.
Verification & Artifact Extraction
- Deliverables Inspection: All 181 candidate artifacts were checked for Canvas 2D context creation and
requestAnimationFrameusage. - Autonomous Completion: Defined as reaching terminal handoff without manual re-prompts or external retry scripts (181/181 candidate vs 3 timeouts requiring retry script in baseline).
- Error Accounting: Recorded tool-error events across the entire ladder (49 candidate vs 1,467 baseline).
- Lossless Video Capture:
ffmpeg -f x11grab -framerate 60recording lossless FFV1 master MKVs from the virtual display. - Delivery Transcoding: 1080p 60fps MP4 (
libx264 -crf 18 -pix_fmt yuv420p).
Run Autonomous Swarms on Your Own Hardware
The Swarm runtime daemon, database, virtual display, and session coordination ran entirely locally on Linux; model inference was served via remote provider APIs. Spin up single agents or multi-session task programs without cloud lock-in, external runtime dependencies, or runaway memory bloat.