16 Claude Agents Write a 100,000-Line C Compiler: Linux 6.9 Builds for $20,000 over ~2,000 Sessions
Anthropic researcher Nicholas Carlini had 16 parallel Claude agents build a Rust-based C compiler from scratch: a shared bare git repo, Docker containers, and lock files in current_tasks/ to claim work. Over nearly 2,000 Claude Code sessions and roughly $20,000 in API costs, the team produced a 100,000-line compiler that builds Linux 6.9 on x86, ARM, and RISC-V. Author-reported figures; this site has not independently re-tested them. Task: Chapter 01: Enabling long-running Claudes PublishedFeb 5, 2026 Published Feb 5, 2026 TeamEngineering Team Engineering TopicsAgentsCodingClaude CodeContext engineeringSee more... Topics Agents Coding Claude Code Context engineering Written by Nicholas Carlini, a researcher on our Safeguards team. ScienceMar 23, 2026Long-running Claude for scientific computing Science Mar 23, 2026 I've been experimenting with a new approach to supervising language models that we’re calling "agent teams." With agent teams, multiple Claude instances work in parallel on a shared codebase without active human intervention. This approach dramatically expands the scope of what's achievable with LLM agents. To stress test it, I tasked 16 agents with writing a Rust-based C compiler, from scratch, capable of compiling the Linux kernel. Over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V. The compiler is an interesting artifact on its own, but I focus here on what I learned about designing harnesses for long-running autonomous agent teams: how to write tests that keep agents on track without human oversight, how to structure work so multiple agents can make progress in parallel, and where this approach hits its ceiling. Enabling long-running Claudes Existing agent scaffolds like Claude Code require an operator to be online and available to work jointly. If you ask for a solution to a long and complex problem, the model may solve part of it, but eventually it will stop and wait for continued input—a question, a status update, or a request for clarification. To elicit sustained, autonomous progress, I built a harness that sticks Claude in a simple loop (if you’ve seen Ralph-loop, this should look familiar). When it finishes one task, it immediately picks up the next. (Run this in a container, not your actual machine). In the agent prompt, I tell Claude what problem to solve and ask it to approach the problem by breaking it into small pieces, tracking what it’s working on, figuring out what to work on next, and to effectively keep going until it’s perfect. (On this last point, Claude has no choice. The loop runs forever—although in one instance, I did see Claude pkill -9 bash on accident, thus killing itself and ending the loop. Whoops!). Running Claude in parallel Running multiple instances in parallel can address two weaknesses of a single-agent harness: One Claude Code session can only do one thing at a time. Especially as the scope of a project expands, debugging multiple issues in parallel is far more efficient. Running multiple Claude agents allows for specialization. While a few agents are tasked to solve the actual problem at hand, other specialized agents can be invoked to (for example) maintain documentation, keep an eye on code quality, or solve specialized sub-tasks. My implementation of parallel Claude is bare-bones. A new bare git repo is created, and for each agent, a Docker container is spun up with the repo mounted to /upstream. Each agent clones a local copy to /workspace, and when it's done, pushes from its own local container to upstream. To prevent two agents from trying to solve the same problem at the same time, the harness uses a simple synchronization algorithm: Claude takes a "lock" on a task by writing a text file to current_tasks/ (e.g., one agent might lock current_tasks/parse_if_statement.txt, while another locks current_tasks/codegen_function_definition.txt). If two agents try to claim the same task, git's synchronization forces the second agent to pick a different one. Claude works on the task, then pulls from upstream, merges changes from other agents, pushes its changes, and removes the lock. Merge conflicts are frequent, but Claude is smart enough to figure that out. The infinite agent-generation-loop spawns a new Claude Code session in a fresh container, and the cycle repeats. This is a very early research prototype. I haven’t yet implemented any other method for communication between agents, nor do I enforce any process for managing high-level goals. I don’t use an orchestration agent.; tools: Claude. Human role: - Setup: the author designed the harness, task-locking scheme, tests, and feedback files that define the agents' work. - Ongoing human involvement during runs: not stated in the source.; limitations: - The author calls it a very early research prototype: no inter-agent communication or orchestration layer, and agents pick the "next most obvious" task themselves. - High cost (just under $20,000) and agents spending significant time orienting in fresh containers are the main constraints. - Merge conflicts are frequent; the system needs extremely high-quality tests to keep agents solving the right problem. - Generated code is less efficient than GCC; the assembler and linker remain buggy..
Tools
Published on Agent Work Atlas:
Overview
Anthropic researcher Nicholas Carlini had 16 parallel Claude agents build a Rust-based C compiler from scratch: a shared bare git repo, Docker containers, and lock files in current_tasks/ to claim work. Over nearly 2,000 Claude Code sessions and roughly $20,000 in API costs, the team produced a 100,000-line compiler that builds Linux 6.9 on x86, ARM, and RISC-V. Author-reported figures; this site has not independently re-tested them.
Workflow
Chapter 01: Enabling long-running Claudes PublishedFeb 5, 2026 Published Feb 5, 2026 TeamEngineering Team Engineering TopicsAgentsCodingClaude CodeContext engineeringSee more... Topics Agents Coding Claude Code Context engineering Written by Nicholas Carlini, a researcher on our Safeguards team. ScienceMar 23, 2026Long-running Claude for scientific computing Science Mar 23, 2026 I've been experimenting with a new approach to supervising language models that we’re calling "agent teams." With agent teams, multiple Claude instances work in parallel on a shared codebase without active human intervention. This approach dramatically expands the scope of what's achievable with LLM agents. To stress test it, I tasked 16 agents with writing a Rust-based C compiler, from scratch, capable of compiling the Linux kernel. Over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V. The compiler is an interesting artifact on its own, but I focus here on what I learned about designing harnesses for long-running autonomous agent teams: how to write tests that keep agents on track without human oversight, how to structure work so multiple agents can make progress in parallel, and where this approach hits its ceiling. Enabling long-running Claudes Existing agent scaffolds like Claude Code require an operator to be online and available to work jointly. If you ask for a solution to a long and complex problem, the model may solve part of it, but eventually it will stop and wait for continued input—a question, a status update, or a request for clarification. To elicit sustained, autonomous progress, I built a harness that sticks Claude in a simple loop (if you’ve seen Ralph-loop, this should look familiar). When it finishes one task, it immediately picks up the next. (Run this in a container, not your actual machine). In the agent prompt, I tell Claude what problem to solve and ask it to approach the problem by breaking it into small pieces, tracking what it’s working on, figuring out what to work on next, and to effectively keep going until it’s perfect. (On this last point, Claude has no choice. The loop runs forever—although in one instance, I did see Claude pkill -9 bash on accident, thus killing itself and ending the loop. Whoops!). Running Claude in parallel Running multiple instances in parallel can address two weaknesses of a single-agent harness: One Claude Code session can only do one thing at a time. Especially as the scope of a project expands, debugging multiple issues in parallel is far more efficient. Running multiple Claude agents allows for specialization. While a few agents are tasked to solve the actual problem at hand, other specialized agents can be invoked to (for example) maintain documentation, keep an eye on code quality, or solve specialized sub-tasks. My implementation of parallel Claude is bare-bones. A new bare git repo is created, and for each agent, a Docker container is spun up with the repo mounted to /upstream. Each agent clones a local copy to /workspace, and when it's done, pushes from its own local container to upstream. To prevent two agents from trying to solve the same problem at the same time, the harness uses a simple synchronization algorithm: Claude takes a "lock" on a task by writing a text file to current_tasks/ (e.g., one agent might lock current_tasks/parse_if_statement.txt, while another locks current_tasks/codegen_function_definition.txt). If two agents try to claim the same task, git's synchronization forces the second agent to pick a different one. Claude works on the task, then pulls from upstream, merges changes from other agents, pushes its changes, and removes the lock. Merge conflicts are frequent, but Claude is smart enough to figure that out. The infinite agent-generation-loop spawns a new Claude Code session in a fresh container, and the cycle repeats. This is a very early research prototype. I haven’t yet implemented any other method for communication between agents, nor do I enforce any process for managing high-level goals. I don’t use an orchestration agent.
Reported result
- Nearly 2,000 Claude Code sessions over two weeks: 2 billion input tokens, 140 million output tokens, total cost just under $20,000. - The 100,000-line compiler builds a bootable Linux 6.9 on x86, ARM, and RISC-V; compiles QEMU, FFmpeg, SQLite, Postgres, Redis; ~99% pass on most compiler test suites. - No native 16-bit x86 backend (calls GCC for real mode); buggy assembler/linker; output less efficient than GCC. (Author-reported; not independently re-tested.)
Human role
- Setup: the author designed the harness, task-locking scheme, tests, and feedback files that define the agents' work. - Ongoing human involvement during runs: not stated in the source.
Limitations
- The author calls it a very early research prototype: no inter-agent communication or orchestration layer, and agents pick the "next most obvious" task themselves. - High cost (just under $20,000) and agents spending significant time orienting in fresh containers are the main constraints. - Merge conflicts are frequent; the system needs extremely high-quality tests to keep agents solving the right problem. - Generated code is less efficient than GCC; the assembler and linker remain buggy.
Try it
I want to replicate the parallel agent workflow for a coding task. Use Claude Code in Docker containers with a shared bare git repository. Implement a task locking mechanism where agents write files to current_tasks/ to claim work. Set up an infinite loop script that runs claude --dangerously-skip-permissions with a prompt instructing it to break tasks into small pieces and push changes. [Replaceable inputs: specific coding project, number of agents, test suite location]. First, run a dry test with 2 agents on a small module to verify lock file synchronization and merge conflict handling. Show me the git log and lock file states before scaling up. Ensure I approve the test harness configuration before starting the full run.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.