When you pay for “Claude Opus” or “GPT-6” through an API, how do you know that model actually answered you, and not a cheaper one swapped in to save money? Right now you cannot check. Anthropic has published an open-source research prototype called FlashProve that tries to fix this with cryptography. It attaches a zero-knowledge proof to a model’s output that shows which model produced it, without revealing the model’s weights. It is far from ready for real chatbots, but the numbers are a big jump over earlier attempts. Here is how it works, what it can and cannot do, and why it matters for anyone who uses AI APIs or local models.
- What: FlashProve, an Anthropic research prototype for “provable inference”. Open source (Apache 2.0) on GitHub.
- How: the lab publishes a fingerprint of a model; each response comes with a zkSNARK proof that it was produced by the fingerprinted model. Weights stay secret.
- Numbers: ~110 tokens/s proving on one H100 for Llama 4 Maverick (400B); 19 MB proofs; ~17 s to verify on a normal CPU.
- Before: the best earlier open system needed 14+ hours for 1,000 tokens and made a 93.6 GB proof.
- Limits: 70-95x overhead, 1,024-token contexts, greedy (most-likely-token) sampling only, architecture not hidden.
- Status: research only. Anthropic says there are no plans to deploy it yet.
The Problem: You Cannot Prove Which Model Answered
Every time you call a model through an API, a reseller or a “free GPT” website, you are trusting the provider. There are real ways this trust can break:
- A provider quietly routes some traffic to a smaller, cheaper model to cut costs.
- A reseller claims to serve a top model but serves a weaker open model.
- A service quantizes a model heavily and keeps selling it under the full name.
- A company claims a task or a benchmark run was done by a specific model, and nobody can check.
Anthropic compares the goal to DKIM, the signatures that let mail servers check an email really came from the domain it claims. FlashProve wants the same kind of check for AI output, and it is designed to resist cheating even by the lab that built and runs the model.
How FlashProve Works
In plain terms:
- The lab publishes a fingerprint of its model weights. The fingerprint does not reveal the weights, so closed models can take part.
- When the model generates a response, the provider also produces a zkSNARK, a compact cryptographic proof that “this output came from running the model with that fingerprint on this input”.
- Anyone can verify the proof on an ordinary computer, without access to the weights.
Zero-knowledge proofs for neural networks are not new, but they have been far too slow to be useful. FlashProve’s contribution is speed.
The Numbers
| Metric | Best earlier open system | FlashProve |
|---|---|---|
| Model tested | – | Llama 4 Maverick (400B) |
| Proving speed | 14+ hours per 1,000 tokens | ~110 tokens/s on one H100 |
| Proof size | 93.6 GB | ~19 MB |
| Verification time | Nearly a full day | ~17 s on a standard CPU |
| Overhead vs normal inference | – | ~70-95x |
Going from a 93.6 GB proof to 19 MB, and from a day of verification to 17 seconds, is the kind of jump that turns a paper idea into something you can imagine shipping in a few years.
What It Cannot Do Yet
- Short contexts only: proofs currently cover contexts of up to 1,024 tokens. Real chats and agent runs are often 100x longer.
- Greedy sampling only: it works when the model always picks the single most likely next token. Normal chatbots use randomized sampling (temperature), which is not supported yet.
- Expensive: 70-95x overhead means proving every response would multiply serving costs.
- Architecture is visible: the weights stay hidden, but the model’s structure does not.
- Needs buy-in: it only works if labs publish fingerprints, and Anthropic says there are no plans to deploy it at Anthropic or anywhere else yet.
How to Try FlashProve Yourself
The code is on GitHub (version 0.16.0 at the time of writing, Apache 2.0). Anthropic states clearly that the repository is a research artifact: it is not maintained and does not accept contributions. Its security argument is machine-checked in Lean 4, with a stated cheating probability of about q/2^124 + 2^-101 after q hash queries. The README offers four routes, from “verify a proof on a laptop” to “prove a real 400B model”:
| Route | What it does | What you need | Time |
|---|---|---|---|
| 1. Verify a stored proof | Builds the cp_verify tool and checks an example proof |
Linux, bash, g++ 13+, under 2 GB RAM | Build 1-2 min, check under 2 s |
| 2. Toy proofs | CPU self-test of the proof library | Route 1 plus make and python3 | About 1 min |
| 3. Small model | Commit, prove and verify an 8-layer synthetic model | One dedicated H100 80 GB, CUDA 13.2, 10 GB RAM | Build ~29 min, run 23-30 s |
| 3. Full size | Llama 4 Maverick shape with synthetic weights, 1,001 tokens | H100 stack, 280 GB RAM | About 42 min |
| 4. Real Llama 4 Maverick | Proves a token with a public 4-bit conversion | H100 stack, 330 GB RAM, 245 GB disk, Python 3.13, your own calibration set | Hours |
Route 1 in three commands (on Ubuntu 24.04, as a normal user):
sudo apt-get update && sudo apt-get install -y --no-install-recommends g++ make python3 unzip
verifier/build.sh
bin/cp_verify examples/accepted-proof/config examples/accepted-proof/ivk \
examples/accepted-proof/example.req examples/accepted-proof/example.y \
examples/accepted-proof/example.proof -id "$(cat examples/accepted-proof/ID.txt)"
The build should print a line starting “THE VERIFIER IS BUILT:”, and the last line of the check should be YES with exit code 0. That example uses synthetic weights, so it only proves the verifier works, not anything about a real model.
Reading the verdict: exit code 0 with YES (or WITHIN LIMITS) means accepted; 1 with NO: <name> means rejected; 5 with NOT CHECKED means no verdict; 14 means the call itself was invalid. One important rule from the README: get the model’s commitment ID from a party you trust, never from the server you are checking, otherwise a cheating provider could hand you a matching fake.
GPU proving runs only on one platform: x86-64 Linux with SHA CPU extensions, a single H100 80 GB not shared with other jobs, CUDA 13.2 Update 2 and gcc 13. The quick start is examples/quickstart-gpu.sh, which commits, proves a 64-token request and verifies it; it can run silently for more than 15 minutes. Note that the headline 110 tokens per second is prefill throughput at 24 requests per batch, not interactive chat speed.
FlashProve vs Other Ways to Check a Model
| Method | How it works | Strength | Weakness |
|---|---|---|---|
| Your own evals | Run a fixed test set against the API and compare scores over time | Cheap, works today | Catches big swaps only; a provider can detect and special-case test prompts |
| Output fingerprinting | Look for statistical quirks in a model’s answers | No cooperation needed | Probabilistic, easy to blur with quantization or fine-tuning |
| Trusted hardware (confidential computing) | The GPU or CPU attests which code and weights it loaded | Low overhead | You must trust the chip vendor and the attestation chain |
| FlashProve (zero-knowledge proofs) | Each answer carries a cryptographic proof tied to a published commitment | Mathematical guarantee, weights stay secret, verifier runs on a normal CPU | 70-95x overhead, 1,024-token contexts, greedy sampling only, research code |
| Run it yourself | Download open weights and run them locally | Total certainty and privacy | Only for open models, needs your own hardware |
For most people today, the last row is the practical one. If you need certainty about which model you are using, run an open model on your own GPU; our best Ollama models by VRAM list is a good place to choose one.
Why It Matters to You
For API users and businesses, provable inference would end the guessing game over whether a provider is serving what you pay for. That matters more as model prices fall and the gap between a frontier model and a cheap substitute shrinks to something users cannot see by eye.
For the local and open-model community, it matters too. Hosted “Llama” or “Kimi” endpoints vary widely in quantization and quality, and today the only check is running your own evals. A future version of this could let open-model hosts prove they run the exact weights they advertise. Until then, the safest way to know which model answered is to run it yourself; our guides to installing Ollama and Ollama vs LM Studio vs llama.cpp are a good start.
My Take
This is early research, and Anthropic says so plainly. But the problem is real, the code is open, and the speed-up is dramatic. The two limits that matter most are the 1,024-token context and greedy-only sampling; when those fall, expect regulators and big API buyers to start asking for proofs. It also fits a wider trend this week: verifying AI behaviour is becoming its own product category, alongside things like CrowdStrike’s new AI agent kill switch.
Frequently Asked Questions
What is FlashProve?
An open-source Anthropic research prototype that uses zero-knowledge proofs (zkSNARKs) to prove which AI model produced a response, without exposing the model’s weights.
Is FlashProve used in Claude today?
No. Anthropic describes it as intermediate research and says there are no plans to deploy it at Anthropic or other labs yet.
Where is the FlashProve code?
On GitHub at anthropics/FlashProve, under the Apache 2.0 licence, with Lean proofs and documentation.
Can I use FlashProve with a local model?
In principle the code works on open models (it was tested on Llama 4 Maverick), but it needs an H100-class GPU for proving and only supports short, greedy-decoded outputs, so it is a research tool, not a home tool.
What hardware does FlashProve need?
Verifying a proof needs only an ordinary Linux machine with under 2 GB of RAM. Producing proofs needs one dedicated NVIDIA H100 80 GB with CUDA 13.2, and up to 330 GB of system RAM for the full Llama 4 Maverick route.
Is FlashProve maintained?
No. Anthropic published it as a research artifact (version 0.16.0) and says it is not maintained and not accepting contributions.
Does FlashProve work with ChatGPT-style random sampling?
Not yet. It only supports greedy decoding, where the model always picks the most likely next token, and contexts up to 1,024 tokens.




