Anthropic's Frontier Red Team and the startup Theorem say Claude did not just test 123 widely used open-source libraries. It produced machine-checked mathematical proofs that 239 of their test entry points cannot crash — and published the receipts.
Track it live: Markets tracker
The Claude formal verification 123 libraries result, published on Thursday, October 22, 2026, by Anthropic's Frontier Red Team together with the verification startup Theorem, makes a claim that software engineering almost never gets to make. Not "we tested this heavily." Not "no bugs were found." Instead: for 239 fuzz-test entry points across 123 open-source libraries drawn from Google's OSS-Fuzz programme, Claude produced formal proofs that the code cannot crash — no memory-safety error, no failed assertion — for any input up to 64 megabytes, verified down at the level of the compiled RISC-V assembly itself.
If that sounds too strong, the authors built the work so you do not have to take their word for it. The proofs are machine-checked. A small, trusted kernel in the Rocq proof assistant either accepts each proof or it does not, the way a calculator either balances a ledger or does not. That is the difference between a very confident test report and a receipt.
What Claude formal verification 123 libraries actually proved
The method, as described in the October 22, 2026, publication, starts from something ordinary: the fuzz tests that OSS-Fuzz already runs relentlessly against these libraries. Fuzzing feeds a program torrents of random and mutated inputs, hunting for the one strange file that makes it crash. It is the best bug-finding technique the industry has, and these libraries have survived trillions of fuzzing runs. Theorem's approach converted those existing fuzz-test entry points into formal theorem statements — roughly, "for every input within this size bound, executing this compiled code produces no crash" — and then set Claude to prove them.
The scale is difficult to picture. The team reports about 180 million lines of Rocq proof in total, with a typical proof running near 600,000 lines, and Claude writing on the order of one billion lines in all over a few weeks, including discarded attempts. The median binary under proof contained about 18,000 RISC-V instructions. Humans did not write those proofs line by line, and no human could have: the entire point is that a model generated candidate proofs at machine speed while a mechanical checker, indifferent to the model's reputation, rejected anything that did not hold.
Crucially, the proofs were carried out at assembly level, not just on source code. That matters because compilers are software too, and source-level guarantees can quietly evaporate in translation. The trusted base was deliberately kept small: the RISC-V architecture model, a model of the Linux process environment, the theorem statements themselves, and the Rocq checker. Everything else had to earn its place inside a proof.
The bugs fuzzing missed
Perhaps the most persuasive part of the October 22, 2026, report is not the code that passed. It is the code that failed. On the way to the proofs, Claude found and helped patch hundreds of bugs that fuzzing had missed despite, in some cases, trillions of executions. Two examples show why. One was a counter underflow in a decompressor that only triggers with inputs around 20 megabytes — far larger than the small files fuzzers typically favour. Another was an out-of-bounds read in an image decoder that needed inputs near 64 megabytes to surface. Random testing rarely wanders into those corners because the inputs are enormous and the conditions precise. A proof attempt wanders everywhere, by definition: it cannot finish until every corner is accounted for. Claude also rediscovered a known vulnerability, CVE-2026-56132 in the libexpat XML parser, which the authors treat as a useful calibration check — the method finds real flaws, not just exotic ones.
Why this matters
Software runs civilisation, and most of it is verified the way a bridge might be verified by driving trucks over it until one falls through. Fuzzing is excellent — it has found tens of thousands of real bugs — but it can only show the presence of failures, never their absence. Formal verification promises the opposite: a mathematical guarantee. It has historically been so expensive that it was reserved for the tiniest, most critical kernels. The classic comparison, cited in discussion of the new result, is seL4, a microkernel whose verification consumed roughly 20 person-years of expert effort against about two years to build the kernel itself. Ten-to-one was the going exchange rate between proving code and writing it.
The Claude formal verification 123 libraries work attacks that exchange rate directly. If a model can generate assembly-level proofs for 123 real, messy, widely depended-upon libraries in weeks, then verification stops being a cathedral project and starts looking like a pipeline step. The economic implication is large enough to watch on the markets tracker: the libraries in OSS-Fuzz sit underneath browsers, servers, phones and cloud infrastructure, and a single memory-safety flaw in one of them can become a CVE, an emergency patch cycle and, occasionally, a breach headline. Reducing that class of risk has measurable value to every company built on top of open source — which is to say, nearly all of them.
The caveats, stated plainly
Here is where responsible coverage has to slow down, because "formally verified" is the most over-read phrase in computing. The proofs cover single-threaded, statically linked RISC-V binaries built against the musl C library. Most software the world actually ships runs on x86 or ARM processors, dynamically linked, typically against glibc. A proof about the RISC-V build is powerful evidence about the underlying code, but it is not, by itself, a proof about the exact binary on your laptop.
Second, crash-freedom is not correctness. The theorems rule out memory-safety errors and failed assertions. They say nothing about logic bugs that never crash: the parser that silently returns the wrong answer, the access check that is politely, stably wrong, the calculation that is wrong in a well-behaved way. A program can be provably crash-proof and still do the wrong thing, securely and reliably, forever. Third, every proof rests on its models and its theorem statement. If the RISC-V model, the process model or the statement itself misdescribes reality, the guarantee inherits that error. The authors were transparent about this trusted base, and a subset of the proofs and the semantics work has been published on GitHub, where outside researchers can and should prod it.
What critics and sceptics say
Sceptics make three fair points. The first is scope: 239 entry points, however thoroughly proved, are entry points, not entire libraries in every configuration. The second is transfer: until the pipeline routinely handles threaded, dynamically linked x86 and ARM builds, its guarantees describe a model of deployment rather than deployment itself. The third is interpretation: there is a real risk that "Claude proved it cannot crash" gets repeated, in boardrooms and headlines, as "Claude proved it is secure," which the work does not claim. Defenders respond that this criticism proves too much. Fuzzing also covers a model of deployment, and nobody dismisses it. A checked proof over a stated scope is still a strictly stronger artefact than a test log over the same scope, and the bug haul — hundreds of flaws the best existing technique missed — is an empirical result, not a philosophical one.
Context: a striking week for AI and code
The result did not arrive alone. In the same October 2026 period, researchers disclosed AI-assisted discovery of serious flaws in PHP, dubbed PHP2Shell in security coverage, and Anthropic reported that Claude had been used to strip unneeded code out of OpenSSH, shrinking the attack surface of one of the internet's most sensitive tools. Read together, the pattern is coherent: models are becoming genuinely useful on both sides of the security ledger at once, finding vulnerabilities in widely used code faster, removing code that should never have shipped, and now, in the Theorem collaboration, attempting the hardest trick of all — proving a negative, at scale, in a form anyone can recheck.
What happens next
The obvious next questions are engineering questions. Can the pipeline move from RISC-V to x86 and ARM, from static musl builds to the dynamic glibc binaries production systems actually run, and from single-threaded code to the concurrent code where the nastiest bugs live? Each step enlarges the trusted modelling problem. The commercial question follows: Theorem and companies like it are betting that verified components become a purchasable property, the way penetration tests and audits are today, with insurers, regulators and enterprise buyers eventually asking not just whether software was tested, but what, precisely, was proved about it.
For now, the honest summary is narrow and impressive at once. On October 22, 2026, Anthropic and Theorem reported that Claude generated machine-checked proofs covering 239 entry points in 123 open-source libraries, that the checking is mechanical rather than testimonial, and that the attempt surfaced hundreds of bugs the industry's best testing had missed. That is not the end of software failure. Logic will still err, models will still misdescribe the world, and most shipped binaries remain unproved. But a technique that once cost 20 person-years for one small kernel just processed a meaningful slice of the open-source ecosystem in weeks — and left receipts anyone can verify. That is a before-and-after line, even with every caveat attached.
Read next: Anthropic cuts internet access in AI evaluations and AI vulnerabilities and the disclosure surge.