Claude proved 123 libraries can't crash. What a proof really means

Abstract. On October 22, 2026, Anthropic's Frontier Red Team, working with a company called Theorem, reported that Claude had written machine-checked proofs that 239 entry points in 123 widely used open source libraries never crash, on any input smaller than 64 MB.1 Theorem supplied the formal models of RISC-V processors and Linux processes that the proofs are built on [1]. This page explains what that sentence means, what a proof rules out that a test can't, and the fine print that comes with it.

In words: for every possible input under 64 MB, the program finishes without crashing. That, roughly, is the statement Claude proved 239 times.2 "Roughly" is doing work. The exact statement also pins down the machine, the operating system and what counts as a crash. It's in section 3.

The short version

A test checks the inputs someone thought to try. A proof covers all of them, and a separate program called a proof checker confirms every step, so nobody has to take the prover's word for it. Anthropic says Claude, working with Theorem, wrote about 180 million lines of such proofs in a few weeks and found hundreds of bugs that trillions of test runs had missed. The catch: a proof only covers the property it states, on the machine it assumes, so "formally verified" still doesn't mean "bug free."

Video 1. The same story in 1 minute 58 seconds.

1What happened

On October 22, 2026, Anthropic's Frontier Red Team published "LLMs are making formal software verification feasible at a much larger scale," written with Theorem [1]. Over a few weeks, Claude proved that 239 entry points across 123 libraries from OSS-Fuzz, Google's project that continuously fuzz tests open source code, won't crash on any input smaller than 64 MB.

Two terms first. A fuzz test is a small harness that feeds a library a stream of random or mutated inputs, hunting for one that makes it crash. An entry point here is one of those harnesses: one way into a library's code. Formal verification means proving, with mathematical rigor, that code has a stated property for every input, instead of checking a sample.

The proofs total about 180 million lines of Rocq, a language for writing proofs that a computer can check mechanically.3 Rocq was formerly known as the Coq Proof Assistant [8]. A typical proof runs to about 600,000 lines, for a compiled program with a median of 18,000 machine instructions [1].

Trying to prove the code safe turned up hundreds of bugs. Anthropic says some "had eluded detection for years, despite trillions of test runs," and one, a previously unknown logic bug, had been latent for more than a decade [1]. Other examples in the post: an out-of-bounds read in an image decoder that needed a 64 MB input and more than 2 GB of memory to trigger, and a rediscovery of a known vulnerability in libexpat, an XML parser, that needed deeply nested input.

Theorem launched OSS Verify the same day, offering the process free to open source projects: "We prove it's crash-free or send you the patches it needs" [3]. Anthropic's announcement on X passed 1.5 million views [2].

These results are Anthropic's own report. Anthropic says it is publishing a subset of the proofs so anyone can check and reuse them, and holding back proofs that could reveal bugs that haven't been patched yet [1].

2Tests and proofs

Most software is checked with tests: run the code on some inputs and see whether anything goes wrong. Tests are good at finding bugs. They can't show that a bug is absent, because they only try the inputs that someone, or some random generator, picked.

The classic illustration comes from Joshua Bloch at Google. On June 2, 2006, he wrote that the binary search in Java's standard library, a version he had written himself, was broken [4]. The bug was one line:

int mid = (low + high) / 2;

Binary search finds an item in a sorted array by checking the middle of the range still in play, from index low to index high, then throwing away the half that can't contain it. A Java int holds at most 2,147,483,647. Once an array has more than about a billion items, low + high can exceed that. The sum wraps around to a negative number, the program asks for an item at a negative position, and Java throws ArrayIndexOutOfBoundsException. The bug sat in Java for about nine years before it broke someone's program [4].4 Bloch notes the same bug was in the binary search in Jon Bentley's 1986 book Programming Pearls, which Bentley had proved correct [4]. Integers on paper never overflow; 32-bit integers in a machine do. Hold that thought for section 3.

Try it below. The slider sets the size of the array. The demo searches for the last item, which pushes low as high as it can go.

1,000,000 items

The test suite

1,000,000 random searches on arrays of up to 1,000,000 items. Your browser runs them for real.

Not run yet.

The proof

Every valid pair of low and high, for every array size up to 2,147,483,647.

Figure 1. Test versus proof on Bloch's binary search bug. The tests pass for both lines, because no array they try is big enough to matter. The proof side tells the two lines apart. Solver timings are from our own run, described in section 4.

No test suite that sticks to small arrays will ever see this bug, however many tests it runs. A proof works differently: it's an argument that covers every input at once. A solver, a program that reasons about all inputs symbolically instead of one at a time, finds the bad case in milliseconds. Proving the fixed line correct takes a few lines of algebra.

Figure 2 shows why sampling can't get there. Each point is one pair of values the midpoint line could receive. Half of all valid pairs overflow, yet every one of them needs an array of more than a billion items, far outside where small tests live.

Every valid pair of low and high, with the overflow region and the tested region marked high low
1×
Each axis shows
0 to 2,147,483,647
Overflow pairs in view
50%
Tested pairs in view
0.00002%

At full size, every test lands in a single speck at the bottom left. Drag the zoom to find them.

  • All valid pairs (low ≤ high)
  • Pairs where low + high overflows
  • Pairs a test on arrays up to 1,000,000 items can try
Figure 2. All 2,305,843,010,287,435,776 valid inputs to the midpoint line, drawn to scale. A proof speaks for the whole triangle. A test suite speaks only for the points it visited.

From one line to 123 libraries

Bloch's line has two inputs. A library's fuzz test takes a whole file, and the number of possible files under 64 MB is so large that no test suite could visit more than a vanishing fraction of them. Covering them all takes a proof, and proofs about real code have been expensive. As Anthropic put it, formal verification "has only been feasible for small codebases (or required a lot of expert time)" [2].

The new part is who writes the proofs. Claude does the long, tedious work, and a much simpler program, the Rocq proof checker, decides whether each proof is valid. Here is the pipeline as Anthropic describes it [1]:

  1. Start with a library and its existing OSS-Fuzz fuzz test.
  2. Compile it to a RISC-V executable. RISC-V is an open design for processor instructions. The proof is about the machine instructions that actually run, not the source code.5 Hillel Wayne calls this the main innovation: proving the compiled program skips a step where translating source code into a proof language can quietly prove the wrong thing [7].
  3. Write the spec. Combine the binary, Theorem's formal models of RISC-V and of Linux processes, and the property "this fuzz test never crashes" into one precise mathematical statement.
  4. Claude writes a proof in Rocq. The proof checker accepts it only if every step follows from the rules.
  5. When a proof gets stuck on a real bug, Claude patches the code. The spec is regenerated and Claude proves it again.

3What exactly was proved, and what wasn't

Statement (paraphrasing Anthropic [1]). For each of the 239 fuzz test entry points, compiled as a single-threaded, static RISC-V binary linked against musl libc,6 musl and glibc are two implementations of the C standard library, the basic code nearly every C program leans on. "Static" means it is bundled into the program file. with a fixed memory budget, running on Linux: for every input smaller than 64 MB, and every modeled operating system response and memory layout, the program exits normally, without triggering a memory-safety error or failing an assertion.

What counts as a crash. OSS-Fuzz builds C and C++ code with AddressSanitizer, a tool that stops a program the moment it touches memory it shouldn't. So "crash" means a memory-safety error of the kind AddressSanitizer catches, or a failed assertion, which is a check the programmers wrote into the code [1].

Taken on trust, not proved

Every proof rests on things that are assumed correct, often called the trusted base.7 If anything on this list is wrong, a proof can check out and still not describe what the real program does. Anthropic lists them [1]:

  • The formal models of RISC-V and of Linux processes, which Theorem supplied.
  • The exact theorem statements that were proved.
  • The Rocq proof checker itself, plus the hardware, operating system and OCaml compiler it relies on.

Not covered

  • Bugs that aren't crashes. A program can exit normally and still compute the wrong answer or skip a security check. Anthropic notes some logic bugs "never crash at all."
  • Memory bugs AddressSanitizer can't see. In Anthropic's words, "ASan doesn't detect all memory safety bugs."
  • Other machines and setups. The proofs are about static, single-threaded RISC-V binaries using musl. Anthropic points out that most people run these libraries on x86 or ARM and link them dynamically against glibc. Inputs of 64 MB or more are outside the statement too.
  • Code nobody pointed a proof at. Not every entry point of each library was verified, and a program that misuses a library can still corrupt memory on its own side.
  • A wrong statement. A perfect proof of the wrong spec proves nothing useful. That's the Bentley lesson from section 2. Anthropic also flags reward hacking: Claude could make a theorem provable by changing the program. The team penalized patches and logged and audited them [1].

"Formally verified" does not mean "bug-free."

4What we checked ourselves

The binary search bug is Joshua Bloch's 2006 finding, and the 123-library result is Anthropic's and Theorem's. We wanted to see the gap between testing and proving with our own eyes, so on October 23, 2026 we reran Bloch's example in miniature: a short Python script, and Z3, a widely used solver.

Testing the original line
1,000,000 random searches on arrays of up to 1,000,000 items: 0 failures, in 0.5 seconds.
Asking the solver about the original line
A counterexample in 3 ms: low = 1, high = 2,147,483,647 gives mid = -1,073,741,824.
The smallest failing case
high = 1,073,741,824, which means an array of 1,073,741,825 items.8 Bloch describes the threshold as arrays of 230 elements or more, "roughly a billion" [4]. With high starting at the last index, the first size that can actually fail is one item past 230.
Asking the solver about the fix
low + (high - low) / 2 stays between low and high for all 2,305,843,010,287,435,776 valid input pairs. No counterexample exists; proved in 15 ms.

The "Run 1,000,000 tests" button in Figure 1 repeats the first step in your browser. Here is the human-sized version of the last one:

Claim. If 0 ≤ low ≤ high ≤ 2,147,483,647, then low + (high − low) / 2 is computed without overflow and lands between low and high.

Proof. Since 0 ≤ low ≤ high, the difference high − low is between 0 and high, so it fits in an int. Halving it gives a number d with 0 ≤ d ≤ high − low. Then low ≤ low + d ≤ high ≤ 2,147,483,647, so the addition fits too, and the result sits between low and high. ∎

5Reactions

"It's not a panacea, but a formally verified program is way more robust than one that's vibe-tested."

Haseeb Qureshi, managing partner at Dragonfly, @hosseeb, October 23, 2026. He calls formal verification a big part of why cybersecurity favors defenders in the long run.

"I'm excited by the idea of using formal verification to prove these kinds of 'universal properties' of existing software (like memory safety)."

Charlie Marsh, founder of Astral, which makes the Python tools uv and Ruff, @charliermarsh, October 23, 2026. He adds that he's a novice in the field.

"This, probably deliberately, doesn't address the single biggest gap in AI-based verification: AIs cannot come up with good properties."

Hillel Wayne, formal methods writer and teacher, @hillelogram, October 23, 2026. He calls the work very cool, notes the team proved a known universal property (the code doesn't crash) rather than arbitrary ones, and stresses that wrong assumptions are the biggest source of errors in verified code.

6Timeline

  1. 1986Jon Bentley's Programming Pearls includes a binary search, proved correct, with the overflowing midpoint line [4].
  2. June 2, 2006Joshua Bloch at Google publishes "Nearly All Binary Searches and Mergesorts are Broken." The bug had sat in Java's library for about nine years [4].
  3. Oct 22, 2026Anthropic's Frontier Red Team publishes its results with Theorem: 239 entry points in 123 libraries proved not to crash [1] [2]. Theorem launches OSS Verify, free for open source [3].
  4. Oct 23, 2026Haseeb Qureshi, Charlie Marsh and Hillel Wayne weigh in [5] [6] [7]. Anthropic's post passes 1.5 million views on X. Emergent Mind posts its video explainer.
  5. Oct 24, 2026This page goes up.

7What it means

Proofs are getting much cheaper. The math behind formal verification is old. What kept it to small programs was the expert time each proof took. If AI can write proofs that a checker then confirms, "proved not to crash" could become an ordinary claim for widely used libraries, not a rare one.

The checker carries the trust, not the AI. You don't have to believe Claude. You have to believe Rocq, the models of the machine, and the statement being proved. That's a much smaller, more inspectable thing to trust.

Ask three questions of any "formally verified" claim. Which property was proved? Under which assumptions about the machine, the inputs and the environment? And what is trusted without proof? This result answers all three in public, which is what makes it possible to judge.

Keep testing. Tests find bugs quickly and cover behavior nobody has written a spec for. Choosing the right property is still the hard part, which is Hillel Wayne's point.

If you maintain an open source library, Theorem says OSS Verify is free for open source and will prove a project crash-free or send the patches it needs [3]. Anthropic says Theorem is also publishing a Claude skill to help developers start verifying their own code [1].

8Questions people are asking

Does this mean these 123 libraries have no bugs?

No. It means 239 specific fuzz tests can't crash, in the AddressSanitizer sense, on inputs under 64 MB, on the machine the proofs assume. Wrong answers, security checks that don't fire, code no fuzz test reaches, and bugs that only show up on other setups are all outside the claim.

If Claude wrote the proofs, why trust them?

Because Claude's say-so isn't the evidence. Each proof is checked by Rocq, a proof checker that rejects any step that doesn't follow. What remains to trust is Rocq itself, Theorem's models of RISC-V and Linux, and whether the statement says what people think it says.

What's the difference between a test and a proof?

A test runs the code on particular inputs and reports what happened on those inputs. A proof is a logical argument that a property holds for every input in a stated range. In Figure 1, a million tests pass for the broken line; one solver query finds the failure.

Why did trillions of test runs miss these bugs?

A fuzzer only finds a bug if it happens to generate an input that triggers it. Some of these bugs needed very specific, very large inputs: one needed a 64 MB input and more than 2 GB of memory. A proof can't skip those, because it has to account for every input.

Why does it matter that the proofs are about RISC-V?

The proofs are about the exact machine instructions that run on a RISC-V processor, in a static binary using the musl C library, with one thread. Most people run these libraries on x86 or ARM chips with glibc, so the guarantee doesn't automatically carry over to the copy on your laptop. It does say the code itself has no crash on any input under 64 MB in that setting.

Can I get my own project verified?

Theorem's OSS Verify offers it free to open source projects [3], and Anthropic says Theorem is publishing a Claude skill for developers who want to try it themselves [1].

9Updates

  1. This page went up. It covers everything known as of October 24, 2026.

References

  1. Anthropic Frontier Red Team, with Theorem. "LLMs are making formal software verification feasible at a much larger scale." October 22, 2026.
  2. Anthropic (@AnthropicAI). Announcement on X. October 22, 2026.
  3. Theorem (@theoremlabs). OSS Verify announcement on X. October 22, 2026.
  4. Joshua Bloch. "Nearly All Binary Searches and Mergesorts are Broken." Google Research blog, June 2, 2006.
  5. Haseeb Qureshi (@hosseeb). Post on X. October 23, 2026.
  6. Charlie Marsh (@charliermarsh). Post on X. October 23, 2026.
  7. Hillel Wayne (@hillelogram). Post on X. October 23, 2026.
  8. The Rocq Prover. rocq-prover.org.
  9. Emergent Mind's own check: a Python script testing the midpoint line with 1,000,000 random searches and the Z3 solver, run October 23, 2026. Results in section 4.