The image generated by AIYXL using AI
Anthropic released a research prototype on November 2 that uses zero-knowledge proofs to verify inference against committed model weights. Its Llama 4 demonstration shows what can be checked and how much proving still costs.
A model name on an API response tells customers what the service says it ran. Anthropic’s FlashProve asks what those customers could verify for themselves. On November 2, the company published research and released prototype code for checking whether a response matches the computation of a model whose weights the provider had committed to.
A claim a verifier can check
FlashProve uses a zero-knowledge proof. A provider commits to specific model weights and produces evidence that the checked output follows from them. A verifier can check that evidence without receiving the weights. The commitment still needs a trustworthy association with the model version a customer intended to use. A proof can establish the computation covered by that commitment; whether the answer is accurate or suitable for the task calls for separate evidence.
That distinction matters when requests pass through a model gateway. In an audit, a customer might want to know whether a request followed the agreed routing policy. A proof tied to a known commitment could give the customer a way to check a particular inference claim independently of the gateway’s own logs.
The work behind the proof
Anthropic reports about 110 tokens per second of proof generation on one H100 GPU in a demonstration with a four-bit version of Meta’s Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model. The reported proof was around 19 MB for a 1,024-token request. The researchers measured roughly 70 to 95 times the GPU time of ordinary inference with vLLM under their comparison conditions. The throughput figure describes proving in that setup. A deployment would also need to budget for storing, transferring and verifying proofs.
FlashProve generates proofs after inference. That design lends itself to thinking about sampled audits, where a team could choose which requests to verify and accept a delay before receiving the evidence. The suitability of that approach would depend on the audit’s coverage requirements and on how well the audited path represents the live service.
Where the guarantee stops
The prototype checks an integer version of the model using greedy decoding, where each step chooses the highest-scoring token. A sampled reply or one produced by a floating-point implementation can diverge from that path. The research also reports a context limit of 1,024 tokens for proving, and the authors distinguish their formal work in Lean from the guarantees available for the fast executable code.
For a team evaluating the technique, a concrete next test would be to pick a model version, an inference configuration and a set of representative requests, then check which outputs the verifier can cover. That exercise would put a number on how much of a real workload can be audited with the prototype as released.