Anthropic's FlashProve: what 72x overhead and a 1,024-token cap mean for proving which model answered you

TL;DR

This week Anthropic published FlashProve (coverage dates it November 2 to 3), an open-source (Apache 2.0) prototype that lets a model provider prove that a specific reply was produced by a specific set of committed weights, without revealing the weights. On a 400B-parameter mixture-of-experts model (Llama 4 Maverick, 4-bit weights), one H100 proves about 110 tokens per second, a proof for a 1,024-token request is about 19 MB, and a CPU checks it in about 17 seconds. The previous open-source system the authors compare against needed a 93.6 GB proof and almost a day to verify.

The numbers are a large step, but the limits matter more than the speedup. The proof covers an integer model under greedy decoding, the context is capped at 1,024 tokens, and proving costs roughly 72 to 95 times the GPU time of plain inference. My own arithmetic, using an assumed H100 rental rate, puts proving at around $6 per million tokens against a few cents for the plain run. That rules out proving every chat turn, but it makes random audits cheap: proving 300 sampled requests costs a provider under $2 in this illustration.

All FlashProve figures below come from Anthropic's research page and were cross-checked against press coverage. Everything labeled "illustrative" or "my arithmetic" is derived by me and depends on stated assumptions.

What did Anthropic actually release?

The research post is titled "Progress on provable inference for large language models" and sits at anthropic.com/research/provable-inference. The code, protocol description, technical report and Lean proofs are in the anthropics/FlashProve repository under Apache 2.0. Anthropic calls it a research prototype and says it is not deployed on its own API. TechCrunch's report adds that no production deployment has been announced.

The mechanism is a zero-knowledge succinct argument (a zkSNARK). The provider does a one-time offline step that commits to the model weights. That commitment is about 6.5 MB and took about 39 minutes to generate, and the report says one commitment is good for roughly 16 million requests. For each request, the provider can then produce a proof that the committed model, evaluated on the given prompt, yields exactly the claimed output tokens. Anyone holding the commitment, the prompt and the response can run the verifier. They need no access to the weights and no GPU.

How fast is it compared with the previous system?

The authors tested a 400B mixture-of-experts model with about 17B active parameters per token, using public 4-bit weights converted to an integer representation. Their headline numbers:

The throughput gap is about 5,500x and the proof-size gap is about 5,000x, using the reported figures. A quick consistency check on the reported numbers: 24 requests of 1,024 tokens proved in about 223 seconds works out to 110 tokens per second, and 0.02 tokens per second means about 14 hours for 1,000 tokens, which matches the "over 14 hours" figure that press coverage quotes for the older system.

What does proving cost per token, and per request?

Proofs are generated after the fact, in parallel batches, so the live reply is not slowed, though the proof arrives later. The cost is GPU time. At the reported rate, one 1,024-token request consumes about 9.3 H100-seconds of proving. I do not know what any provider pays for an H100, so the dollar figures below assume three rental rates. Change them to your own.

TOKENS_PER_REQ = 1024
BATCH, BATCH_SECONDS = 24, 223   # reported: 24 requests proved in about 223 s on one H100
OVERHEAD = 72                    # reported: about 72x vLLM GPU time

prove_tok_s = BATCH * TOKENS_PER_REQ / BATCH_SECONDS
print(f"proving throughput : {prove_tok_s:.0f} tok/s")
print(f"H100-seconds/request: {BATCH_SECONDS / BATCH:.2f}")
for rate in (1.5, 2.5, 4.0):     # ASSUMED rental price, USD per H100-hour
    prove = 1e6 / prove_tok_s / 3600 * rate
    print(f"${rate:.2f}/h: prove 1M tokens ${prove:.2f} | plain (prove/{OVERHEAD}) ${prove/OVERHEAD:.3f}")

Output:

proving throughput : 110 tok/s
H100-seconds/request: 9.29
$1.50/h: prove 1M tokens $3.78 | plain (prove/72) $0.053
$2.50/h: prove 1M tokens $6.30 | plain (prove/72) $0.088
$4.00/h: prove 1M tokens $10.08 | plain (prove/72) $0.140

The "plain" column divides the proving cost by the reported 72x. That is a rough implied figure, because the 72x comparison uses vLLM under its own configuration and the 94x figure comes from a different setup. It is useful for orders of magnitude only: proving costs dollars per million tokens where ordinary serving of a 4-bit model costs cents.

Is checking a proof cheap enough to do at scale?

Verification takes 17 seconds on 24 threads and 21 seconds on one thread. Those two numbers say the verifier barely parallelizes, which is useful: if proofs are independent, a 24-core machine could run 24 single-threaded checks at once. My arithmetic, which assumes the 21-second figure holds when 24 checks run side by side (I have not tested that), gives about 1,170 verified tokens per second per 24-core box. Checking is far cheaper than proving, and it needs no weights, so a customer, an auditor or a regulator can do it.

What does a proof not tell you?

This is where the headline can mislead, so it is worth listing the limits that the research page itself states.

1. Greedy decoding only. The proof is about an integer model under greedy decoding, meaning the single most likely token at each step. Chat products that sample with a temperature are outside the scope.
2. A quantized artifact, not your serving stack. If a provider serves a floating-point build, the report warns that its outputs may deviate from the integer model that was proven. The proof speaks about the committed integer model.
3. 1,024 tokens of context. Prompt plus response must fit. Agent traces, long documents and retrieval-heavy prompts do not.
4. Mixture-of-experts assumed. The system assumes the served model is a mixture-of-experts architecture.
5. Weights hidden, architecture visible. The proof reveals the architecture, not the weights.
6. Lean covers the theory. Completeness, soundness and zero knowledge are stated and proven in Lean. The fast C++ verifier does not carry a formal guarantee, so the chain from paper to Lean to production code is not formally closed.

There is also a point the proof cannot settle by itself, and it is my own reading rather than a claim from the report. A proof binds a response to a commitment. It does not bind the commitment to a marketing name. For "this came from the model you paid for" to mean anything, someone you trust has to publish which commitment belongs to which product, which is how TechCrunch describes the fingerprint idea. Without that anchor, a provider could prove a perfectly valid statement about a cheaper model.

Which uses fit today?

The audit case deserves a number. Suppose a provider swaps in a cheaper model on a fraction p of requests, and every swapped answer differs from what the committed model would have said. A customer who later asks for proofs on n random requests catches at least one swap with probability 1 - (1 - p)^n. With p = 1% and n = 300, that is 95.1%. The provider's cost to prove 300 requests is about 0.77 H100-hours, roughly $1.94 at the assumed $2.50 per hour. The caveat is that the provider does the proving, so a refusal or a mismatch is itself the signal, and the whole scheme only covers traffic that meets the greedy, 1,024-token conditions.

Anthropic also describes a separate prototype that signs its own inference traffic and recomputes inference on a trusted server, which it says met an internal goal due at the end of September. That route has no proving overhead but requires trusting the recomputing server, so the two designs trade differently.

Frequently asked questions

Does FlashProve let me check that a chatbot answer came from a specific model?
Only under narrow conditions today: greedy decoding, at most 1,024 tokens of prompt plus response, a mixture-of-experts model, and a provider who has published a commitment you can match to the product.

How big is a FlashProve proof and how long does it take to verify?
About 19 MB (18.78 MB) per 1,024-token request, checked in about 17 seconds on 24 CPU threads or 21 seconds on one thread, with no GPU needed.

How much more expensive is proving than running the model?
The report gives about 72 times the GPU time of vLLM in typical conditions and about 94 times at the highest load tested. With an assumed $2.50 per H100-hour, my arithmetic gives about $6.30 per million tokens to prove.

Does the proof reveal the model weights?
No. The provider commits to the weights, and the proof is zero-knowledge with respect to them. The architecture is not hidden.

Is FlashProve ready for production?
Anthropic describes it as a research prototype, it is not deployed on its API, and no production deployment has been announced.

Sources

• Anthropic research: Progress on provable inference for large language models, primary source for all FlashProve figures
• anthropics/FlashProve repository, Apache 2.0 code, protocol description and Lean proofs
• TechCrunch, November 3, 2026, deployment status and the fingerprint idea
• The Decoder, cross-check of throughput, proof size, verification time and the earlier system
• Interesting Engineering, cross-check of hardware, license and limits

Further reading

• Can two Mac Studios really run an 816B model? A bandwidth roofline check on Muse Spark Open
• Shorter outputs, same price: what DeepSeek V4.1-Flash-1017 changes in an agent's bill