QWE AI Academy Skip the launch thread. Clone FlashProve, build the C++ verifier, and get a real YES on a laptop CPU in under five minutes – no GPU, no 400B weights. That single run is the point of this guide. Everything else is context for what that YES does and does not mean.
Anthropic’s Frontier Red Team shipped the open prototype on November 2, 2026 (research post). Code, Lean proofs, and the protocol live under Apache 2.0 at github.com/anthropics/FlashProve. Research artifact, not a product you drop on production traffic.
Verify a stored proof on CPU right now
Route 1 in the official getting-started guide is the only path most readers need today.
- Clone and enter the repo:
git clone https://github.com/anthropics/FlashProve cd FlashProve - Install build deps if needed (Ubuntu):
sudo apt-get update && sudo apt-get install -y --no-install-recommends g++ make python3 unzip - Build:
verifier/build.sh. Quiet for 1-2 minutes, then a line startingTHE VERIFIER IS BUILT:and exit 0. - Check the included honest example:
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)"
Last line: YES. Exit code 0. That only proves the verifier and these synthetic files agree – not a live API. Full-size synthetic proofs (still no GPU) sit under examples/full-size/.
Wrap anything untrusted. Hostile proof files can chew memory or hang with no built-in caps:
( ulimit -v 8388608; timeout 600 bin/cp_verify CONFIG_DIR PUBLIC_KEY_DIR REQUEST_FILE TOKEN_FILE PROOF_FILE -id COMMITMENT_ID )Build the request file yourself so the covered token range is the range you care about. Exit 0 plus that final line together are the verdict. The fast C++ path has no Lean machine-check – only the slower Lean verifier does – so treat cp_verify as reviewed ordinary software.
Think of the commitment ID like a fingerprint on a sealed envelope. The math can say “this letter matches that seal” and still be useless if you accepted the seal from the same stranger who handed you the letter.
What a YES actually buys you
A provider commits offline to one weight set and publishes a short public commitment ID. Later they attach a zkSNARK proof: succinct to check, zero-knowledge on the weights. You need the commitment, the request, the claimed tokens, and the proof. You never re-run the model.
As of the Nov 2026 numbers on public 4-bit Llama 4 Maverick (400B MoE, ~17B active per token), one H100 hits around 110 tokens/s of proving in batches of 24. Proofs land near 19 MB for a 1,024-token window. Verifier time: ~17s on 24 threads, ~21s single-thread. Offline commitment once (~39 min) covers on the order of 16 million requests before leaf tables force a re-commit. Proving cost sits ~70-95× ordinary vLLM GPU time for the same work (batch often ~72×; up to ~94× under heavy vLLM load).
Pro tip: Pull the commitment ID from a party you already trust. Never from the server under test. Never from the proof bundle. A valid proof for the wrong ID still prints YES.
Architecture stays visible – MoE layout included. Weights stay hidden. Side-channel timing and in-line proving are out of scope; this release is post-hoc only.
Pitfalls that bite first-time users
6.81%. That is the share of positions where the integer/fixed-point top token disagreed with a float baseline in one reported measurement (known-limits). Proofs certify greedy or clipped-gap choices on the integer model. Sampling, temperature, and normal float serving will often fail exact-match. If your production stack is float + sample, a failed proof may mean “different engine,” not “tampered weights.”
Context hard-caps at 1,024 tokens. Longer chats do not fit. Leaf tables expire after roughly 16M requests / ~688k batches, so commitments are not forever. Dense non-MoE layouts are not the design target.
How the speed stacks up
| System | Model scale | Approx. prove speed | Proof size / notes |
|---|---|---|---|
| FlashProve (2026) | Llama 4 Maverick 400B MoE | ~110 tok/s (1×H100) | ~19 MB; Apache 2.0 + Lean |
| VerInf | Same model class | ~0.02 tok/s | 93.6 GB; multi-hour verify |
| DeepProve | GPT-2 / Gemma-scale | ~1.4-2.9 tok/s (single) | Full-sequence; open |
| zkLLM-style | ~13B | ~2.5 tok/s batched | Smaller proofs; older circuits |
FlashProve is ~5,000× VerInf on the same class if you take both sides’ reported figures at face value. Hardware and claim boundaries differ – order-of-magnitude only. TEEs still win on overhead for live frontier serving when you want attestation more than pure crypto. FlashProve is the biggest open step at 400B-scale software proofs so far, and still labeled intermediate research.
So who actually runs selective proving first – auditors sampling high-stakes traffic, or providers who want a public “we didn’t swap the model” badge? The prototype does not answer that. You get to.
FAQ
Can I run this against Claude or a closed API today?
No. The released prover targets the public Maverick-shaped integer model or synthetics. You only verify proofs a provider chooses to emit.
What does YES guarantee?
Say you covered tokens 0-128 under exact-match. YES means those tokens are the greedy outputs of the committed integer model on that window – not that the float production engine, the temperature sample, or the prose is “correct” or safe. Clipped-gap is looser on purpose. Always read the covered range in the request file before you celebrate.
Is the 70-95× overhead usable in production?
Not for every reply. People will batch high-stakes or auditor traffic and prove after the fact; batching amortizes weight-opening. Live sampled streams are not covered out of the box. The Nov 2026 write-up is explicit: intermediate progress, not a drop-in service. Further engineering has to close the gap if you want always-on proofs.
You already know the move. Confirm the example YES this afternoon. Then read the serving and weight-hiding guides before you ever touch secret weights. One verified run beats another summary of the launch post.