---
title: "Parallel is a budget, not a speed setting"
url: "https://toddpaulbrownjr.com/writing/parallel-is-a-budget/"
author: "Todd Paul Brown Jr."
description: "** Ten parallel subagents burned a five-hour budget in 33 minutes. The fix was a cap and a rule, not a bigger plan — and the same lesson applies to…"
kind: "article"
updated: "2026-09-26T02:50:37+00:00"
---

# Parallel is a budget, not a speed setting

Ten parallel subagents burned through a five-hour session budget in 33 minutes. The shared web-search allowance — 200 searches for the whole session — emptied almost immediately. Eight of ten agents were killed mid-write by the API, and one critical report was lost outright and had to be rewritten.

That was FAIL-0001, logged 22 August 2026, while building the research phase for a local-model benchmarking tool I'm calling Milkman. A lead agent had launched 10 subagents at once: three on a harder-judgment model, seven on a standard one. Several of those sub-forked their own subagents. They raced each other for one shared resource pool instead of multiplying throughput, and the session was dead before I looked at the screen.

The fix wasn't a bigger plan or more budget. It was a cap and a rule: no more than three concurrent subagents, no subagent may fork its own subagents, word caps on every subagent output, models tiered to task difficulty, and checkpoints written to disk early. That rule still runs today.
## Why it happened

Parallelism looks like a speed setting. More agents running at once should mean faster results, and in some systems it does. But in an agent harness with a shared resource pool — search calls, API tokens, memory, disk — uncoordinated parallelism is a budget decision, not a speed multiplier.

When ten agents all start pulling from the same 200-search budget at the same time, each one treats the budget as if it were theirs alone. None of them knows how fast the others are spending. The budget empties, the API kills the slower ones mid-task, and you lose work that was already half-done.

The same mechanism hit [Content Ops](/builds/content-ops/) from a different angle. At three parallel content jobs, the server ran out of memory. The drafting pipeline works: it writes from approved sources, produces a changeset for review, and publishes only what a person approves. Running one job at a time, it's stable. At three jobs, the process died.

The choice was a bigger server or a slower queue. I chose slower. Content Ops runs one project at a time now, and it's live in production at version 5.12 with 839 TypeScript tests and 57 Python tests passing.

## The lesson

Parallelism is a budget decision, not a default. You don't get to treat it as free speed and hope the infrastructure scales invisibly. You cap it, you tier the work, and you checkpoint early so a killed job doesn't lose everything it wrote.

The unattended run works the same way. You don't earn it by trusting the agent more. You earn it by building the gate that says no, first.

I ran a genuinely unattended overnight session once, on a different project — an on-device interactive fiction engine that's parked now. The session spanned an 11.4-hour gap between one evening commit and a cluster of four morning commits. In that gap: a presence system that took the engine's continuity score from 3 out of 10 to 10 out of 10, a fix to how the engine tracks attention, and a recall system surfacing the right story excerpts when the model needs them.

Before any of those four commits could land, the same run re-ran the project's two hardest zero-violation gates: zero knowledge-isolation leaks across eighteen scenarios, and zero locked-development violations checked under direct pressure in both directions. What existed before that night: a 3,020-line requirements document split into nine gated phases, a 38-entry numbered decision log, nineteen distinct scored evaluations with numeric thresholds, and a replay mode that reruns expensive checks against recorded model responses without a fresh GPU pass.

Nothing shipped because the agent got smarter while I slept. It shipped because I'd already built the thing that would have stopped it if it hadn't held up.

## What another builder can apply

If you're running agent work in parallel — multiple subagents, multiple drafting jobs, multiple anything pulling from one pool — treat it as a budget question first. Ask: what's shared, what's the cap, and what happens when the pool empties? Then set a concurrency limit that keeps every job inside the budget, even if that limit is one.

If you want unattended runs, build the verification layer before the run, not after. Write the tests, the gates, the thresholds. Make the system capable of refusing a bad result while you're still watching. Then walk away.

Parallelism compresses cost when the infrastructure already handles contention. Without that infrastructure, it compresses your budget into whatever time it takes for the fastest agents to empty the pool. Cap it, checkpoint it, and let the work finish instead of racing itself to a kill signal.