Anthropic Open-Sources FlashProve for AI Model Proofs | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
Anthropic Open-Sources FlashProve for AI Model Proofs
The research prototype can prove that a response came from committed model weights, but its substantial computing costs keep it far from an everyday Claude feature.
Anthropic has released FlashProve, an open-source research prototype utilizing zkSNARK cryptography to verify that specific model weights generated a given AI response without exposing those weights. By committing to a model identity, providers can prove their output authenticity, preventing unauthorized model substitution. However, the technology is currently impractical for widespread deployment due to significant overhead. Generating proofs requires massive compute resources, including NVIDIA H100 GPUs and hundreds of gigabytes of RAM, with processing costs 70 to 90 times higher than standard inference. Consequently, FlashProve is best suited for high-value auditing rather than real-time chat verification.
Anthropic has released FlashProve, an open-source research prototype that lets an AI provider prove which model produced a response without revealing the model’s weights. The release includes executable code, a technical protocol specification and a Lean formalization, giving researchers something they can inspect and run.
The primary research post, dated November 2, 2026, targets a practical trust problem: an API’s model label is a claim made by the provider. A customer cannot reliably tell from an answer whether a router silently substituted a cheaper model, or whether an evaluator received a different model from the one customers use.
FlashProve offers a cryptographic way to check that claim. It is not a Claude product rollout. TechCrunch’s November 3 report says the research remains ongoing, with no plans announced to deploy it at Anthropic or another lab.
What Anthropic Released
Anthropic’s release contains five parts: the research announcement, a technical report, a protocol specification, executable software, and Lean proofs with an interactive theorem visualizer. The software includes a prover, a fast C++ verifier and a formally verified Lean verifier.
The code, proofs and documentation are available under Apache 2.0. Anthropic describes the work plainly:
“This research post is meant to share intermediate progress, and not a completed research agenda.”
That qualification matters. The FlashProve repository identifies version 0.16.0 as a research artifact that is “not maintained, not accepting contributions.” Open-source availability gives others permission to inspect and extend the work; it does not come with an ongoing maintenance commitment.
My view is that the useful advance is the combination of executable software and an inspectable security argument. Researchers can examine both what the implementation does and what the protocol claims to guarantee. Neither artifact alone would provide the same starting point for scrutiny.
How Commit, Prove and Verify Works
FlashProve separates the provider’s work from the customer’s check. Its documented workflow has three stages:
Commit. The provider publishes a commitment ID that binds it to one set of model weights. Those weights remain private.
Like this article (0 likes)
Save article
Prove. The provider’s GPU generates a proof that a specified response came from the committed model.
Verify. A verifier checks the proof against the commitment and request-related data, without possessing the weights or rerunning the model.
The underlying technology is a zkSNARK, a cryptographic proof system that can establish a computation’s validity while hiding private information used in that computation. Here, the private information includes the model weights.
Consider a routing service that promises access to Model A. If the provider commits to Model A’s weights and a customer checks responses against that commitment, substituting Model B should prevent the provider from producing an accepted proof under the protocol’s security guarantees. The response might look convincing, but its wording would no longer be the basis for trusting its origin.
There is still an important identity step outside that computation: customers need a trusted association between the commitment ID and the advertised model. A proof can bind an answer to particular weights; it cannot independently decide whether those weights deserve a commercial name such as “Model A.”
For auditors, that distinction suggests a concrete requirement. Preserve the commitment associated with the model being evaluated, then verify later responses against that same commitment. Accepting whichever ID accompanies each answer would miss the continuity check that makes substitution detectable.
The Performance Numbers Need Their Conditions
Anthropic reports results for Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model, using 4-bit quantized weights and integer arithmetic during prefill. The repository describes a 1,024-token context window and a throughput configuration of 24 requests per batch.
These are Anthropic’s published measurements, not independent benchmarks.
The 110 tokens per second figure is prefill throughput, not an ordinary chatbot output-speed claim. Prefill processes an input token sequence; generating a reply token by token is a different workload. Likewise, a quantized mixture-of-experts result cannot be carried over to an arbitrary dense model or proprietary frontier architecture.
The GPU-time comparison is the bigger operational constraint. A 72–94-fold increase means proving consumes vastly more accelerator work than the comparison inference runs. It should not be read as an exact multiplier for user-visible latency or a cloud bill: batching, hardware utilization, storage and deployment design would all affect those outcomes. Production operating costs remain unknown.
Proof transfer also adds up. At the reported size, 1,000 comparable requests would produce about 18.8 GB of proof data, using decimal units and excluding other traffic. That is a straightforward extrapolation from Anthropic’s measurement, not an observed deployment result.
I’d treat selective verification, such as a limited set of high-value evaluations, as a more plausible early application than attaching proofs to every casual chat response. That judgment follows from the published compute and data overhead, not from an announced deployment strategy.
What the Security Proof Covers
FlashProve aims to hide model weights, not model architecture. A company considering it would therefore need to distinguish between protecting its trained parameters and keeping the model’s overall design confidential.
The repository says the protocol’s soundness is proved in Lean 4. It gives an approximate false-acceptance bound of:
q / 2^124 + 2^-101
Here, q represents the number of hash queries. Under the protocol’s stated assumptions, this bounds the chance of accepting an output that is not from the committed model. It is not a probability that the model’s answer is factually wrong.
That difference defines the system’s value. A verified response can still contain a hallucination, unsafe advice or poor reasoning. The proof addresses which committed computation produced the response, not whether the response deserves confidence.
Formal verification also has a specific scope. Anthropic describes top-level auditable mathematical statements and supplies a Lean verifier alongside the faster C++ verifier. Those artifacts make the security reasoning inspectable; they do not turn every surrounding service component into formally verified software.
What Developers Can Try Now
The easiest documented entry point is verifying a stored example proof. The README lists Linux, Bash and g++ 13 or later, with under 2 GB of RAM, for that route.
From an existing repository checkout’s root, it documents this build command:
verifier/build.sh
The script builds the verifier. The supplied example can then be checked with:
The README says successful verification ends with YES and exit code 0. Crucially, that example uses a small model with synthetic weights. Checking it demonstrates the example-verification workflow, not the identity of a model behind a live API.
The README estimates under two seconds for checking this stored example. That is a different workload from the approximately 17-second verification measurement above, so the figures should not be treated as interchangeable.
Generating proofs requires much more hardware. The supported prover platform includes:
An x86-64 Linux machine with CPU SHA extensions.
A dedicated NVIDIA H100 with 80 GB of GPU memory.
CUDA 13.2 Update 2, specifically nvcc 13.2.86.
GCC and g++ 13, with working files on local disk.
For the real Maverick-weight route, the README additionally lists 330 GB of system RAM, 245 GB of disk space, a 232 GB model download, and a calibration set the user must prepare. “One H100” is therefore not a complete description of the machine needed.
These requirements make FlashProve accessible as research software, but not lightweight infrastructure. Developers can start by inspecting and verifying the supplied artifacts; evaluating full-scale proving requires a substantially larger commitment.
Frequently Asked Questions
3 questions
1
Can FlashProve Verify Claude Responses Today?
It is not an announced Claude or Anthropic API feature. The released benchmark and repository focus on a specific Llama 4 Maverick configuration, and no production deployment plan has been announced.
2
Does FlashProve Reveal the Model’s Weights?
The protocol is designed to keep weights private while proving that a response came from the committed model. Hiding the model architecture is not its goal.
3
Does a Valid Proof Mean the Answer Is Correct?
No. It verifies the response’s connection to the committed model computation. Factual accuracy, safety and usefulness still require separate evaluation.
