Loading today’s stories
Build1 distinct publisher3 min readPublished
A 45-run experiment held a coordinator's context under 5,000 tokens, but the protocol obliged it to spawn at least two children on every task, so the average tax prices unconditional forking rather than orchestration itself.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The spawn path is where the money goes. A coordinator calls `spawnSubsession(role, brief)` with a versioned brief document; the child starts from that brief with no access to the parent transcript, logs every tool call to an append-only checkpoint journal, returns a report against an enforced JSON schema, and writes a succession letter when it terminates [5]. The coordinator merges the report and never the transcript [5]. That invariant is what holds the coordinator under its context ceiling [8]. The bill for it is itemized as spawn latency, report serialization, brief-plus-report-plus-synthesis tokens, and duplicated work when children re-navigate context the parent had already read [6].
The 52% token premium and the 5,000-token ceiling are quoted in different currencies [7][8]. One is spend; the other is peak occupancy. Inline runs peaked above 15,000 tokens on multi-file edits, so the orchestrated arm bought roughly 10,000 tokens of headroom, and at the 2,000-plus tokens a single spawn costs in brief and report, that headroom prices out at about five spawns [16][10]. If you were nowhere near a context limit, you paid cash for space you already had.
The success rate also fell slightly under orchestration [7], so cost per completed task rose by more than the headline 52%: the numerator went up while the denominator went down [18].
Resolution matters before anyone plans against the per-category figures. Forty-five runs spread across twenty tasks and two arms is about 1.1 runs per cell [17]. The audit attributes 5% of output variation to model sampling [11]. The 10-20% parallel speedup [9] is a direction, not a coefficient you can budget with.
For the 52% average to describe your system, your orchestrator would have to fork as unconditionally as this protocol required: delegate to at least two worker subsessions on every task, then synthesize their reports before answering [3]. Depth was capped at 2 [3], so nothing here prices what grandchildren cost when they re-navigate the same repository.
Sadeghizad writes that the difference comes down to plumbing rather than theory [15]. The plumbing sets the constant, but the split in the results sits in the workload: independent files and isolated test modules on one side [9], single-function debugging with repeated test-fix cycles on the other [10]. Two thousand tokens of paperwork to change three lines is the same plumbing that pays for itself across four parallel modules.
His framing is that every multi-agent design bets coordination overhead is cheaper than monolithic context bloat, and that nobody had published what the bet costs [14]. All 45 runs are out, failures included, with the rubric fixed in `RUBRIC.md` before any runs and full journals behind the audit [4][12]. That makes the experiment cheap to repeat, and repeating it is the useful part: run both arms against your own fixtures, because the constant you measure will be your runtime's, not his.
Ranked by verification strength, evidence, and original report placement.
Mohammad Fauzel Sadeghizad ran 45 controlled experiments across 20 programming tasks to measure the fork tax: the performance penalty paid when an agent workflow is split into subsessions instead of running inline.
The inline arm was a single autonomous session with the subsession toolset structurally stripped (canSpawn: false); the agent performed all code navigation, editing, script execution and verification within its own session.
The orchestrated arm was a supervisor session authorized to spawn children (canSpawn: true, depthCap: 2); under pre-registered protocol amendments the coordinator had to delegate work to at least two worker subsessions and synthesize their returned reports before delivering the final answer.
Both arms used the same model, temperature and system prompt structure, deterministic fixtures of 20 programming tasks with known correct outputs, and a pre-registered evaluation rubric (RUBRIC.md) fixed before any runs.
When a coordinator spawns a child, the runtime performs a role-typed spawn via spawnSubsession(role, brief) with a versioned brief; the child starts with the brief and no access to the parent transcript, every tool call and state transition is logged to an append-only checkpoint journal, the child must return a structured report against an enforced JSON schema, writes a succession letter on termination, and the coordinator receives only the report, not the full transcript.
The fork tax is the sum of spawn latency (session initialization, role validation), report serialization overhead, coordination token cost (brief plus report plus synthesis), and potential duplication when children re-navigate shared context.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 4, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Three manual interventions in a month, and every guard was working as designed1 distinct publisher
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
Separating moderation rejections moved one API gateway's success rate from 95.5% to 98.9%1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Careful design, thin sample, single hand
The discipline is real for a self-published benchmark: rubric fixed before any runs, fixtures with known correct outputs, failures published rather than dropped, checkpoint journals used to confirm coordinators actually delegated instead of trusting the arm label. The sample is where it thins out. 45 runs across 20 tasks and two arms is about one run per cell, and the audit itself concedes 5% run-to-run variance, so a subgroup finding like '10-20% faster' rests on single observations. Absent throughout: absolute token counts, the size of the success-rate drop, the model, the runtime, and the rubric and verification files themselves.
Nobody outside the experiment
No one but the author appears anywhere in this reporting. The runtime being measured is never named, no second team is shown running it, and there is no install, deployment or usage figure of any kind. The only observable event is the publication of the experiment, and adoption by anyone else remains unshown.
The average prices a mandate, not a choice
Sadeghizad calls the findings unambiguous and opens by asserting that nobody has published this cost. The protocol he ran, though, forced every coordinator to spawn at least two children on every task, including the ones where a three-line edit was the whole job. Read as 'unconditional forking costs about half again in tokens', the 52% holds. Read as 'orchestration costs 52%', it inherits a floor the experiment imposed on itself. The task-shape result, which is the part a reader can act on, gets less billing than the average that the mandate distorts.
Self-measured but still unflattering
The author is benchmarking the subsession machinery he built, on a platform where he is his own editor, citing an audit file from his own results directory as the independent check. The counterweight is which way the result points: it makes his architecture look expensive on most task shapes, and it volunteers two runs where the coordinator cheated by working inline. Publishing his own worst numbers points away from a promotional motive.
Mechanism firmer than magnitudes
How a spawn bills, and why short child sessions lose to inline editing, are the parts worth carrying away; they follow from the runtime contract regardless of sample size. The percentages deserve looser handling, given roughly one run per task-and-arm cell, a conceded 5% of sampling variance, a success-rate change reported only as slight, and no replication by anyone else. Treat 52% and 38% as the order of magnitude for one harness on one model.