A routing layer sits between the model on your contract and the tokens that reach the customer. It can send the prompt to the weights you paid for, or to a cheaper cousin that writes almost as well. You can read the reply as carefully as you like. Fluency is a terrible audit log.
That is the quiet risk in a lot of model APIs. A sales agent will not catch a swapped model by tone. Neither will an agent that updates a CRM, sends a follow-up, or approves a discount.
Anthropic has released an open research prototype aimed at that gap. Coverage of the release credits the company’s Frontier Red Team. The project is called FlashProve. Skip the benchmark for a minute. Three facts decide whether it belongs on a roadmap:
- It can bind a reply to one committed checkpoint. A checker does not need the weights, and does not re-run the model.
- It does not prove that checkpoint is the model you bought. A green check can be perfect and still describe a cheaper set of weights.
- It is an after-the-fact audit, not a live control. Proofs are produced in batches after the reply, and the code is a research artifact, not a supported product.
A seal is not a label
A valid proof binds a reply to whatever weights were committed. It does not, by itself, prove those weights are the model on the invoice, the model a regulator approved, or the model a vendor advertised last Tuesday.
The headline demonstration makes that sharper. The measured run commits to Meta’s public 4-bit Llama 4 Maverick weights, not an FP8 or full-precision production checkpoint. Maverick is a mixture-of-experts model with about 400 billion parameters and roughly 17 billion active on a given token. A cryptographically perfect check can still attest to a quantized cousin of the model you think you bought.
The project spells out the operational consequence. Take the commitment ID from a party you trust. Never take it from the server you are checking, and never from files that arrived with the proof. Otherwise a cheating provider can commit to a cheaper model, prove that cheaper model honestly, and hand you a perfect alibi.
Hiding is narrower than a slogan, too. The project README says values that depend on the weights are masked, except a declared list documented separately. “The proof reveals nothing” oversells what the code claims. The architecture itself is public. What the proof is meant to protect is the weights.
A passing check is not only an exact match. The practical verifier can accept an exact yes or a within-limits yes. No tolerance for that gap is stated in the public description of the verifier. For an audit, that distinction matters more than headline throughput.
Soundness, the property that a forged proof should fail, is proved in Lean 4, according to the README. Under the stated hash assumptions, a forgery should be vanishingly unlikely. That bound is about hash queries in the proof, not a quota of customer requests. Published coverage of the release also says the fast C++ checker a person would actually run carries no formal guarantee of its own. A slower Lean verifier is the one tied to the theorem. Protocol math and the binary on a laptop are not the same object.
Anthropic says the hash-based construction offers post-quantum security, and that it belongs to the same family used by validity-proof networks such as Starknet. Treat that as Anthropic’s claim about the proof family, not as a finished compliance product.
A fingerprint, then a proof
The provider publishes a short fingerprint of one exact weight set. Later proofs are checked against that fingerprint, not against disclosed weights. In the published figures, a client downloads about 6.5 MB once per commitment. The reported proof is 18.78 MB. Those figures do not say whether 18.78 MB is one proof per request or one proof for a whole batch. Either reading changes bandwidth and storage. The proofs arrive after the fact, so this cannot sit on the live request path.
The speed story, as Anthropic’s materials frame it, leans on how a mixture-of-experts model works. Picture a large bench of specialists, with only a few called into the room for each word. The prover’s work tracks that active slice, about 17 billion parameters, not the full 400 billion. Weights stream from host memory, which is why a single 80 GB GPU can run the job.
What 110 tokens a second actually means
Read the operating point before you repeat the headline. The project README says the prover reaches about 110 tokens per second of prefill at 24 requests per batch, on one H100, with a 1, 024-token context. Anthropic’s performance guide, as reported by Marktechpost, puts that same point at 111.23 tokens per second on public 4-bit Maverick weights, one H100 80 GB, and 24 CPU cores. The batch takes roughly 221 to 226 seconds from start to proofs.
That 110 is aggregate prefill throughput across 24 requests. It is not one customer’s speed. A batch of one, in the same measurements, is 17.41 tokens per second. At the 1, 024-token cap, that is about a minute for a single request, not the several minutes of the 24-request batch. Quote “110 tokens a second” without the batch size, and you are selling the busy operating point.
A CPU checks the reported 18.78 MB proof in 17 seconds on 24 threads, or 21 seconds on one thread. The verifier needs no GPU.
The prototype is narrow in ways that matter in production. Context stops at 1, 024 tokens, while production windows now run into the hundreds of thousands. The reported decoding is greedy, always the single most likely next token, not the sampling most APIs ship. The model has to be a mixture of experts. Getting the real-weight path running is heavy on its own: the README’s Maverick route asks for about 330 GB of host RAM, plus a large download of the public 4-bit weights. Those setup requirements are separate from the benchmark rates above.
GPU time, not a price tag
Proving is not inference with a stamp on it. Against vLLM running FP8 Maverick on eight H100s, the same performance write-up measured about 72 times the GPU time for a batch of 24 requests, and about 94 times at the highest load tested. The familiar “70 to 95 times” line is a rounded range around those two figures, not a third test.
The hardware is not matched, and that mismatch is the same business point as the seal. Proving was timed on 4-bit weights and one H100. The baseline was FP8 weights on eight H100s. The multiple is GPU time, not dollars, energy, or same-box throughput. Even with that caveat, this is not a switch you flip on every automated call and forget. It is an after-the-fact audit with a data-center appetite.
Version 0.16.0 is Apache 2.0. The README labels it a research artifact: not maintained, and not accepting contributions. Nothing in the release shows a customer, a statute, or a production Anthropic model running under this proof. The uses Anthropic has listed, from spotting a tampered inference server to checking where a piece of text came from, are possibilities, not deployments.
One predecessor, not a field
On the same 400 billion model, the open comparison in published figures is VerInf: about 0.02 tokens per second, proofs around 93.6 GB, and verification on the order of 17.7 hours on 20 cores. That run was on a DGX Spark, not an H100. FlashProve is much faster to prove and much smaller to check than that baseline. It is not a matched race.
Attestable, which has not released code, reports about 53 to 77 tokens per second on Gemma 4, a 31 billion dense model, also on one H100. Its proofs are a few megabytes, its checks are hundreds of milliseconds, and its context goes up to 16, 000 tokens. Different model, different job. FlashProve’s prove rate on a 400 billion mixture-of-experts model is the striking number. Its 18.78 MB proof and 17-second check are not, once you look past VerInf.
Questions worth asking before this hits a roadmap
- Can a customer prove which model answered an API call?
Not on an ordinary API. FlashProve can bind a reply to one committed weight set, and a CPU can check that binding. The public demo commits to 4-bit Maverick weights, not an FP8 or full-precision checkpoint. A perfect proof can still describe a cheaper, quantized cousin. It cannot, alone, prove those weights are the model you were sold.
- How fast is the reported demo, really?
About 110 prefill tokens per second is aggregate throughput when 24 requests are proved together on one H100, and that batch takes roughly 221 to 226 seconds. It is not one customer’s speed. In the same measurements, a single request runs at 17.41 tokens per second, so a 1, 024-token generation is about a minute. The reported proof is 18.78 MB, checked on a CPU in 17 seconds on 24 threads, and the proofs arrive after the fact.
- What does proving cost relative to just running the model?
About 72 times the GPU time of the reported vLLM baseline at 24 requests, and about 94 times at the highest load tested, often summarized as roughly 70 to 95 times. That is GPU time, not a dollar price, and the baseline was a different precision on eight H100s.
- Does a green check mean an exact replay of production decoding?
No. The reported limits are a 1, 024-token context, greedy decoding, and mixture-of-experts models. A pass can be an exact match or only within limits, and no tolerance for that gap is stated in the public description of the verifier. Most production APIs sample, use much longer context, and are not proved as each token appears.
- Is this ready to gate production agents?
No. Version 0.16.0 is an unmaintained research artifact, closed to contributions, demonstrated on public Llama weights, with proofs produced after the fact. Useful as a preview of an audit trail. Not a control you can assume a vendor will operate next quarter.
- Who publishes the fingerprint, and is a pass exact or only close?
Whoever publishes the commitment ID has to be a party you trust, not the server under test and not a file that arrived with the proof. If that party is the inference box, the cryptography can be perfect and the label can still be a lie. Ask also whether a pass is an exact match or only within limits. Those two answers are the ones that matter.
If the agents you run can update a record, send a message, or approve a discount, model identity is already a business control. A swapped model is a quiet way to cut cost, change behavior, or tamper with a token stream, and “it sounded fine” will not hold up in a dispute. FlashProve shows a cryptographic receipt for a frontier-scale mixture-of-experts model can actually be produced. It also shows the receipt is still a lab instrument.
Ask a plainer question than whether a vendor can prove a reply. Ask whether a party you trust, not the inference box, publishes the weight fingerprint, and whether any check is exact or merely close. Until those answers are boring, treat provable inference as a direction. Do not file it as a finished checkbox.