Claude Wrote 180 Million Lines of Proof. The Bugs It Found Had Survived Trillions of Tests.

In October 2026, Anthropic and Theorem Labs published a study that sounds backwards. They put Claude to work at the level of RISC-V assembly instructions, inside production open-source codebases, and asked it to produce formal verification proofs. In a few weeks, the system worked through 123 open-source repositories and 239 test entry points. It generated about 180 million lines of Rocq proof code that passed the Rocq checker. During the run, Claude attempted about 1 billion lines. About 180 million survived verification.

The findings were harder to dismiss than the scale. Some bugs had survived trillions of fuzzing executions. Some had sat in code for more than a decade. Claude also found defects in x86 processor hardware and hundreds of errors in the official x86 instruction-set documentation while building the mathematical model it needed.

The project changed the question a scanner asks.

Why trillions of fuzz runs missed the bugs

A fuzzer generates inputs, feeds them to a program, and watches for crashes, hangs, memory errors, and other abnormal behavior. Google’s OSS-Fuzz has pushed this method to industrial scale, with cumulative execution counts in the trillions. The method works. Many memory-safety bugs have been found this way.

Its limit is structural. A fuzzer samples. If a bug requires a very specific input shape, the sampler may never reach it. The study’s example is a counter underflow in a decompressor. Triggering it requires an input of about 20MB, and the bytes must fall into a rare arrangement. OSS-Fuzz-style campaigns often cap inputs at 1MB. The bug is not hiding because the fuzzer is lazy. It is hiding because random sampling cannot promise coverage of every path.

Claude’s task was different. The team translated test entry points into mathematical propositions. One proposition, for example, asked whether a program can avoid crashing for any input up to 64MiB. A proof attempt either closes or gets stuck. When it gets stuck, the stuck point often corresponds to a real path where the safety property fails. A failed proof locates the bug.

A controlled experiment makes the gap concrete. Researchers planted seven bugs in a Python interpreter written in Rust. Random testing missed five of the seven. The formal proof caught all seven.

That comparison does not make fuzzing obsolete. The two methods provide different kinds of assurance. Fuzzing gives statistical confidence. A completed proof gives coverage of all paths and inputs within the stated model.

Why the verification went down to machine code

The study’s second important choice was the verification target. Claude did not verify C or Rust source code. It verified the machine code that actually runs on a RISC-V CPU.

Source code is not what executes. Compiler optimization changes behavior. Startup code runs before main. The allocator hands out memory. printf does work the source file never shows. A proof about source text can verify an idealized model of the program while missing the program that actually runs. Machine code removes that gap. The proof has to model instructions, memory reads and writes, runtime initialization, and boundary conditions at the level where the CPU sees them.

The cost is proof size. A cJSON parser entry point of 391 lines of C produced about 630,000 lines of Rocq proof. Most of that proof is not about JSON parsing. It models the C runtime startup, the memory allocator, printf, and even the runtime of the memory-checking tool. The business logic is a small part of the proof. This is why 239 entry points produced 180 million lines. Formal verification is heavy because the program does not live alone. It lives on top of a runtime, a library stack, and an instruction set. The proof has to carry that weight.

That cost produces coverage. A proof that covers every reachable path and every input in a stated range turns a rare trigger condition into a map coordinate. The 20MB decompressor input stops being a needle in a haystack. It becomes a place where the proof cannot proceed.

The loop that matters: stuck, locate, patch, continue

Generating proofs at this scale would be an engineering feat on its own. The capability that matters most is the loop around failure.

In traditional formal verification, the expensive part is often diagnosis. A proof obligation fails. The engineer has to decide whether the specification is wrong, the model is wrong, or the code has a bug. That backtracking can take hours or days. Claude’s run shows a tighter cycle: when a proof gets stuck, it locates the corresponding defect, generates a patch, and continues the remaining proof. Discovery, repair, and re-verification sit inside one automated loop.

The benchmark for the old cost model is seL4, the verified microkernel. It took about 2 person-years to write the code and about 20 person-years to verify it. Formal verification delivered strong guarantees, but the price kept it inside aviation, security kernels, and a small set of critical systems. Claude’s run does not make verification free. It bends the cost curve.

The cost curve: doubling every two months

Theorem Labs published a roadmap: about $134 million in investment could verify 95% of machine code in the Nix software stack by the end of 2027. The projection rests on verification efficiency doubling roughly every two months, plus proof reuse across projects. Model iteration also lowers unit cost. Opus 5.5, for example, used about 40% fewer tokens than its predecessor on the same work.

The number deserves caution. Efficiency doubling depends on task difficulty, reuse rates, and human review capacity. A roadmap is not a guarantee. The direction is still clear. Formal verification is moving from a luxury for a few critical systems toward an option for a broader open-source community. Proof reuse changes the economics in a way test reuse does not. A test case is tied to an input. A machine-checked proof can become a trusted component that later projects cite. The first batch of proofs is already public.

The hardware and the documentation got pulled in

One side effect stood out. Building the x86 instruction-set model exposed every vague sentence, missing case, and wrong claim in the reference manual. A precise mathematical description of every instruction leaves no room for “close enough.” Claude found hundreds of errors in the official x86 documentation and a small number of defects in CPU hardware itself.

That result has symbolic weight. Once verification reaches machine code, the hardware specification becomes the foundation. A crack in the foundation limits what any upper-layer proof can mean. Claude pointed at the cracks. That has value even before anyone patches them.

What the proofs prove, and what they do not

The study’s boundaries are part of its meaning. Anthropic and the researchers state them clearly. The current work covers single-threaded, statically linked RISC-V programs running under Linux with a fixed memory budget. Within that model, the proofs show that behavior conforms to a defined safety specification, such as not crashing. That is a strict guarantee, and a useful one. It is not a declaration that software has no bugs.

The work does not cover multithreading or concurrency. Data races, lock ordering, and memory-model issues are outside the current scope. It does not prove that a result on RISC-V transfers automatically to x86 or Arm. Different instruction sets have different semantic models, and a bug can be architecture-specific. The Rocq checker verifies that a proof matches the mathematical specification. It does not verify that the specification matches the real-world security requirement. Human experts still have to review the specification. A proof can only guarantee the properties the specification describes. Properties outside the specification can still fail.

The precise claim is narrower than the headline: for a defined subset of programs, on a defined architecture, under a defined runtime model, the work provides a level of confidence that random testing cannot reach. It raises the floor of the security argument. It does not finish the argument.

What this changes for the industry

Software supply chains are deep, open-source dependencies are layered, and vulnerabilities sit dormant for years. Fuzzing remains the first line of defense. It is cheap, broad, and fast. The gap appears when a bug needs an extreme trigger condition, a rare path, or a decade of quiet. For that gap, formal verification offers a different kind of statement. Instead of “we tried many inputs and nothing happened,” it says, “under this model, the stated safety property holds for all reachable paths and inputs.”

AI lowers the engineering threshold for producing mathematical proof. Mathematics still does the checking. Writing proofs used to require years of training. The work now shifts toward specifying properties, reviewing models, and managing proof assets. Verification does not become simple. It can be repeated across many projects.

The longer path points toward provable software infrastructure: kernels, cryptographic libraries, parsers, and runtimes that many applications depend on. If machine-checked proofs accumulate for those components, the security baseline of the whole software stack rises. The Nix roadmap is one pilot. Its value is not the 95% figure by itself. Its value is the demonstration that a large-scale, lower-cost, reusable verification pipeline can run.

The first proofs are public

Claude’s 180 million lines of proof will not make vulnerabilities disappear. They will not put security engineers out of work. They change the question. The old question was: we ran so many tests, what did we miss? The new question is: can we prove that within this range, there is no path left to miss?

The road from hitting bugs to proving correctness is long. The boundaries are explicit: single-threaded, a specific architecture, a specific specification, human review. The direction is marked. The first proofs are public. The next step is another repository, another harness, another proof that either closes or gets stuck.