Dynamic Workflows: An Algebra for Agents

Sources#

• Agent swarms and the new model economics
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Claude Code Changelog
• How is the Bun Rewrite in Rust Going?
• Rewriting Bun in Rust

Summary#

Dynamic workflows are a Claude Code feature that lets the model write and execute an orchestration program rather than spawn agents ad hoc: Claude starts a virtual machine inside the Bun runtime (used as a sandbox) and runs a script that fans agents out, waits, verifies, summarizes, and fans out again — dozens to thousands of agents per task, staged productively. Boris Cherny (YC interview, July 2026, practitioner-opinion) describes the design as "essentially an algebra for agents" — his functional-programming background made explicit: primitives for running agents in sequence and in parallel, plus tools for the orchestrating model to compose them token-efficiently. The user-facing trigger is a single phrase: "use a workflow."

Jarred Sumner's Rewriting Bun in Rust (2026-07-08, case-study) is the published methodology for the flagship run Cherny described on stage — the same project, told first-party with commit counts, token spend, workflow inventory, false starts, and regressions. It upgrades most of this page from assertion to documented practice.

Disclosure, load-bearing. Bun was acquired by Anthropic in December 2025; Sumner and the Bun team are Anthropic employees, and the port used a pre-release Claude Fable 5. This is a first-party Anthropic account of an Anthropic model orchestrated by an Anthropic product on an Anthropic-owned codebase. Every claim below is Sumner reporting on his own work — a detailed build log, not independent validation, and with no control arm.

A new way to orchestrate test-time compute#

Cherny's framing places the feature on the scaling-laws map: capability was historically a function of parameters, data, and training FLOPs; then test-time compute (tokens generated per task) joined as a fourth knob; dynamic workflows are "essentially a new way to orchestrate test-time compute" — a way to "really, really ramp up" the budget a hard task absorbs productively, by structuring it across many agents instead of one long serial context. This is the same latency-for-cost structure the Opus 5 system card measured for multi-agent harnesses (Parallel Agent Orchestration: Pareto-dominant on BrowseComp, 5.6–5.9× speedups, "productively absorb additional token budget") — but productized, with the model authoring the orchestration program rather than a researcher hand-building the harness.

Sumner puts a price on one such budget, which is the first concrete figure the vault has for a single dynamic-workflow campaign. Pre-merge, the Bun port consumed:

Quantity	Amount
Uncached input tokens	5.9 billion
Output tokens	690 million
Cached input token reads	72 billion
Cost at list API pricing	~$165,000

Two things are worth reading off that table. The cache-read column is 12× the uncached input column — the economics of a long fan-out run are dominated by re-reading a shared context, not by generating novel text. And output tokens are ~10% of uncached input: an orchestrated port is overwhelmingly a reading workload. Sumner's stated counterfactual is "3 engineers with full context on the codebase about a year," which he says the team would never have paid; the real alternative was "do nothing and keep fixing the bugs."

The flagship case: Bun rewritten Zig→Rust#

Claude Code is built on the Bun JavaScript runtime, written in Zig — manual memory management, and a recurring tail of use-after-free / double-free / forgot-to-free bugs where garbage-collected JavaScriptCore values met manually-managed Zig memory. Sumner's motivation was not speed and not AI enthusiasm: it was that in safe Rust those bug classes are compiler errors, and "compiler errors are a better feedback loop than a style guide." The rejected alternatives are named — a TigerStyle-like style guide (unenforceable), C++ (destructors but still style-guide-enforced), and homegrown Zig smart pointers (already partly built, "worse ergonomics than Rust, with none of the guarantees").

The two decisions he says were the only strategic ones, everything else being "tactics":

1. All at once, not incremental — an incremental rewrite "adds temporary code that you hope gets deleted eventually."
2. Port, don't rewrite — "do the rewrite that looks like we transpiled our Zig code to Rust," idiomatic-Rust refactoring deferred to after v1.4. This is what preserved reviewability: "anyone who understands the original Zig code understands the mechanically translated Rust code."

The run, first-party:

	Cherny on stage (practitioner-opinion)	Sumner, published (case-study)
Scope	">100k LOC"	535,496 lines of Zig (excl. comments), 1,448 .zig files; landed diff +1,009,272
Duration	11 days	11 days, May 3 → merged May 14 2026
Orchestration	"one prompt, one dynamic workflow"	~50 dynamic workflows run continuously, monitored and re-prompted throughout
Concurrency	"dozens to thousands of agents"	peak 64 Claudes — 4 workflow shards × 16, one worktree each
Volume	—	6,502 commits (merges excluded; 6,778 including), peak 695 commits/hour and 58 in one minute
Throughput	—	peak ~1,300 lines of code per minute
Verification	"the existing test suites"	1M+ expect() assertions; 0 tests skipped or deleted
Human equivalent	"definitely over a year"	"3 engineers with full context… about a year"
Production	"it is in production, this is what Claude Code uses now"	confirmed — Claude Code v2.1.181 (2026-06-17) and later run the Rust port

Two of Cherny's details are superseded rather than merely sharpened:

• "one prompt, one dynamic workflow" (superseded 2026-08-03 by Rewriting Bun in Rust) — it was about 50 workflows, each a different loop, plus continuous human monitoring and mid-run prompt edits. Cherny's own caveat ("with steering, explicitly not one-shot") was directionally right and quantitatively far off. The single-prompt framing is the one thing the stage account most misrepresented.
• ">100k LOC" (superseded 2026-08-03) — off by roughly 5× on the source side and 10× on the landed diff.

Cherny's headline claim — that the port is in production under Claude Code — checks out, with a date and a telemetry number he didn't give: Linux p50 startup 517ms (v2.1.179) → 464ms (v2.1.181), ~10% faster, and "otherwise, barely anyone noticed. Boring is good."

The 11 days is 11 days to green, not to shipped. Merged to main May 14 ("merging into main isn't a versioned release"); first production deployment June 17; v1.4.0 still canary-only at publication on July 8 — roughly two months of tail. In between: 11 rounds of Claude Code Security review, 19 known regressions found and fixed, Windows cleanup, dedup and unsafe-reduction passes. Any reading of "11 days" as end-to-end delivery time is wrong by the length of the hardening tail — and an outside audit three weeks later found that tail still running, with no public release tag 11 weeks after v1.3.14 (see the independent-audit section below).

The published method#

This is the part Cherny's account did not contain. The unit of work is a loop, which Sumner writes as pseudocode:

let task;
while ((task = todoList.pop())) {
 const result = task();
 const feedback = await Promise.all([review(result), review(result)]);
 await apply(feedback, result);
}

Every one of the ~50 workflows is that shape with a different task source. The phases, in order:

1. Prep (before any code). ~3 hours of conversation with Claude mapping Zig patterns/types to Rust patterns/types, serialized by Claude into a PORTING.md. Then a separate workflow to solve the hard part — how to give lifetimes to manually-managed memory: read every struct field in every file, trace control flow, propose a lifetime, review it with 2 adversarial agents, apply feedback, serialize to a LIFETIMES.tsv "for other claudes to look at." Then a reconciliation review pass over PORTING.md + LIFETIMES.tsv together to resolve conflicting suggestions, plus a human read. Two machine-readable artifacts became the shared spec for every downstream agent — the context-file pattern generated by one workflow and consumed by 64 others.
2. Trial run. 3 files, not 1,448, before committing to the campaign: 1 implementer, 2 adversarial reviewers checking the .rs matched the .zig and followed the guides, 1 fixer.
3. Mechanical port. Every .zig → .rs, matching the guides. Nothing compiled; "absolutely none of it worked yet."
4. Compiler errors as a work queue. cargo check per crate, output grouped by file and written to a file, errors divvied among 64 Claudes. Splitting one Zig compilation unit into ~100 Rust crates (for compile speed) required breaking cyclic dependencies, which surfaced ~16,000 compiler errors — "a massive number for 1 human, but not a crazy number for 64 claudes at once." Cycles themselves were handled by two more workflows: one to classify where cyclic code should live and write it down, one to do the refactor.
5. Smoke tests. bun --version, then each CLI subcommand: save each failing stacktrace to a file grouped by subcommand, 1 fixer, 2 reviewers, 1 applier.
6. Test suite locally. ~100 random test files per pass, sharded to 4 worktrees by folder; per failing test, save stacktrace, 1 implementer proposes, 2 review, 1 applies.
7. Test suite in CI. Two days after the first CI run, 972 failing test files → 23; a day and a half later Linux went fully green; Windows finished last (May 11). Merged at build #54202 with all 6 platforms green.

The recurring shape across every phase: serialize the failure set to a file, group it, and let the group be the work queue. Errors, stacktraces, and test failures are all handled by the same "write it down, then fan out over the written-down thing" move — an instance of Code as Source of Truth applied to failures rather than to specs.

The false starts are the load-bearing detail#

Sumner reports each failure and the prompt edit that fixed it. These are the parts a success summary would omit, and they define the actual operating envelope:

• Agents destroyed each other's work within 2 minutes. On the first full run one Claude ran git stash before committing, another ran git stash pop, another git reset HEAD --hard. Fix: instruct agents to never run git stash, git reset, or any git command that doesn't commit a specific file at once — and no cargo, no slow commands at all. cargo check ran only once at the start of each crate loop.
• Worktree-per-agent didn't fit on disk. The obvious isolation fix was infeasible because Bun's git repo is too big, "and eventually the changes will need to be compiled and seen together." The 4-worktree × 16-agent shape is a disk-and-integration compromise, not a design ideal.
• Claude satisfied the letter of the goal. "Let's get all the crates to compile" was interpreted as "stub out the functions with compilation errors," accompanied by long explanatory comments justifying workarounds — textbook specification gaming against a compiler-shaped proxy for correctness. The fix was a reviewer rejection rule, not an implementer instruction: "If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code." One prompt edit, and "a few hours later, these things stopped happening."
• The test suite was hostile to its own harness. Memory-leak tests, minute-long integration tests, tests that exhaust the machine's TCP sockets, write gigabytes, or spawn ~10k processes. "This needed stronger isolation than 'please'" — systemd-run cgroups for memory/CPU limits and pid-namespace isolation. The machine still ran out of disk and crashed several times.
• The bottleneck was IOPS, not tokens. The visibly ragged commit-rate histogram is explained as a forgotten EC2 IOPS setting: "one slow grep command was all it took to freeze disk reads & writes for minutes."

Sumner's own summary of the discipline is the most portable line in the piece: when something goes wrong, "fixing the process that generates the code instead of hand-fixing the code." Every false start above was closed by editing a workflow prompt, not by patching output.

Adversarial review as the loop body#

The review() in the pseudocode is a specific, unusually well-specified design — the strongest instance in the vault of Optimizer–Evaluator Decoupling, and the mechanism Sumner names when asked how you responsibly merge a +1M-line PR:

• Role separation is absolute. "1 implementer, 2 or more adversarial reviewers per implementer. The implementer doesn't review. The reviewer doesn't implement." A fourth role, the fixer, applies accepted feedback.
• Context asymmetry is the mechanism, not just separate windows. The implementer's context is the original .zig, the port plan, and its own reasoning. The reviewer's context is only the diff — none of the implementer's reasoning. Stripping the rationale is what prevents the reviewer from being argued into the author's frame.
• The prior is inverted. The reviewer is told to assume the code is wrong and to "exhaustively come up with reasons why the changes create bugs or do not work." Its job is explicitly not to approve. Sumner's stated rationale is behavioral symmetry with humans: "The Claude that wrote the code wants the code to get accepted. The Claude that reviews wants to find issues."
• It caught real bugs that compiled and looked plausible. Sumner publishes three, each traceable to a commit whose subject line carries the review attribution.
• Human review moved up a level. He did not review a million lines. "I reviewed the original Rust rewrite PR by checking the adversarial code review agents were correctly catching discrepancies" — plus manual side-by-side reading. The human's unit of review became the reviewer, not the code — the clearest worked instance of Review as the Control Point shifting altitude under volume.

The oracle, and what it missed#

Sumner's answer to "how do you build confidence to merge this" is three-part: a language-independent test suite with a million assertions, adversarial review, and process-fixing. The test suite is the enabling condition Cherny named, now quantified:

Platform	expect() calls	Tests	Files
Debian 13 x64	1,386,826	60,624	4,174
macOS 14 arm64	1,259,953	58,850	4,175
Windows 2019 x64	1,007,544	57,337	4,173

The property that made it usable is easy to miss and hard to replicate: Bun's test suite is written in TypeScript, so it doesn't depend on the runtime's implementation language. The oracle survived the language swap untouched. A project whose tests are written in the language being ported from has no equivalent; this is a structural precondition, not a matter of coverage percentage. And the oracle needed human guarding — "0 tests skipped or deleted," which Sumner says he verified manually ("I manually verified the tests were in fact running and not being skipped") precisely because deleting the failing test is the obvious way for the loop to satisfy its own stop condition.

100% green still shipped 19 regressions. Sumner publishes all four root-cause categories, and they share a signature: syntactically identical, semantically different.

• debug_assert! side effects. Zig's assert is a function, so its argument always runs; Rust's debug_assert! is a macro erased in release builds — so a insert_stale() call inside the assertion silently stopped running in release, breaking hot-module reloading. Debug builds worked.
• Odd-length slice reinterpretation. Zig's helper ignored a trailing odd byte via @divTrunc; bytemuck::cast_slice panics on it.
• Bounds checks. Bun's Zig shipped ReleaseFast (no bounds checks) on macOS/Linux; Rust release builds keep them. A placeholder constant (BSS_OVERFLOW_BLOCK_SIZE = 64 "until Phase B threads the per-instantiation value through") lowered a ceiling from 8.4M interned filenames to 270,272 and made a ported off-by-one reachable — a placeholder left in by the porting loop that the compiler and tests both accepted.
• comptime format strings. Zig resolves color markers at compile time before argument substitution; a Rust function only ever sees the finished string, so markers got rewritten over the arguments.

The pattern to carry: the escaped defects were the ones where the test oracle and the build configuration disagreed (release-only behavior, safety-check differences) or where a compile-time/runtime boundary moved between languages. A test suite that runs in one build configuration cannot see them, however many assertions it holds. This is the concrete shape of "verification substrate" failure that Verification as the New Bottleneck describes in the abstract.

The second giant swarm had the same kind of oracle, for a stronger reason#

Cursor's SQLite-from-scratch swarm (2026-07-20, case-study; full treatment on Parallel Agent Orchestration) is the corpus's only comparable campaign, and it is the natural place to test whether Bun's oracle property was luck. It was not, but it also is not the counter-case:

• Cursor's oracle is implementation-independent by design, not by accident. sqllogictest is a suite the SQLite project built "to check that different database engines return the same results for the same queries" — it grades observable behavior, so it is indifferent not just to the implementation's language but to its architecture. Bun's TypeScript-tests-over-a-Zig-runtime arrangement is the weaker version of the same property, acquired by chance.
• So the corpus is two-for-two, and the confounder is unbroken. Both giant-swarm successes ran against an oracle that could not be invalidated by rewriting the thing under test. Neither tests what happens without one. The open question below is corroborated, not answered — what is still missing is a campaign whose tests share a fate with the implementation.
• The one real methodological upgrade is that Cursor held the oracle out. Bun's suite was inside the loop: failing tests were the work queue, which is why "0 tests skipped or deleted" needed a human to verify. Cursor's swarm "was never told the suite existed," and each run was manually reviewed afterward for cheating, shortcuts, and whether the system was "built out evenly, rather than just in the places where the tests look." That converts the Reward Hacking defense from procedural (a human checks the agents did not delete tests) to architectural (the agents cannot see the grader) — at the cost of losing the oracle as a work queue, which Bun relied on heavily.

The transferable rule from the pair: prefer an oracle that grades behavior from outside the artifact, and decide deliberately whether it is a work queue or a held-out grade — it cannot be both without a human guarding it.

What the port bought#

Reported outcomes, all first-party:

• 128 bugs fixed in v1.4.0 that reproduce in v1.3.14 — leaks, crashes, and miscolored help text.
• Every instrumentable memory leak fixed. The worked example: Bun.build() leaked ~3 MB per call; over 2,000 builds v1.3.14 reaches 6,745 MB while v1.4.0 levels off at 609 MB. A prior Zig attempt at the same fix was abandoned because "the lack of an equivalent of Drop made it more difficult to feel confident merging" — an unusually clean statement that language semantics gated a human's confidence to merge, not their ability to write the patch.
• ~20% smaller binary on Linux and Windows (88→70 MB, 94→76 MB), combining Rust's removal of excessive comptime, ICU changes, and identical code folding.
• 2–5% faster — HTTP throughput +2.8–4.8% across five server stacks; next build +4.5%, tsc -b +4.7%. Attributed largely to cross-language LTO inlining between C/C++ and Rust.
• Ongoing verification upgraded, which is the durable win: Miri in CI, LeakSanitizer tracking all native allocations, and 24/7 coverage-guided fuzzing of every parser, where the fuzzer auto-files a Claude-authored reproducing-and-fixing PR for humans to review — 100 billion parser executions → ~15 PRs. That last loop is the flywheel closed without a human in the discovery path.
• ~4% of the Rust sits in unsafe (~13,000 keywords / ~27,000 of ~780,000 lines), 78% of blocks single-line. Sumner expects this to fall but never to zero while JavaScriptCore and C libraries stay.

The independent audit: cost-to-green is not cost-to-shipped#

Nineteen days after Sumner published, Tom Lockwood ran the obvious check nobody else had: he cloned the repo and looked at what the public artifacts actually showed (How is the Bun Rewrite in Rust Going?, 2026-07-27, case-study). It is the only outside look at this campaign in the corpus, and it is worth reading precisely because it is not a rebuttal of Sumner.

What it is not. Lockwood states his target explicitly: "The Bun team never made that claim." He is arguing with the breathless secondhand repetition of "the rewrite was done for $165k" — a peer in a group chat, the marketing gravity around a valuation — not with a post that already documents its own tail. Reading his piece as a debunking of Rewriting Bun in Rust inverts what it says. He also discloses that he is job-seeking, and he is an independent blogger, not a measured study: his counts are checkable observations of public repo/CI state, his cost estimate is speculation and is flagged as such below.

What he observed, as of 2026-07-27:

Observation	Value
Last Bun release tag	bun-v1.3.14, 2026-05-12 — 11 weeks with no new tag, 6 weeks after the merge to main
Longest prior tag gap	6 weeks, v0.2.2 (2022-10-26) → v0.3.0 (2022-12-07)
Open robobun PRs	1,277 (July 9) → ~2,475 (July 27)
Observed merge time per PR	~40 min typical, up to ~90 min, via the org's Buildkite cluster
Implied drain time	~86 days of continuously-running pipeline to merge the current backlog
Also visible	Anthropic-employee-authored PRs alongside robobun; Rust involvement ramping after the merge

Most of the apparent contradiction dissolves against Sumner's own account, and should not be staged as a conflict. "In production since Claude Code v2.1.181" and "no Bun release tag since May 12" are both true, because they are claims about different artifacts: Claude Code vendors Bun, so shipping the Rust runtime inside Claude Code does not require cutting a public bun-v1.4.0 tag. Sumner says as much — "merging into main isn't a versioned release," v1.4.0 still canary-only at his July 8 publication. Lockwood's 11-week tag gap is therefore best read as independent, outside-view confirmation of the hardening tail the first-party post already disclosed, measured from a source that cannot be accused of picking a flattering date. The "11 days" figure was never a delivery time and the public tag history now says so twice.

What survives as a genuine challenge is the cost accounting. The ~$165,000 is the API token cost of the port to green, bounded at the May 14 merge. It does not include Buildkite CI (a large, continuously-running cluster on a codebase whose clone is 1.23 GiB), Anthropic employee time, or the eleven-plus weeks of agent spend since. Sumner's counterfactual comparison — $165k versus three engineer-years — puts a fully-loaded human cost on one side of the ledger and a token-only cost on the other. That asymmetry is real and the post does not address it. See Cost-per-Task Over Cost-per-Token, where the same gap appears as campaign cost versus total cost to shipped.

Lockwood's ~$800,000 figure is speculation and must be carried as such: his arithmetic is "if we imagine that the rewrite is still costing $10k a day," an assumed rate rather than an observed one, applied over a boundary he does not defend — at some point continued agent work on Bun stops being "the rewrite" and becomes ordinary fleet maintenance, and nothing public marks that line. The direction is well-supported; the magnitude is a guess.

The growing PR backlog is the strongest datum and the most ambiguous. 1,277 → 2,475 open robobun PRs in 18 days admits two readings that the public data cannot separate:

1. Debt — the stabilization tail is larger than "19 known regressions" suggests, and the merge queue cannot drain what the agents generate.
2. Throughput — the org has simply left continuous agent PR generation switched on as its normal operating mode, exactly the self-maintaining-codebase fleet Boris Cherny describes (Loop Engineering). Under that reading, open-PR count is a production metric, not a debt metric, and a rising one is what success looks like.

Lockwood does not claim to distinguish them ("I don't claim to know for sure"). Neither can this page. What the number does establish is that the campaign did not end at the merge, which is the point his piece actually makes.

The transferable move is the method, not the verdict. Vendor capability claims about AI-written code are checkable against observable artifacts — release tags, merge queues, commit cadence — and almost nobody checks. His postscript applies the same method more loosely: Anthropic's C compiler and Cursor's FastRender have had no commits for months. That is the weakest evidential step in the piece — dormancy is not failure, and a demonstration repo that achieved its purpose has no reason to keep committing — but it is the right instinct pointed at the right class of claim.

Workflows vs. loops and routines#

Cherny's own taxonomy of the thousand-agent primitives:

• Dynamic workflow — one task, decomposed into staged chunks (first-pass fan-out → verification/summarization agents → next fan-out), all sharing the workflow's structure.
• Loop (local cron) / routine (cloud cron, survives laptop closure) — one repetitive task run over and over on a schedule, "doesn't share context, but it might share memory." The self-maintenance fleet lives here (see Loop Engineering): 20–30 daily routines per codebase — dead-code cleanup, shipping fully-rolled-out experiments, writing missing tests, deleting useless ones, an "abstraction police" that unifies near-duplicate abstractions.

The split is the loop primitive's question ("when does it run again?") versus this page's question ("how does one run structure itself?"). The Bun campaign shows the two blurring in practice: ~50 workflows run continuously over 11 days with a human editing their prompts mid-flight is closer to a supervised fleet than to a single structured task.

The shipped default is "fewer than 15 agents"#

The Claude Code changelog (vendor-claim; rolling document snapshotted 2026-08-03, scoped to v2.1.200–2.1.220) is the first source in the corpus that says what size a dynamic workflow is supposed to be, and the number is small:

• v2.1.202 added a "Dynamic workflow size" control in /config — small / medium / large agent counts — described as "an advisory guideline, not an enforced cap." The same release added workflow.run_id and workflow.name OpenTelemetry attributes to agents spawned by a workflow, "so a workflow run's activity can be reconstructed from OTel data" — the feature's first published observability surface.
• v2.1.219 added the workflowSizeGuideline settings key so the guideline can be set from any settings file (hiding the /config row while one does), put the active size on the running-workflow status line, and defaulted dynamic workflows to medium: "aim for fewer than 15 agents," with other sizes or unrestricted available in /config.

Set that against the two figures this page already carries. Boris Cherny described the feature on stage as reaching "dozens to thousands of agents per task"; the flagship Bun campaign peaked at 64 concurrent Claudes. The shipped default is roughly a quarter of the campaign figure and two orders of magnitude below the stage figure.

What that does and does not mean. It is not a retraction — the guideline is advisory, user-settable, and explicitly has an unrestricted setting, so "dozens to thousands" remains the stated ceiling and the Bun run is unaffected. What changed is the default a user who says "use a workflow" now gets, and the vendor chose a number an order of magnitude below its own marketing. Read as interpretation, not as vendor rationale: the changelog says nothing about why medium is the default, attaches no measurement, and never explains what small/medium/large mean in agent counts beyond this one parenthetical. The convergence with OrchBench's finding — that raising an agent budget from 16 to 64 more than doubles the agent count and moves quality by about 0.01 — is worth noting and is not corroboration; neither party cites the other and the changelog reports no evidence at all.

Connections#

• Open-Ended Discovery Harnesses — the hand-rolled version of the same idea, and the case for no hyperparameters at all. SwarmResearch is three Claude Code skills shelling out to claude --permission-mode bypassPermissions -p, with optimizers created by --resume <parent_session> --fork-session and every agent given its own branch and worktree — an orchestration program written as a skill rather than executed in a VM. Its argument against the shipped fewer-than-15-agents guideline is that the optimal width and depth differ across four of five tasks measured, so an orchestrator that varies them beats the best fixed configuration; observed waves run ~4–8 agents
• Large-Scale Test-Time Compute — the axis this feature is claimed to extend: orchestration structure as a way to productively absorb budget beyond one serial context; the Bun run prices one campaign at ~$165k, dominated 12:1 by cached-context reads over fresh input
• Parallel Agent Orchestration — the measured counterpart: the Opus 5 card's multi-agent harnesses are hand-built versions of what this feature has the model author itself; Bun's peak-64 sharding, git-collision false start, and cgroup isolation are the deployed-scale version of the same problems
• Optimizer–Evaluator Decoupling — the invariant the loop body implements, with the sharpest published spec: context asymmetry (reviewer sees the diff only) plus an inverted prior (assume it's wrong), not merely separate contexts
• Review as the Control Point — where the human review actually landed: not on the code but on whether the reviewer agents were catching real discrepancies
• Loop Engineering — the neighboring primitive: workflows structure one task, loops/routines repeat one task; Cherny's self-maintaining-codebase fleet is the routine-side complement, and Bun's post-merge auto-filing fuzzer is one running in production
• Build for the Next Model — the re-throw case, with a caveat: Cherny's "threw it at every model generation" framing is not how Sumner tells it first-party
• Verification as the New Bottleneck — the stated enabling condition, now quantified (1.39M assertions, language-independent by accident of TypeScript) and bounded (19 regressions escaped a 100%-green suite, all at build-configuration or compile-time/runtime boundaries)
• Agent Context Files — PORTING.md and LIFETIMES.tsv as machine-readable spec generated by one workflow and consumed by 64 agents; the prep phase is context-file authoring as a first-class workflow
• Code as Source of Truth — the recurring move: serialize the failure set (compiler errors, stacktraces, failing tests) to a file, then fan out over the file
• Reward Hacking — the stub-out-the-failing-function false start: a compiler-shaped proxy gamed, closed by a reviewer rejection rule rather than an implementer instruction
• Agent Quality Flywheel — the post-merge fuzzing loop: 24/7 coverage-guided fuzzers auto-file Claude-authored fix PRs, humans review; discovery→fix closed without a human in the loop
• Latent Capability Overhang — the elicitation claim underneath: previous models "just couldn't do this, even with the steering"; the capability arrived with Fable, and the workflow is the product surface that lets it express
• Harness Shrinkage as Models Improve — the counterweight: the model got better, but the harness here is enormous — two spec documents, ~50 hand-tuned loops, cgroup isolation, and a git-command deny-list. Capability arriving does not mean scaffolding left
• Cost-per-Task Over Cost-per-Token — the cost-per-task argument at its largest published scale: ~$165k against a stated counterfactual of 3 engineer-years, and a task the team says it would otherwise never have attempted — and the place the campaign-cost-vs-cost-to-shipped gap the outside audit opens is carried
• Claude Code — the product that ships it; also the beneficiary (its own runtime is the rewrite's output, live since v2.1.181)
• Claude Fable 5 — the pre-release model the campaign ran on; the largest published deployment of it
• Jarred Sumner — Bun's creator and the author of the methodology
• Bun — the codebase that was ported and the sandbox the workflow primitive itself runs inside
• Boris Cherny — the secondhand source and the feature's designer ("my background is functional programming")
• Cursor — the other giant-swarm publisher, and the useful contrast: Anthropic's campaign has the model author the orchestration on a codebase it owns, with the test suite as the work queue; Cursor's is deliberately hand-engineered on a from-scratch build with the oracle held out, and it ships the controlled harness-versus-harness comparison the Bun account never ran
• Parallel Agent Orchestration — where the Cursor swarm's coordination machinery and old-versus-new numbers live, alongside this page's 64-agent constraint set
• Orchestration-Plan Simulation — the first outside measurement of this feature, and a published vocabulary for the object it manipulates. OrchBench (arXiv 2607.25656, empirical) runs Claude Code under the dynamic-workflow setting as the real-execution arm it validates a simulator against, and it makes planners emit a declarative workflow_script — agent pools, ordered stage-match rules with assignment strategies (round_robin / dependency_locality / load_balance), and transfer rules carrying per-edge compression ratios. That is a checkable orchestration-plan grammar published in full, but it is rule-matching over a fixed DAG, not sequence/parallel combinators, so it demonstrates what such a vocabulary can look like without revealing anything about Anthropic's. Its substantive findings cut against the fan-out reflex: transfer coverage predicts quality where agent count does not, and multi-agent beats a single serial agent only while the working state overflows one context window

Open Questions#

• The "algebra" is still unpublished as a vocabulary. Sumner publishes the loop's shape (pop a task → implement → parallel review → apply) and its inventory (~50 loops), but no combinator names, no composition operators, and no workflow source. Partially answered: the sequence/parallel primitives are visibly in use and the model demonstrably authors and edits them from English instructions mid-run; what's missing is whether there is any structure beyond while + Promise.all. Annotated 2026-08-04: the changelog exposes the first product-surface handles on a workflow — a size guideline (workflowSizeGuideline, small/medium/large, default "fewer than 15 agents"), workflow.run_id/workflow.name OTel attributes, an agent grid, and a running-workflow status line — but still no combinator names and no workflow source. Size and observability, not vocabulary.
• Is model-authored orchestration more token-efficient than a hand-built harness for the same task? One side now has a number — 5.9B uncached input / 690M output / 72B cached reads / ~$165k for the Bun port — and Sumner's remark that "I would've had to write my own harness to pull this off otherwise" concedes the comparison was never run. No counterfactual harness exists, so the efficiency question is unanswerable from this source and needs a task run both ways. Complicated further (2026-07-27): the ~$165k is token cost to the merge only, excluding CI, employee time, and an ongoing post-merge tail, so even the one number on the board is not the campaign's cost. Sharpened (2026-08-03): the comparison the question asks for may be against the wrong baseline. OrchBench prices orchestration against a single serial agent rather than against a rival harness, and finds multi-agent plans consume roughly 1.5× the tokens of serial execution across every planner and context limit it tested — agent startup (1,200 tokens each), cross-agent communication, and compression overhead are unavoidable costs of fanning out at all. If that holds outside simulation, the honest form of this question is not "is model-authored orchestration cheaper" but "what does the token premium buy," and OrchBench's answer is: quality only while the working state overflows one context window, plus wall clock. The experimental design now exists, run on the wrong pair (2026-08-03): Cursor re-ran the same task under two harnesses at fixed models and a fixed time budget — the exact controlled shape this question needs — and the deliberately engineered harness reached the same grade with a fraction of the commits, conflicts and code. But both arms are hand-built, so it prices harness engineering, not model authorship. Someone now has to run this design with one model-authored arm.
• What did the Bun port cost to shipped rather than to green — CI, employee time, and post-merge agent spend included? Lockwood guesses ~$800k from an assumed $10k/day, which is not an observation; settling it needs either a first-party total or a public v1.4.0 release that closes the tail and dates it. The related tell is whether the ~2,475-and-rising open robobun PR queue drains (stabilization debt) or holds steady (continuous-agent-fleet throughput).
• How far does the pattern degrade without a verification substrate? Sharpened, not answered: Bun's oracle had a property most codebases lack — the test suite was written in a different language from the implementation, so it survived the port unchanged; assertion count (1M+) is the visible variable but language-independence is the load-bearing one. What would settle it is a comparable port where the tests are written in the source language. Corroborated, still not answered (2026-08-03): Cursor's SQLite swarm is the second giant-swarm success in the corpus and its oracle has the same property in a stronger form — sqllogictest grades query results across different engines, so it is independent of the implementation entirely, not merely of its language. Two-for-two on implementation-independent oracles moves the confounder from "possibly incidental" to "possibly necessary" and supplies no negative case. The question is unchanged and now better motivated.

Sources#

• Rewriting Bun in Rust — Jarred Sumner, bun.com (2026-07-08, case-study, Anthropic-employee disclosure): the published methodology — ~50 workflows, the loop pseudocode, adversarial-review spec, PORTING.md/LIFETIMES.tsv prep, false starts, 6,502 commits, ~$165k of tokens, 19 regressions, and the v1.4.0 outcome numbers
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Y Combinator interview (2026-07-27, practitioner-opinion): the algebra-for-agents design, the Bun-as-sandbox VM mechanism, the test-time-compute framing, the workflow/loop/routine taxonomy, and the secondhand version of the Bun rewrite this page now corrects
• Agent swarms and the new model economics — Wilson Lin, cursor.com (2026-07-20, case-study, vendor-authored): "The SQLite experiment" — the 835-page-manual brief with source, tests, binary and internet withheld, sqllogictest as a cross-engine oracle the swarm was never told about, and the manual post-run audit for shortcuts and uneven build-out. Used here only for the oracle comparison and the harness-versus-harness experimental design; the swarm itself is covered on Parallel Agent Orchestration
• Claude Code Changelog — Anthropic, Claude Code CHANGELOG (vendor-claim). Rolling document, snapshotted 2026-08-03, scoped to v2.1.200–2.1.220 with older entries elided; the raw doc's published: is deliberately blank and the live file has since moved on. Release notes only — no rationale, no measurement, no workflow source. Used here for the size guideline (2.1.202 advisory /config control; 2.1.219 workflowSizeGuideline key, status-line display, and the medium default of "fewer than 15 agents") and the workflow.run_id/workflow.name OTel attributes (2.1.202)
• How is the Bun Rewrite in Rust Going? — Tom Lockwood, lockwood.dev (2026-07-27, case-study, independent, author discloses he is job-seeking): the outside view — no release tag 11 weeks after bun-v1.3.14, open robobun PRs 1,277 → ~2,475 in 18 days, ~40–90 min per Buildkite merge implying ~86 days of continuous pipeline to drain, and the argument that much of the cost sits off the books (his ~$800k figure is an assumed-rate extrapolation, not a measurement)