On November 2, Anthropic presented FlashProve, a research prototype for cryptographically checking that an AI response came from a previously specified model. The idea is for a provider to make a verifiable commitment to particular weights without publishing them. Potential applications include model evaluation and requests sent through an intermediary. This is an uncovered study from the past three days, rather than a consumer product launched this morning.
What is actually checked
The public repository describes three stages: committing to the model, producing a proof and verifying it. Verification can run on an ordinary CPU without access to the weights. The project is explicitly labeled a research artifact that is not maintained. Its published example uses Llama 4 Maverick with a 1,024-token context.
The report describes a mathematical assurance about conformity to a specified computation. That differs from checking a claim about the world. If the model produces an incorrect date, a valid proof could confirm that this particular model selected those tokens. It would not make the date correct. This is an editorial explanation of the scope, not a newly discovered flaw in the prototype.
The cost of proving
Anthropic reports approximately 110 processed tokens per second of prefill proving on one H100 for a four-bit version of the 400-billion-parameter mixture-of-experts model. The stated proof is about 19 MB for a 1,024-token request. Weights reside in host RAM and are streamed to the GPU; one H100 does not mean the full model fits in its video memory. The company puts GPU time at approximately 70–95 times the time vLLM takes for corresponding requests. These are author-reported measurements for a particular configuration, not a benchmark independently reproduced by us or ordinary chat-generation speed.
The technical report specifies an integer model with greedy token selection. Sampling or a different floating-point implementation may produce another sequence. The formally specified protocol and slow Lean verifier also do not automatically provide formal assurance for all of the fast executable code. These are significant boundaries when assessing deployment readiness.
Where verification might help
Our editorial example is a service that promises model A but could route a request to model B. A verifiable binding to the weights would add evidence about the computation’s origin, even if both answers looked equally persuasive. The customer would first need to know which commitment identifies the agreed model and exactly what the proof covers.
This makes the choice of statement as important as the verification mechanism. A team might want evidence about one selected request rather than assume that checking it establishes the behavior of every request made over a month. That is a scope question for a prospective integration, not an additional capability demonstrated by the release.
The short context and computational overhead distinguish the example from a widely deployed conversation with a long history. The news is progress on an inspectable research mechanism, with public code and stated limitations. It does not establish that Claude now attaches such a proof to every consumer response or that the system certifies the safety of every task.
