Anthropic's FlashProve proves which committed weights produced a model's output, with one token checked per proof

Anthropic's Frontier Red Team and co-authors from EPFL and MIT published FlashProve on Nov 2, an Apache 2.0 research prototype for provable inference. The provider first publishes a commitment to the model weights, a short fingerprint that keeps the weights hidden. For each request it then produces a zkSNARK proof of the statement "The committed model produces these output tokens when evaluated." On Llama 4 Maverick (400B-parameter mixture of experts, 4-bit weights), one H100 proved a batch of 24 requests in about 223 seconds, or 110 tokens per second, at 18.78 MB per proof. Each request was a 1,024-token window and each proof checked one token. A client downloads the ~6.5 MB commitment and checks a proof in 17 seconds on 24 CPU threads. Per GPU, proving took about 72 times as long as vLLM needed for the same 24 requests, and about 94 times at vLLM's highest tested load. Anthropic says Claude produced improvements on zkSNARKs for inference and built a system substantially faster than prior open-source ones. The release includes a fast verifier in C++, a verifier in Lean and Lean proofs of the security properties. Why it matters: When you call a model through an API or a reseller, you cannot check that the model you picked is the one that answered. A router could swap in a cheaper model, and an attacker could tamper with the reply. FlashProve shows one way to check, on a large open model, without the provider giving away its weights. The prototype has narrow limits. It works only for mixture-of-experts models, contexts of up to 1,024 tokens and greedy decoding, and Anthropic does not guarantee that the fast C++ code matches the Lean proofs. The GitHub repo calls itself "Not maintained", and TechCrunch reports no plans to deploy it at Anthropic or any other lab. Anthropic says it met its own Sept 30 goal for this through a separate project that signs its traffic and recomputes inference on a trusted server.

Try this: Pick one model you reach through a router or reseller. Check that provider's docs for any proof of which model answered, beyond a model name in the response. Then open the FlashProve repo and list what a provider would have to publish for you to verify a reply: a weight commitment and a proof per request. To watch a verifier run, follow the repo's route 1. It builds cp_verify and checks a stored example proof on a CPU with under 2 GB of RAM, and the README says that example uses a small synthetic model, so it shows only that the verifier works.