Claude Opus 4.6 Agent Teams Wrote a C Compiler: What $20,000 Bought and What It Did Not

On February 5, Anthropic released Claude Opus 4.6. The same day, Nicholas Carlini, a researcher on Anthropic's Safeguards team, published the most concrete demonstration in the launch: 16 Claude agents, working in parallel for two weeks, wrote a C compiler in Rust that can build a bootable Linux 6.9 on x86, ARM and RISC-V. The bill was just under $20,000.

That is a real result, and the write-up is unusually frank about where it stops. I read it less as a story about the model than as one about specifications and review, which is where a team considering multi-agent coding will spend its money. Every number below is reported by Anthropic unless I say otherwise. I have not run the compiler or the harness.

What Claude Opus 4.6 changed

The release is aimed at longer agent runs:

Source: Anthropic's announcement. Vendor-reported.

Agent teams let several Claude Code agents work in parallel and coordinate on their own; you can take over any of them. Anthropic says they suit work that splits into independent, read-heavy pieces, such as reviewing a codebase. The compiler was the opposite kind of job.

The C compiler experiment in numbers

Source: Carlini's write-up, February 5, 2026. Run and reported by Anthropic.

By my arithmetic, that is about $10 per session and 20 cents per line. Each session read roughly a million input tokens and wrote roughly 70,000, about 14 to 1. Agents spend most of their tokens reading, so the context features in this release affect the bill as well as the quality.

The total is worth checking against the price list. At the standard rates, 2 billion input and 140 million output tokens come to about $13,500. At the rates for prompts over 200,000 tokens, they would come to about $25,250. The reported figure sits between the two, which fits a mix of long and short prompts, but the write-up does not break it down. Before budgeting an agent project from token counts and a price list, check a real invoice.

How 16 agents coordinated without an orchestrator

The coordination came from a harness, not a product feature. Carlini built it himself: a shell loop that starts a new Claude Code session whenever the last one ends, a Docker container per agent with no internet access, and a shared git repository that each agent clones and pushes back to. The write-up does not say the agent teams feature in Claude Code was used.

It is deliberately crude:

• Claiming work. An agent takes a task by writing a lock file into a current_tasks/ directory. When two agents go for the same task, git sync forces the second to pick another.
• No manager. There is no orchestrating agent and no channel between agents except git. Each one picks the next most obvious problem.
• Merging. Agents pull, merge each other's work and push. Conflicts were frequent, and the agents resolved them.
• Memory in files. Every session starts with no context, so the agents were told to keep READMEs and progress files current. Test output stayed short, with details in log files, so context did not fill with noise.
• Standing roles. Some agents had permanent jobs: merging duplicate code, speeding up the compiler, improving the code it generates, critiquing the design as a Rust developer would, and writing documentation.

Each agent ran Claude Code with --dangerously-skip-permissions, which is defensible only because of the container around it. After OpenClaw's one-click gateway takeover, disclosed on January 31, the container is the part of this design I would adopt first.

The test suite was the real specification

Carlini writes that most of his effort went into the environment around Claude: finding high-quality compiler test suites, and writing verifiers and build scripts for open-source packages. He stresses that the verifier must be close to perfect, or Claude solves a different problem from the one you meant.

Near the end of the project, new features kept breaking old ones, so he added a continuous integration gate that new commits had to pass. Sixteen agents with no shared memory can undo each other's work unless a test stops them.

Then came the Linux kernel. Building it was one enormous task, so the agents all hit the same bug, and having 16 of them stopped helping. The fix was to use GCC as a known-good oracle: compile most of the kernel with GCC and a random subset with the new compiler, then narrow down which files it got wrong. One blocked task became many independent ones.

This is the best case for agent teams. A C compiler has a written standard, decades of public test suites and a reference implementation that settles any argument. Most business software has none of the three. Its specification lives in people's heads and in last year's incident reports.

The environment is part of the specification too. On release day, the repository's first issue reported that the README's hello-world example failed on three setups, because the preprocessor could not find stddef.h and stdarg.h, headers a C compiler normally supplies itself. Commenters showed it works with the right include paths. Not a deep bug, but it is what happens when the test machine quietly becomes part of the definition of working.

What $20,000 did not buy

Carlini lists the gaps himself:

• No 16-bit x86 code generator. Booting Linux from real mode needs one, so that step calls GCC. The compiler's own attempt produced more than 60 KB of code, beyond Linux's 32 KB limit. ARM and RISC-V need no GCC for this step.
• No working assembler or linker of its own. These were the last parts Claude started on, and they are still buggy. The demo video used GCC's.
• Not a drop-in replacement. It builds many projects, not all of them.
• Slow output. With every optimisation on, its code is less efficient than GCC's with every optimisation off.
• Middling Rust. Reasonable, and well short of what an expert Rust programmer would write.

He adds that the compiler has nearly reached the limit of what Opus can do, and his attempts to fix several gaps did not fully succeed. By his account, Opus 4.5 could already produce a working compiler but could not compile any real large project.

The repository's README says all the code and documentation were written by Claude, and it states that the compiler uses its built-in assembler and linker by default and works as a drop-in replacement for GCC. Carlini's write-up says the opposite on both points. The same README warns that none of the code has been validated and that the docs may contain false claims. Claude wrote the documentation, and the documentation needed a reviewer.

What this means for teams considering multi-agent coding

Cost per useful result. $20,000 bought a research prototype that its own README advises against using. That is a fair price for an experiment, and Carlini says it is a fraction of what the work would have cost him alone. For a product team, the unit that matters is a change that is reviewed, merged and still working a month later. Nothing here measures that, and I would not extrapolate.

Review burden. A hundred thousand lines in two weeks is, by my arithmetic, about 7,000 lines a day. The README says no human pair-programmed with Claude or gave feedback on code quality along the way. Carlini names the risk himself: it is "easy to see tests pass and assume the job is done". A process that needs a person to read every line will fall behind on the first day.

Where humans still decide. Choosing the tests, designing the harness, splitting the kernel problem with the GCC oracle and deciding when the result was good enough were human calls. The agents did the typing and much of the debugging. The judgement stayed with the engineer.

The same split holds in my own work. On MerlinX, the agentic platform I work on, I designed and directed the core, and it was built with AI coding agents. A green test run is where a release starts. Releases ship in gated waves: UAT runs the identical image artifacts, verified by digest rather than rebuilt look-alikes, and nothing is promoted until post-deploy assertions pass and a soak holds against the baseline error rate. The compiler project added the first gate, CI, near the end. Nothing in the write-up describes running the same build in a second environment before release, and the first bug report landed in that gap.

What I would test before adopting multi-agent coding

• Start where an oracle exists. A port with an existing test suite, or a migration with a reference implementation. Without one, agents optimise for whatever the tests happen to check.
• Cost per merged, reviewed change. Cost per session is easy to report and says little.
• Review capacity. Decide how many reviewer hours you have per thousand lines, and limit agent throughput to match.
• A clean machine as a gate. Build and run the output somewhere the agents never touched.
• Agent-written documentation. Check every claim against behaviour. This README shows why.
• Containment. No internet, no secrets and no production credentials inside the container, whatever the permission flags allow.
• Read-heavy work first. Anthropic suggests the agent teams preview for reviews, a sensible place to learn how teams behave before they write code.

Sixteen agents, two weeks and nearly $20,000 produced a C compiler that can build Linux, with GCC on hand for the boot code, the assembler, the linker and the refereeing. To be fair, that is how the rest of us build Linux too.

Sources

• Anthropic, Introducing Claude Opus 4.6, February 5, 2026
• Nicholas Carlini, Building a C compiler with a team of parallel Claudes, Anthropic Engineering, February 5, 2026
• anthropics/claudes-c-compiler, repository and README, February 5, 2026
• Issue #1, Hello world does not compile, February 5, 2026
• OpenClaw security advisory GHSA-g8p2-7wf7-98mq, January 31, 2026

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and AI-assisted software delivery.