Anthropic has released FlashProve (v0.16.0, Apache 2.0) — a research prototype for provable inference using zkSNARKs. The API provider publishes a commitment hash of the weights once, without revealing the weights themselves, and attaches a proof to each response that the tokens were generated by the fixed model. The proof can be verified on a standard CPU in seconds without access to the weights; the system remains a research tool rather than a ready-made service.

image

What happened

The Frontier Red Team published the anthropics/FlashProve repository (v0.16.0) on GitHub under the Apache 2.0 license, including code, instructions, and a technical report; the protocol's correctness is separately covered by formal proofs in Lean 4. The mechanics are two-stage: the provider calculates and publishes a commitment hash of the weights approximately 6.5 MB in size once, and then issues a zkSNARK proof of approximately 19 MB for each response, linked to the hash and the specific request. The verifying party only needs the hash, the request, and the response: the verifier runs on a standard CPU and takes approximately 17 seconds on 24 cores (21 seconds on a single core), without requiring access to the weights.

Context

Provable inference has long remained theoretical: zkSNARKs can prove that a specific program performed a computation, but the cost for large language models was prohibitive. The previous benchmark, VerInf, generated proofs at a speed of approximately 0.02 tokens per second with a proof size of 93.6 GB — unsuitable for a live service. FlashProve shifts this economics: on the test model Llama 4 Maverick (400B MoE, 4-bit quantization, 232 GB), preparing the commitment takes about 39 minutes on one H100 plus 24 CPU cores, one hash is amortized over approximately 16 million requests, and generation runs at a speed of about 110 tokens per second on an H100. The protocol is built around the asymmetry of "expensive to prove — cheap to verify": proofs have become thousands of times faster and lighter, moving the topic from an academic to an engineering plane for the first time.

Why this matters for the industry

The industry gains a trust tool that did not previously exist: an LLM-API provider can cryptographically prove to a client that the response was generated by the claimed model, not a substituted cheaper version — a relevant issue for LLM traffic routing, where the internal model choice is hidden behind a single interface. Regulators gain a way to verify that an approved model is being inferred on dedicated hardware, rather than another model being trained or run. The verification side is ready for productization: a CPU verifier, a few seconds to check a response. The obstacle is on the proof side: generation carries a GPU overhead of approximately 70–95x compared to standard vLLM inference, so this is currently a project direction rather than a deployable feature. A reasonable step for teams building API clients for critical processes is to build an optional slot for response origin verification into the architecture in advance, to be enabled when proof costs drop.

Why this matters for users

There is no ready-made service, but everything needed for independent verification is open: the anthropics/FlashProve repository builds on Linux (g++ 13 or newer, less than 2 GB RAM, 1–2 minutes compilation), after which attached proofs can be verified and the commitment and proof file formats can be examined. The protocol specification and formal correctness proofs in Lean 4 are also available. For those building critical processes on LLM-APIs — security, document approval, audit — this is groundwork for how response origin will be proven in the future; the realistic milestone today is experimentation and architecture preparation, not production use.

What is still unknown / limitations

The guarantee is narrow by design: it is valid only for the integer version of the model and greedy decoding, so typical production configurations with sampling (temperature>0) remain outside the proven zone. The context is limited to 1024 tokens, the proof weighs about 19 MB per request, and proof generation carries a GPU overhead of 70–95x compared to standard vLLM inference — the system cannot be deployed in production with such parameters. Formal proofs in Lean 4 apply to the protocol, not automatically to the implementation, so the gap between specification and code must be checked separately. Analogies with TLS are premature: TLS verification does not depend on the content of computations, whereas here the guarantee is tied to integer arithmetic, so the correct formulation today is verifiable inference within given bounds. The published figures were obtained from the team's own tests on Llama 4 Maverick; independent reproductions are not yet available.

Sources

Author

Look at AI, editorial team