16 parallel Claude agents wrote a 100k-line C compiler for $20k — the harness, not the compiler, is the takeaway

In early February, Anthropic Safeguards researcher Nicholas Carlini ran sixteen parallel Claude Opus 4.6 instances on a shared Git repository for two weeks and came away with a 100,000-line C compiler, written from scratch in Rust, that Anthropic says can build Linux 6.9 on x86, ARM, and RISC-V. The compiler is the novelty headline, and its claims deserve scrutiny; for anyone building long-running agent systems, the durable content is the harness he built to keep the agents working without an operator.

What shipped

Carlini's write-up describes roughly 2,000 Claude Code sessions over two weeks, costing "just under $20,000" in API tokens — 2 billion input and 140 million output tokens consumed by Opus 4.6. The resulting compiler, released the day before the post as the anthropics/claudes-c-compiler repository under CC0-1.0, is a gcc-compatible driver that reports itself as GCC 14.2.0 and targets x86-64, i686, AArch64, and RISC-V 64.

Anthropic's capability claims, all from the engineering post: the compiler "can build a bootable Linux 6.9 on x86, ARM, and RISC-V," compiles QEMU, FFmpeg, SQLite, PostgreSQL, and Redis, has "a 99% pass rate on most compiler test suites including the GCC torture test suite," and "can compile and run Doom" — in Carlini's words, "the developer's ultimate litmus test."

The repository README, itself almost entirely model-written, extends the list — 16 projects named outright plus "over 150 additional projects" — and claims its built-in assembler and linker produce ELF executables "without any external toolchain." Its one human-written paragraph is worth reading whole: it says 100% of the code and docs were written by Opus 4.6, with a human guiding only via test cases, and ends with the warning "I do not recommend you use this code! None of it has been validated for correctness."

The experiment sits at the top of a capability curve Carlini has tracked across the Claude 4 series: Opus 4.5 was the first model that could produce a functional compiler passing large test suites, but could not compile any real large project; the kernel-building bar was the Opus 4.6 stress test.

The harness

The mechanism is the actual news. Carlini calls his scaffold "bare-bones" and "a very early research prototype," but each piece is a lesson in supervising many agents:

• An infinite loop instead of a session. Each agent runs claude -p "$(cat AGENT_PROMPT.md)" inside a while true loop, so when a session finishes a task it immediately starts another. Carlini's reason: left to a single session, the model "will stop and wait for continued input—a question, a status update, or a request for clarification". The prompt tells Claude to work until its task is "perfect." (In one instance, Claude ran pkill -9 bash, killing its own loop.)
• Git as the coordination primitive, not an orchestrator. "I don't use an orchestration agent," Carlini writes. Each agent works in its own Docker container with a clone of a shared repo, claiming work by writing a lock file into current_tasks/, and "if two agents try to claim the same task, git's synchronization forces the second agent to pick a different one". Agents pull, merge each other's changes, and resolve merge conflicts themselves — frequently, by his account.
• A verifier, not an instruction set, keeps agents honest. "Claude will work autonomously to solve whatever problem I give it," he writes, "so it's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem." Most of his effort went into the test harness: concise output (errors must write ERROR with the reason on the same line so grep finds them), precomputed summary statistics, and a --fast mode that runs a 1% or 10% sample — deterministic per agent but random across VMs — to counter the models' "time blindness."
• An oracle to break identical-bug deadlock. When all 16 agents hit the same kernel bug and started overwriting each other's fixes, Carlini used GCC as an online known-good oracle: randomly compile most of the kernel with GCC and only a subset with Claude's compiler, then refine, followed by delta debugging to find file pairs that fail together but pass alone.
• Role specialization. Separate agents coalesced duplicate code, improved compiler performance, emitted more efficient output, critiqued the design as a Rust developer would, and maintained documentation.

Why it matters

For engineers running agent teams, three things are worth taking away.

First, the pattern is small and directly copyable: lock files in git, no orchestrator, an eternal loop, and a brutally simple test protocol. Carlini's own framing is that the approach "dramatically expands the scope of what's achievable with LLM agents"; the harness in the post is a bash loop, git, and one Docker container per agent — no orchestration framework.

Second, the failure modes are already visible at the 100k-line scale. Carlini closes the post noting the compiler "has nearly reached the limits of Opus's abilities" and that "new features and bugfixes frequently broke existing functionality" — which is why he built a CI pipeline near the end. Ars Technica reads the pattern as a practical ceiling, noting the model "hit this wall at around 100,000 lines". If you are planning swarm-built codebases, that is the number to plan around.

Third, it shifts where the human skill sits. As InfoQ's roundup of the debate put it, the primary skill becomes "the ability to design the automated testing rigs and feedback loops that allow sixteen parallel instances of a model to solve" the problem — matching Carlini's own conclusion that most of his effort went into the environment, not the compiler. A C compiler is also a near-ideal case for this: decades-old specification, comprehensive test suites, and a known-good reference compiler — advantages "most real-world software projects" do not have.

Caveats

Everything quantitative here is vendor-reported, and the vendor's own materials hedge. The README's project list is model-written; the human note warns the docs "may be wrong and make claims that are false." Anthropic's post concedes, among others:

• It lacks a 16-bit x86 backend, so booting Linux out of real mode calls out to GCC (x86-32 and x86-64 are the compiler's own; ARM and RISC-V need no help).
• Its assembler and linker were "the very last bits" Claude started automating and are "somewhat buggy" — the demo video was produced with GCC's assembler and linker. (On Hacker News, compiler engineer ndesaulniers quibbled the label: GCC itself shells out to GNU binutils, so "GCC assembler and linker" should read "GNU binutils assembler and linker.")
• Even with all optimizations enabled, generated code is slower than GCC with optimizations disabled; the README adds that all of -O0 through -O3 run the same optimization pipeline, and _Atomic is parsed but not implemented.

Independent testing found rough edges. GitHub issue #1 — "Hello world does not compile" — reproduces the README's quick-start failing on fresh Fedora and Ubuntu containers because the driver does not locate the native C library's stddef.h/stdarg.h; commenters found it works once include paths are supplied, and one argued the fault is the driver's include-path handling, not the compiler. A hands-on test on Tildes measured 9.52 seconds versus 2.89 for gcc -O3 on the same program and needed manual absolute header paths.

The strongest factual dispute is the "bootable kernel" claim. In the Hacker News thread, ndesaulniers — who spent nearly a decade at Google getting Clang to build the kernel — asks "It may build, but does it boot...?" before accepting it does, but flags generated-code correctness as unproven. Commenter shakna went further, claiming the final kernel binary cannot be linked at all because CCC "generates incorrect relocations for kernel data structures (__jump_table, __ksymtab)" — a claim with no public response in Anthropic's materials that we could find, and which this post has not independently verified. Treat "builds a bootable Linux 6.9" as an Anthropic claim with contested scope.

Two framing disputes are worth carrying into any decision: "clean-room" means no runtime internet access during development, not that the model was unpolluted by compiler source code — a distinction Ars Technica and multiple commenters flagged as misleading, since the model was almost certainly trained on GCC, Clang, and the rest. And the $20,000 covers API tokens only: not model training, not the human labor of building scaffolding and CI, and not the decades of test-suite and reference-compiler work the task leans on. Carlini's own counter is that it remains "a fraction of what it would cost me to produce this myself—let alone an entire team."

Sources

• Building a C compiler with a team of parallel Claudes — Anthropic (Nicholas Carlini)
• anthropics/claudes-c-compiler — GitHub repository and README
• Issue #1: "Hello world does not compile" — GitHub
• Sixteen Claude AI agents working together created a new C compiler — Ars Technica
• Sixteen Claude Agents Built a C Compiler without Human Intervention... Almost — InfoQ
• Hacker News discussion (735 points)
• Tildes discussion and hands-on test