Provable inference: Anthropic's FlashProve proves which model answered, at 70 to 95 times the cost

Provable inference is a way to check that an AI answer really came from the model a provider says it used, without seeing the model's weights. On November 2, 2026, Anthropic's Frontier Red Team published FlashProve, an open-source prototype that does this with zero-knowledge proofs. It works today on one mid-sized model, at roughly 70 to 95 times the GPU cost of ordinary serving, so it is a proof of concept for a policy idea, not a product.

What provable inference means

When you call a hosted model, you trust the provider. A company could quietly swap in a cheaper model to save money, or serve a stronger one only when it knows it is being benchmarked. Today, nobody outside the company can prove which one answered.

The FlashProve post, by Roy Rinberg, Alex Allain and colleagues from Anthropic, EPFL and MIT, describes a different arrangement. The provider publishes a short cryptographic commitment to its model weights, which pins down one exact set of weights while keeping them hidden. For each request, it then produces a proof that the committed model generated the given output tokens from the given prompt. Anyone holding the commitment, the prompt and the reply can check the proof on an ordinary CPU.

The post says the system is "an open-source performant prototype for provable inference." It also states that "the proof itself reveals nothing about the weights of the committed model." The authors note that "hiding the architecture of the model is not a goal of this system," so the shape of the network stays visible while the numbers inside it do not.

The numbers from the post

The demonstration uses Llama 4 Maverick, a 400 billion parameter mixture-of-experts model with about 17 billion parameters active per token, using public 4-bit weights of about 232 GB. These are the figures Anthropic reports:

• Prover speed: about 110 tokens per second on one H100 GPU.
• Proof size: about 18.78 MB per proof, which the post rounds to about 19 MB for a 1,024-token request.
• Setup: about 39 minutes, done once per model.
• Batch proving: about 223 seconds for a batch of 24 requests.
• Verifier: about 17 seconds on 24 CPU threads, or 21 seconds on one thread, plus about 6.5 MB for the commitment.
• Overhead: roughly 70 to 95 times the GPU time of the vLLM serving software, depending on load.

The GitHub repository adds practical detail. It lists the prover as supported only on a single NVIDIA H100 80 GB with a specific CUDA release, and the full Maverick run needs 330 GB of RAM and a 232 GB weight download. Verifying is far cheaper: the verifier builds in a minute or two on a machine with under 2 GB of RAM.

Why a red team built it

The post lists use cases that go beyond catching a cheating vendor. It says provable inference "has implications for pacing the frontier of AI development and for AI regulation," because "some proposals to regulate and pace AI development rely on monitoring hardware and how it is used." It adds that "regulation might require providers to serve only models approved as safe."

That is the link to the superintelligence race. Governance proposals, from testing regimes to pauses, all assume someone can verify what is running. The White House testing framework we covered in our reporting on the withheld model-testing document depends on knowing the tested model is the deployed model. A proof that binds each request to a specific approved model is one possible building block. The post is careful to say the proof "will not verify if the provider is using an unapproved model" unless the commitment is tied to an approval list, so it needs a policy layer around it.

TechCrunch's Russell Brandom, who reported on the release, added that the researchers describe the work as intermediate and that Anthropic has no plans to deploy it at Anthropic or any other lab.

The limits are large

The authors are blunt about them, and the list is long.

• Integer model, greedy decoding. In the post's words, "The proof is about an integer model under greedy decoding." Real chat products sample their outputs and run in floating-point arithmetic, so the proven computation can differ from what a user sees.
• Short context. Proofs cover contexts up to 1,024 tokens, far below typical chat sessions.
• No guarantee the fast code matches the proofs. The core properties are stated and proven in the Lean language, but the post says the Lean protocol, the paper and the fast C++ code are not guaranteed to match each other.
• Side channels. Timing attacks during proof generation are out of scope.
• Unmaintained code. The repository's README calls the project a research artifact that is "not maintained, not accepting contributions." That is a signal about what Anthropic intends: a published idea, not a service.

The security claim in the README is specific. It says a provider passing off output that is not the committed model's is caught "except with probability about q/2^124 + 2^-101 after q hash queries." That is a strong bound on paper. It does not cover the gaps above.

How this fits with other provenance work

Provable inference answers a different question from text watermarks. A watermark marks that a model made a passage. A proof shows which model made it, and that the claimed weights ran. For the watermark side, see our look at Claude's text watermark and its sampling loophole.

The post also separates this project from another Anthropic prototype that signs inference traffic and recomputes it on a trusted server. That approach is cheaper but depends on trusting the server.

Our take

Treat FlashProve as evidence that a verification layer for frontier AI is technically imaginable, which was not obvious a year ago. Do not treat it as a way to audit GPT-class or Claude-class models today. A 70 to 95 times cost multiplier, a 1,024-token limit and an unmaintained repository rule out production use. The thing to watch is whether a regulator, a cloud, or a rival lab adopts the idea and funds the engineering. Until one does, this is a well-argued sketch with working code.