Anthropic Engineering→ original

16 Claude Agents Wrote a 100,000-Line C Compiler in Two Weeks for $20,000

Anthropic researcher Nicholas Carlini ran 16 parallel Claude Opus 4.6 agents and had them write a C compiler in Rust from scratch. Over two weeks and nearly 2000 Claude Code sessions (about $20,000), the agents produced a 100,000-line compiler that builds Linux 6.9 on x86, ARM and RISC-V, as well as QEMU, FFmpeg, SQLite, Postgres and Redis. It passes 99% of the GCC torture tests and runs Doom. The run consumed 2 billion input tokens and 140 million output tokens. The compiler has clear weaknesses: it has no assembler or linker of its own, and it hands 16-bit x86 off to GCC. Its output code is also less efficient than GCC's with optimizations turned off.

AI-processed from Anthropic Engineering; edited by Hamidun News
16 Claude Agents Wrote a 100,000-Line C Compiler in Two Weeks for $20,000
Source: Anthropic Engineering. Collage: Hamidun News.
◐ Listen to article

Nicholas Carlini, a researcher on Anthropic's Safeguards team, ran an experiment: 16 instances of Claude Opus 4.6 worked in parallel on a shared repository, writing a C compiler in Rust from scratch. A human intervened very little. Over two weeks and about 2000 Claude Code sessions, the agents produced 100,000 lines of code. The compiler builds a bootable Linux 6.9 kernel on x86, ARM and RISC-V. The API bill came to just under $20,000.

How the agent setup works

The basic scheme is simple. Claude runs in an infinite loop: when it finishes one task, it picks up the next. Each agent lives in its own Docker container, clones a shared bare git repository and pushes its changes there. To keep agents from working on the same problem, the setup uses locks: Claude creates a text file such as current_tasks/parse_if_statement.txt, and git won't let a second agent claim the same task. Merge conflicts happen often, but the model resolves them on its own.

There is no orchestrator, and the agents have no shared communication channels. Each one decides for itself what to do next, usually picking the "next most obvious" problem. In one incident, an agent accidentally ran pkill -9 bash and killed its own loop.

Most of the effort went into the environment rather than prompts: tests, logs and feedback. Test output is capped at a few lines so it doesn't clutter the context. Errors are written on a single line with an ERROR tag so they can be found with grep. To deal with the agents' "time blindness," the setup adds a --fast option that runs a sample of 1% or 10% of the tests, deterministic for each agent.

Where they hit the ceiling

As long as tests are independent, parallelizing is easy: each agent takes its own failing test. But the Linux kernel is one giant task. All 16 agents ran into the same bug and overwrote each other's fixes. The solution was to use GCC as a reference oracle: GCC compiled a random subset of the kernel files, and Claude compiled the rest. That way the agents ended up fixing different bugs in different files. For pairs of files that broke only when combined, the team applied delta debugging.

The agents were also assigned roles: one merged duplicated code, another sped up the compiler itself, a third worked on the efficiency of the generated code, a fourth acted as an architecture critic from a Rust developer's perspective, and a fifth maintained the documentation.

Numbers and limitations

  • Size: about 100,000 lines of Rust, with no dependencies beyond the standard library.
  • Resources: 2 billion input tokens and 140 million output tokens, nearly $20,000.
  • Tests: 99% on most suites, including GCC torture.
  • Builds: Linux 6.9 (x86, ARM, RISC-V), QEMU, FFmpeg, SQLite, Postgres, Redis, Doom.
  • Clean-room development: Claude had no internet access.
  • No assembler or linker of its own: these modules were automated last and still have bugs.
  • 16-bit x86 for real mode is not implemented: the output exceeds 60 KB against the kernel's 32 KB limit, so GCC is called instead.
  • The code is less efficient than GCC's, even with optimizations disabled.

Carlini states plainly that the compiler nearly hit the limit of what Opus can do: new features and fixes regularly broke existing functionality. The progress across the model line is visible: early Opus 4 models barely managed a working compiler, and Opus 4.5 was the first to pass large test suites but could not build real projects.

Practical takeaways

The main lesson for anyone building autonomous agents: the quality of the verification mechanism matters more than the model itself. If the verifier is inaccurate, the agent will confidently solve the wrong problem. So tests need to be written with the model in mind: short output, grep-friendly logs, fast deterministic subsets, and CI that stops agents from breaking earlier commits.

Second, parallelism requires decomposition. If a task is monolithic, extra agents only get in the way, and a known working reference helps split it into independent parts.

Third, $20,000 for a compiler capable of building Linux is far cheaper than a team of engineers, but still more expensive than a subscription. The code is published, and you can test it on your own C projects. The author himself adds a caveat: fully autonomous development carries real risks, and human oversight of code quality and security is still necessary.

ZK
Hamidun News
AI news without noise. Daily editorial selection from 50+ sources. A product by Zhemal Khamidun, Head of AI at Alpina Digital.
✦ Autonomous AI Agents

Delegate Deep Research, Coding & Workflows to an AI Agent

Deploy autonomous multi-step execution with NomadNet Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and complex task orchestration.

Launch NomadNet Agent →NomadNet AI Platform
What do you think?
Loading comments…