fan-out & spawn

A Vinculum session runs one continuous conversation with a model, working through whatever it’s assigned one step at a time. Fan-out breaks that pattern on purpose: we split the batch into scoped pieces first, and spawn a worker for each piece, all running at the same time instead of one after another.

The orchestrating session (Vinculum calls it the colonel) keeps the reasoning: what the batch needs, how to divide it, what to do with each result as it comes back. Each worker, a grunt, gets exactly one piece: a directive, a boundary on what it can touch, and a model tier picked for that job specifically. The colonel plans and supervises; the grunt executes its slice and nothing past it.

Running a long batch through one continuous conversation charges the same rate for every step in it: the hard decisions and the mechanical ones both billed at whatever tier that one session runs on. Fan-out splits that rate in two. We run the colonel on the most capable tier, because deciding what to build and how to divide it needs that capability. A grunt runs on a cheaper, faster tier by default, because carrying out one already-scoped piece of work doesn’t.

That split holds regardless of how many workers are running. The colonel’s own reasoning cost stays close to flat whether it’s watching one worker or seven, because the job is still deciding once and reading results as they come in. What scales with headcount is the workers’ execution cost, priced at the cheap tier throughout.

A single session working a batch one task at a time pays for every task in series: task two waits on task one, task three waits on task two, and the wait gets billed the same as the work. Workers spawned in parallel skip that queue. Each one runs against its own slice from the moment it’s spawned and finishes when that slice is done, regardless of what’s happening in any other worker.

The colonel doesn’t wait on any single worker to keep working either. It checks results as they land, spawning more workers or closing out finished ones. A batch’s wall-clock time ends up tracking whichever piece takes longest to finish, however many other pieces already have.

One real batch shows the shape rather than argues for it. Seven workers ran at once against a single directive: five features shipped in fifteen minutes, including a full-stack change spanning 13 files and 35 tests, while two more workers kept running and a third piece of work sat queued behind them. Running the whole batch — the colonel’s oversight and every worker’s execution together — cost 42% of a single Pro-plan subscription’s spend (#860).

The colonel’s own cost barely moved between watching one worker and watching seven: one session, deciding once, then reading results as they land. Every worker’s execution cost scaled with headcount instead, but held to the cheapest model tier available. Cost in this batch tracked the amount of work, whatever the headcount running it.