- Book: Observability for LLM Applications
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
You pay a router for a big model. A good answer comes back. Was it the model you paid for? Anthropic's Frontier Red Team says the answer itself can't tell you: "Judging from the model's output alone is unreliable, even if it produces high-quality responses."
On November 2, the team published FlashProve, an open-source research prototype that produces a cryptographic proof that a reply came from one specific, committed set of model weights. The verifier never sees the weights. The post names the case it has in mind: a model "secretly substituted in by a routing service for cost reasons."
It works, on one model, at a steep price.
What FlashProve actually proves
The README describes three steps. The provider publishes a commitment ID bound to one set of weights. For each reply, the provider's GPU produces a proof that the reply is that committed model's output. Anyone can then check the proof on an ordinary CPU with a tool called cp_verify, without the weights.
The demo model is Llama 4 Maverick, a 400B-parameter mixture-of-experts model with about 17B parameters active per token, using public 4-bit weights. The authors are Roy Rinberg and Alex Allain at Anthropic, with collaborators from EPFL, MIT, StarkWare and Succinct.
The README states the soundness bound: a cheating provider gets caught except with probability about q/2^124 + 2^-101 after q hash queries, a property the team proved in Lean 4. The post is careful about what that covers. The C++ verifier you'd use day to day carries no formal guarantee, though it agreed with the Lean verifier on every proof in their tests, and "we do not guarantee that all three (Lean, paper, code) match each other."
The provider commits to its weights once. Each reply then carries a proof that anyone can check without opening the vault.
The price: GPU time, RAM and a short window
The numbers are better than earlier attempts and still far from production.
- Throughput: about 110 tokens per second on one H100. The team measured a batch of 24 requests taking about 223 seconds.
- Overhead: about 72x the GPU time of vLLM serving the same 24 requests (66 to 77x across runs), and about 94x at vLLM's highest tested load. The vLLM baseline used FP8 weights on eight H100s.
- Window: "Each verifier request is a window of 1,024 tokens, and each proof checks one token." The authors call 1,024 tokens "quite short" next to chat contexts.
- Proof size: about 18.78 MB per proof. The client also downloads about 6.5 MB of commitment data once.
- Verification: about 17 seconds on 24 CPU threads, or 21 seconds on one thread, including the offline checks.
- Commitment: about 39 minutes, once per model, good for about 16 million requests before the provider recommits.
Read the window bullet carefully. The 110 tokens per second works out to 24 requests of 1,024 tokens in 223 seconds, yet each proof checks one token of its window. A proof does not cover every token of the reply.
For scale, the post cites VerInf, earlier work on the same model, at about 0.02 tokens per second. AlphaSignal notes that comparison mixes hardware and settings, so treat it as a rough gap, not a controlled benchmark.
The hardware bar is high on the proving side. The README asks for one dedicated NVIDIA H100 80 GB, CUDA 13.2 Update 2, and gcc 13. The full Maverick route downloads a 232 GB 4-bit conversion and needs 330 GB of RAM and 245 GB of disk.
What it can't do yet
The post lists the limits plainly. Three matter if you were hoping to point this at your API bill.
It proves greedy decoding of an integer model. In the authors' words: "A reply from a floating-point implementation, or sampled decoding, could depart at some position and no longer exactly match the computation proved." If your calls sample with a temperature above zero, they aren't covered.
The architecture isn't hidden. The weights stay secret, but the system assumes an MoE architecture and exposes it. The authors note that an architecture's description "may contain intellectual-property the model provider would like to keep secret." Timing side channels "could potentially reveal information about the weights," and are out of scope.
It isn't behind Claude. The post doesn't say FlashProve runs in Claude or the Claude API, and the demo is Llama 4 Maverick. It says a related Anthropic roadmap goal was met by a different project that signs inference traffic and recomputes inference on a trusted server. FlashProve "pursues the same objective by a different method."
The repo is version 0.16.0 under Apache 2.0, and it's labelled "not maintained, not accepting contributions." The authors say why they shipped it anyway: "We are sharing this explicitly with the goal that others look at what we have done, take it, and improve it."
Check a stored proof on a Linux box
You don't need an H100 to see the verifier work. The README's first route builds cp_verify and checks an example proof on Linux with bash and g++ 13 or newer, in under 2 GB of RAM. It lists the build at 1 to 2 minutes and the check at under 2 seconds.
git clone https://github.com/anthropics/FlashProve
cd FlashProve
verifier/build.sh
E=examples/accepted-proof
bin/cp_verify "$E/config" "$E/ivk" \
"$E/example.req" "$E/example.y" \
"$E/example.proof" -id "$(cat "$E/ID.txt")"
Per the README, success is a last line of YES and exit code 0. Rejection is exit code 1 with NO: <name>. The example uses synthetic weights, so it shows the verifier works, not that a real model answered. I haven't run it myself.
The README adds one rule for anyone building on this. Get the commitment ID "from a party your user trusts, never from the server being checked or from files sent with the proof." A proof against a commitment the router hands you proves nothing about the router.
The case FlashProve targets: a router serving a cheaper model than the one on the invoice.
What you can do about model swaps today
FlashProve is research. Your router invoice is due this month. Two things help now, and neither is proof.
Narrow who can serve the request. If you route through OpenRouter, its provider selection docs let you list providers, turn off fallbacks, and filter by quantization for open-weight models:
"provider": {
"order": ["deepinfra"],
"allow_fallbacks": false,
"quantizations": ["fp8"]
}
The docs say that to guarantee only the top-ranked provider serves a request, "you can disable fallbacks." They also warn that "Quantized models may exhibit degraded performance for certain prompts," which is the quieter version of a model swap.
Watch quality like a metric. Run a fixed set of prompts with known-good answers on a schedule, and alert when scores drift. Anthropic's point stands: output alone is an unreliable way to identify a model. A drop in eval scores still tells you something changed upstream, whether that was a swap, a new quantization, or a silent model update.
Would you pay a premium per token for a proof that the model on the invoice wrote the answer? Or is provider pinning enough for your workload?
If this was useful
I build Hermes IDE, so weigh this with that in mind: it's a free, source-available desktop app for macOS, Windows and Linux that runs Claude Code, Codex and other agents side by side, each on its own branch. Download it or star it on GitHub.
Until proofs like FlashProve's reach real APIs, your traces and evals are how you notice that the model behind an endpoint changed. Observability for LLM Applications covers that side: tracing LLM calls, running evals as regression tests, and catching cost and quality drift in production. If the eval-as-canary idea above is the part you'd act on, the book walks through building it.
Top comments (0)