Anthropic FlashProve: Proving a 400B Model Produced Your Answer, at 110 Tokens a Second

Anthropic has released FlashProve, an open-source system that lets a user check that an AI response was produced by one specific, committed set of model weights, without seeing the weights. On Llama 4 Maverick, a 400B-parameter mixture-of-experts model, a single H100 produces proofs at about 110 tokens per second. Each proof for a 1,024-token request is about 19 MB. Anthropic's research post, dated November 2, 2026, gives the cost plainly: about 70 to 95 times the GPU time of running the same prompts on vLLM.

That makes provable inference a measured engineering trade-off instead of a thought experiment. The same post lists what the system does not do yet, and those limits matter as much as the speed. It follows the roadmap update we covered in Anthropic's Frontier Safety Roadmap: signed token traffic and inference verification, where Anthropic said it had a prototype by a different route.

Everything below comes from Anthropic's research post. The numbers are Anthropic's own measurements; we did not rerun the code.

TL;DR: what FlashProve is, in one table #

Agents that act on your behalf need rules. See how explainx helps secure your agents →

What problem does provable inference solve? #

When you call a model API, you see only text. You cannot check that the answer came from the model you chose. Anthropic names three cases where that gap hurts.

First, independent evaluators who test a model before and after release need to know the tested model is the served model. Second, customers who buy through a routing service want assurance the tokens came from the model they paid for, not a cheaper substitute. Third, an attacker who tampers with the token stream while pretending to be a given model leaves no trace in the text.

Checking by rerunning the model fails twice. Frontier weights are private, and rerunning costs far more than a user or auditor can afford. The goal of provable inference is for a user with a laptop CPU and no knowledge of the weights to verify a response in seconds.

The same theme runs through several posts here. OpenAI's activation classifiers and probes try to read a model's internal state for safety. Anthropic's independent-evaluator program, covered in METR's employee-like access, depends on trust that the evaluated model is the real one. Proofs would turn some of that trust into math.

How does a zkSNARK prove an LLM answer? #

A zkSNARK is a zero-knowledge succinct argument of knowledge. The prover convinces a verifier that a computation ran correctly. The certificate is zero-knowledge, meaning it reveals nothing beyond the claim. It is succinct, meaning checking it is far cheaper than redoing the work.

FlashProve works in two phases.

1. Offline phase. The provider publishes a commitment to the weights, a short fingerprint that pins down one exact set of weights while keeping them hidden. This takes about 39 minutes per model on the test machine, and the commitment is good for about 16 million requests before a new one is needed.
2. Online phase. For a prompt and its reply, the prover produces a proof file stating: the committed model produces these output tokens when evaluated. Anyone holding the commitment, prompt and reply can check it.

Anthropic says the proof system follows a standard recipe: an interactive oracle proof is compiled into a cryptographic proof using hash functions, which also gives post-quantum security. The pieces include code proximity tests with linear constraints and lookup arguments. This is the same family of technology used in blockchain scaling networks, which Anthropic notes by name. For another place where this kind of proof meets AI, see Ethereum's zkAPI for private AI API payments.

Shield with an eye as a symbol of how a verifier checks AI responses against a weight commitment in provable inference

The four design choices that make it fast

Anthropic highlights four decisions in its engineering section.

• Work scales with active experts. In a mixture-of-experts model a token uses about 17B of 400B parameters. The prover's work per token follows the 17B that ran, and the proof still hides which experts were chosen.
• Proofs run after the fact, in batches. The prover reads finished text in one parallel pass, like prefill, and opens the weight commitment once per batch.
• Streaming weights fit one GPU. Weights sit in host memory (about 290 GB) and stream in segment by segment, so one 80 GB H100 is enough.
• Integer arithmetic. The proof covers an exact integer version of the published 4-bit weights, which is cheaper to prove than floating point.

How does it compare with earlier zkML work? #

The speed-up is the headline. Anthropic's post describes prior work in prose; we gathered the figures into one table.

| System | What it proved | Reported speed |

|---|---|---|
| zkLLM (2024) | LLaMA-2-13B | About 2.5 tok/s on one A100 | 
| zkGPT (2025) | GPT-2 | 21.8 s | 

| zkPyTorch (2025) | Llama-3 8B | About 150 s per token on one CPU core | | VerInf | Llama 4 Maverick (same model) | About 0.02 tok/s; 14.3 hours for 1,000 tokens on a DGX Spark, 93.6 GB proof | | DeepProve | GPT-2, Gemma 3 | 2.9 and 1.4 tok/s on one machine; 31 tok/s distributed | | Attestable (commercial) | Gemma 4 31B dense | 53 to 77 tok/s on one H100 | | FlashProve | Llama 4 Maverick | About 110 tok/s on one H100, 19 MB proof |

Two cautions apply. These are numbers each team reported, on different models and hardware, and this is a summary of prior work, not a controlled benchmark. And the comparison to VerInf is on the same model, which is the cleanest data point: about 0.02 tokens per second versus 110.

The 70 to 95 times overhead is roughly two orders of magnitude. Anthropic's own measurement: proving a batch of 24 requests took about 72 times longer than vLLM on the FP8 release of the same model (66 to 77 across runs), and about 94 times longer when vLLM ran at its highest load. For readers who care about serving stacks, our guide to vLLM push-based KV transfer for disaggregated inference shows the baseline engine in a production setting.

Why did Anthropic add Lean proofs? #

Cryptographic code breaks easily. A subtle bug can make a "proof" worthless. Anthropic says Claude is "good at optimization" but makes decisions that are hard to evaluate. Its answer is formal verification in Lean, a proof assistant.

The team states three top-level properties in Lean and proves them, in the random oracle model:

• Completeness: an honest proof is accepted.
• Soundness: a fake proof is rejected, except with negligible probability.
• Zero knowledge: the proof reveals nothing about the weights beyond what the response itself implies.

Anthropic is candid about the remaining gaps. A human must still audit that the formal statements match the intent (an interactive visualizer helps). The fast C++ verifier, the one you would use day to day, carries no formal guarantee, though it agreed with the slower Lean verifier on every test proof. For zero knowledge, the prover must be correct, and Anthropic offers no Lean prover because it would be too slow. It expects providers to run security audits there instead.

This is the same pattern as Anthropic's work on formal verification across 123 libraries: let the model do hard engineering, then make the guarantees small enough for people to audit. For another example of Lean checking AI-produced work, see OpenAI's three Lean-checked math results.

Two keyhole gates a key must pass, showing how a proof acts as an access check on which model served a response

What could FlashProve be used for? #

Anthropic frames four challenges. Treat these as its stated motivations, not shipped features.

1. Pacing. Some AI governance proposals monitor hardware and require some of it to serve inference. A regulator could ask for proofs that served requests came from the claimed model. Anthropic adds a caveat: this shows the hardware served inference, not that it was not also training on the side. This links to the pace-of-development framework Anthropic promised in its roadmap, and to its filing language we covered inthe S-1 amendment on accelerated progress .
2. Tamper detection. A compromised inference server could exfiltrate weights or return malicious output hidden among genuine responses. If every response needs a valid proof tied to the committed weights, a substitute model cannot pass. Anthropic even raises a future case where a more capable model runs in place of the authorized one to avoid monitoring.
3. Text provenance. A developer could show a "proof of failure": that a named model spent at least some number of tokens on a code patch and found no bugs. Anthropic gives the example of a model that tried for 1M tokens and found nothing.
4. Model approval. A regulator could require that only approved models are served, and check it cheaply with proofs.

The post also notes trusted hardware as a complementary route. Hardware approaches rely on the chipmaker; software proofs rely on hard math. Anthropic says both will have a role.

What does FlashProve not do? #

The limits section is short and specific. Read it before repeating any headline.

Add the cost. A 70 to 95 times overhead in GPU time is acceptable for audits and spot checks, not for proving every token served to every user. That is why Anthropic emphasizes proving a sample of tokens after the fact.

One more point: the demo model is Meta's Llama 4 Maverick, not Claude. Anthropic says the weights are not part of the release. Readers download a third-party 4-bit conversion from Hugging Face under Meta's Llama 4 license, and running the full example needs a large GPU machine and Meta's tokenizers.

How does this relate to the earlier roadmap claim? #

In its Frontier Safety Roadmap, Anthropic set a goal to build a provable inference prototype by September 30, 2026. The new post says it met that goal through a separate project that signs its inference traffic and recomputes inference on a trusted server. The FlashProve research "pursues the same objective by a different method."

A footnote adds that after the October 19, 2026 update, Anthropic renamed the goal "inference verification" instead of "provable inference," because the second name suggests a narrower approach than the company thinks is necessary. So FlashProve is best read as one candidate route to high assurance in the token stream, published openly so others can improve it.

Anthropic is explicit about intent: "We are sharing this explicitly with the goal that others look at what we have done, take it, and improve it."

What should builders and security teams do now? #

You cannot yet demand a proof from a commercial API. You can still use the ideas.

• Treat model identity as a security property. If you route traffic across providers, log the model identifier the provider returns and compare it with what you requested. Proofs would harden this, but even basic logging catches silent swaps.
• Read the repository and the Lean statements. If you build verification tooling, the executable Lean verifier and the visualizer for top-level theorems are the useful parts to audit first.
• Plan for overhead. If your use case is audit, sample a small share of responses and prove those, since full coverage costs about two orders of magnitude more GPU time.
• Watch the limits that matter to you. Sampled decoding and long contexts are not covered. A claim that "this answer was proven" applies only inside those bounds.
• Add runtime controls for agents. Provenance tells you which model spoke. It does not stop an agent from taking a harmful action. For that,AgentBeam , the agent security platform from the explainx.ai team, stops AI agents before they take dangerous actions.

If you also want to verify media rather than text, see our guide to Google's SynthID verification site.

Why this matters #

Most AI trust claims today rest on a company saying "trust us." FlashProve shows a path where the claim can be checked by someone who trusts only math and a small verifier. Whether it matures into a standard depends on three things: overhead falling further, longer contexts, and broader architecture support. Anthropic reports that a commercial team, Attestable, independently reached 53 to 77 tokens per second on a dense 31B model, so progress is not coming from one lab.

For now it is a prototype with a strong open release: code, a protocol description, a technical report, and machine-checked security statements. The most useful reading is the limits table above. A proof that a 1,024-token greedy decode matches an integer model is a real result, and a small one compared with proving everything a frontier assistant does in production.

Related reading #

Figures are from Anthropic's November 2, 2026 post and may change as the code and technical report are updated.