🔍 Read the full analysis: How To Read Anthropic’s Claims About Claude And Formal Verification on ThorstenMeyerAI.com
Get business pricing on monitors, keyboards and dev gear
- Business-only prices and quantity discounts
- Tax-exempt purchasing
- Multiple users, one account, clear invoices
TL;DR
Anthropic and collaborator Theorem report that Claude generated Rocq proofs for no-crash properties at 239 entry points across 123 open-source libraries. The proofs apply to specific compiled RISC-V programs under stated assumptions, not to every version or use of those libraries; the companies also report finding hundreds of bugs.
Anthropic’s Frontier Red Team and collaborator Theorem reported on October 22 that Claude produced formal proofs for 239 fuzz-test entry points in 123 open-source libraries, showing that specified compiled programs do not crash on inputs under 64 MB, subject to the models and assumptions used. The companies say the effort also found hundreds of bugs, including issues that fuzz testing had not reached.
The work turns an existing fuzz test into a specification: for every input below the stated size limit, the test program should not crash. The libraries and tests were compiled into RISC-V executables and instrumented with AddressSanitizer to detect certain memory errors. Claude generated proofs in the Rocq proof assistant; Rocq’s checker then checked whether each proof followed from the specification and formal models.
Anthropic says the proof corpus totals about 180 million lines of Rocq, with a typical proof around 600,000 lines. The reported median binary contained 18,000 RISC-V instructions. The scale is notable, but the line count is not a measure of how many people inspected the proofs: Anthropic says the proof checker verifies them, while a smaller set of models, theorem statements and software components must be trusted.
According to Anthropic, the effort discovered hundreds of bugs. Examples described in the source include memory errors requiring unusually large inputs, a bug triggered by a particular sequence of calls, and a file-access restriction that was not always enforced. The source also says Claude rediscovered CVE-2026-56132 in libexpat. These are findings reported by the project; the article does not provide an independent audit of each bug or its remediation status.
Infographic 01 · From test to proof
Existing fuzz tests became specifications. Claude proved them.
Over a few weeks, Claude proved at the machine-code level that hundreds of real fuzz entry points can no longer crash, after patching the bugs it found.
The pipeline
From an existing test to a checked proof
- Compile. The library and its existing fuzz test become a RISC-V executable, instrumented with AddressSanitizer.
- Specify. Theorem’s RISC-V and Linux process semantics plus the no-crash property mechanically yield the specification.
- Prove. Claude writes the proof in Rocq. A failed attempt points at a possible bug; Claude patches it and proves the new spec.
- Check. The Rocq proof checker verifies the proof. Virtually none of the proof needs human review.
Fuzzing vs. proof
Same entry point, different guarantee
| Fuzzing | Proof | |
|---|---|---|
| Inputs | Fuzzing: Generated samples, typically capped at 1 MB | Proof: Every input under 64 MB |
| Paths | Fuzzing: Guided by code coverage, no guarantee | Proof: Every path reachable from the entry point |
| Result | Fuzzing: Bugs found so far | Proof: No crash left to find on the modelled system |
Typical proof: about 600,000 lines for a binary with a median length of 18,000 RISC-V instructions.
“If Claude can prove this spec, the fuzz test on RISC-V becomes superfluous.”Anthropic, 22 Oct 2026
Source: Anthropic, “LLMs are making formal software verification feasible at a much larger scale” (22 Oct 2026).
Powered by Thorsten Meyer AI
What These Proofs Can Establish
Fuzzing tests a program with many generated inputs, but it cannot establish that every possible input has been tried. A successful formal proof can support a stronger statement: within the defined model and specification, the covered program does not trigger the specified failure. That difference could matter for software used in security-sensitive settings, where a rare memory error can be consequential.
The approach also targets a longstanding cost in formal verification. Anthropic cites the seL4 microkernel project as an example of verification requiring far more labor than implementation. Claude’s role in generating proofs may reduce some of that work, while the proof checker provides a mechanical way to check the resulting argument. The project’s results do not by themselves show that verification is now inexpensive or ready for routine use across software development.
Cost remains a stated constraint. Anthropic says some proofs consumed hundreds of millions of tokens, although newer models and reusable proofs can reduce the effort. For maintainers, companies and users, the practical question is whether the cost and narrow coverage can be expanded enough to justify using this process on software they depend on.
formal verification software tools
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
From Fuzz Tests to Machine Proofs
Fuzzing is a software-testing method that supplies programs with large numbers of varied inputs and looks for failures such as crashes. OSS-Fuzz, the source project’s test collection, provides entry points that can be run this way. Such testing can find real defects, but its results depend on which inputs and execution paths are reached.
Anthropic and Theorem’s method uses those existing tests rather than trying to specify a library’s entire intended behavior. They model the compiled program and its environment, then ask Claude to prove that the test cannot crash under the resulting specification. If an attempted proof fails, the team says the failure can expose a possible bug; after a code change, the specification and proof can be produced again.
This is a report about a particular research effort, not a general certification of the libraries. Anthropic says it is publishing proofs that did not require patching, previously unavailable trusted components, and specifications for tests it could not prove. It describes the work, to its knowledge, as the first large-scale AI application of formal verification to production software at the assembly-code level; that characterization is Anthropic’s claim.
As an affiliate, we earn on qualifying purchases.
Where the Proofs Stop
The results cover single-threaded, static RISC-V binaries linked against musl, according to the source. They do not establish the same properties for commonly deployed x86 or ARM builds linked against glibc, or for every version and configuration of the libraries. The stated input bound is also part of the claim: the no-crash property concerns inputs under 64 MB, not arbitrary inputs.
A proof shows what follows from its specification and assumptions; it does not establish that those assumptions capture every behavior users care about. The source describes memory-safety checks and some test-specific properties, but it does not claim that the libraries are bug-free, that every security flaw was found, or that the proofs cover all possible program behavior. It also does not give a complete accounting of the bugs’ severity, fixes, or independent review.
The scale of the proof corpus does not remove the need to trust the formal models, theorem statements, Rocq checker and supporting components. Anthropic identifies hardware, the operating system and the OCaml compiler among additional parts of the trusted setup. How robustly the results transfer to other processors, operating systems, build configurations and concurrent execution remains unsettled by this report.
AddressSanitizer memory error detector
As an affiliate, we earn on qualifying purchases.
As an affiliate, we earn on qualifying purchases.
Proofs, Fixes and Wider Coverage
Anthropic says it is releasing the proofs that required no code patch, certain components needed to check them, and specifications for fuzz tests it could not prove. Those materials should let outside researchers inspect the claims and assess the proof pipeline. The source does not set a schedule for further releases or describe an independent evaluation.
The next useful evidence will include the handling of reported bugs: which issues have been confirmed by maintainers, which have been fixed, and whether fixes are available to users. Further work would also need to show how the method performs on other architectures and software configurations, and whether token and computing costs fall enough for broader adoption.
As an affiliate, we earn on qualifying purchases.
Key Questions
What did Claude prove?
Anthropic and Theorem say Claude generated Rocq proofs that specified compiled RISC-V programs for 239 fuzz-test entry points do not crash on inputs under 64 MB, under the models and assumptions used.
Does this mean the libraries are bug-free?
No. The proofs cover particular binaries, entry points, properties and input bounds. They do not establish that every version or configuration is free of bugs.
How did the work use fuzz tests?
The existing tests were treated as specifications for whether a compiled program crashes. Claude generated proofs, and the Rocq proof checker checked them against the formal specification.
Why did the project report finding bugs fuzzers had missed?
Fuzzers test selected inputs and execution paths. A successful proof must account for all behavior within its specified model, which can expose rare paths or input conditions that testing did not reach. The project’s reported bug count has not been independently verified in the supplied source.
Do the results apply to software people run on ordinary computers?
Not directly in every case. The described proofs cover single-threaded static RISC-V binaries linked against musl. The source says they do not establish the same results for common x86 or ARM builds linked against glibc.
Source: ThorstenMeyerAI.com
Fall Picks
fall essentials
As an affiliate, we earn on qualifying purchases.
