A company that pays for an AI model has no cryptographic way by default to verify that the model produced the response. The provider could route the request to a cheaper model, or an attacker could tamper with the output stream. Anthropic proposes addressing this problem with FlashProve, an open-source prototype that links a response to specific weights without revealing them.
The proposal targets something more specific than detecting whether text «looks» like it was written by a particular AI: it proves that the output corresponds to a model committed to in advance. That distinction could matter for third-party services, audits, and compromised inference systems. But Anthropic's demonstration also makes the price of that guarantee clear: producing each proof requires far more computing power than generating a normal response.
A model fingerprint before responding
FlashProve uses zkSNARK, a family of cryptographic proofs that makes it possible to verify that a computation was performed without revealing secret information about its inputs. In this case, the provider first publishes a cryptographic commitment, a kind of fingerprint that identifies an exact set of weights. The weights remain hidden; the subsequent proof is tied to that commitment, not simply to a claim made by the server.
The process has two phases. In the preliminary stage, the provider fixes the model commitment. When a request arrives, it generates a proof attesting that the response tokens were obtained by evaluating that model with that input. Anyone with the commitment, request, and response can verify the result without accessing the weights.
flowchart TD
A["Proveedor fija compromiso"] --> B["Usuario envía petición"]
B --> C["Modelo comprometido genera salida"]
C --> D["GPU produce prueba"]
D --> E["Usuario recibe salida y prueba"]
E --> F["Verificador comprueba compromiso y respuesta"]The trust requirement does not disappear: the commitment must come from a source the verifier trusts. The FlashProve repository warns that the commitment identifier must be obtained from a trusted party, not from the server being checked or from files delivered with the proof. If the provider can replace both the response and the accepted identity of the model, verification loses its purpose.
The technique hides the weights, but does not aim to conceal the model architecture. Nor does it certify that the model is safe, that its response is correct, or that the service used only specific resources. It certifies a narrower claim: that the verified output corresponds to the model associated with the commitment, under the conditions FlashProve can prove.
The improvement over earlier proofs comes at a cost
Anthropic tested the system with Llama 4 Maverick, a mixture-of-experts model with 400 billion parameters, quantized to 4 bits. On an Nvidia H100 GPU, FlashProve processed around 110 tokens per second while generating proofs. Each certificate is approximately 19 megabytes per request of 1,024 tokens.
The bottleneck is not so much checking the certificate as producing it. The New Stack puts verification at around 21 seconds on a single CPU thread; The Decoder reports 17 seconds on a standard CPU. Anthropic compares the system's GPU time with vLLM and estimates an overhead of 70 to 95 times. These figures come from a specific test, not a general measurement for every model or workload.
The gap with earlier work is notable. Anthropic says VerInf needed 14.3 hours to generate a proof for 1,000 tokens; the proof occupied 93.6 GB and took almost a day to verify. FlashProve reduces the size to around 19 MB and brings verification down to seconds, but proof generation remains costly for an API that has to attach a proof to every response.
In addition, proofs are generated in batches after requests are completed. Tokens are not verified as they appear on screen. For products that need to display a response immediately, this means verification may arrive later than the text. The provider would also have to bear the additional GPU usage, while the verifier needs to retain the response, request, commitment, and certificate.
What could change for providers and customers
In a service that distributes requests among models, a verifiable proof would let the customer check whether they received a response from the model they contracted for. The same mechanism could give a company evidence that an analysis was run with a specific safety model, rather than a cheaper or downgraded version. In both cases, conversation logs alone do not provide this cryptographic guarantee.
Anthropic also proposes uses for auditors and regulators. A regulator could request certificates to check that a provider served an approved model, or gather evidence that declared computing resources were used for inference. The company cautions, however, that verifying inference does not prove that the same hardware was not training another model at the same time. The proof defines what can be attested to; it does not make the provider's entire system transparent.
For internal security, linking an output to specific weights could help detect a compromised server responding with a different model, or an unauthorized agent inserting itself into the generation process. Anthropic also describes a scenario in which a more advanced model impersonates a less capable one to evade controls. For detection to work, the server would have to produce a valid proof for the expected commitment; replacing only the text would no longer be enough.
The idea aligns with a goal Anthropic previously announced, although it is not the same project. The company says it achieved its goal of creating a prototype for verifiable inference through another system, which signs traffic and reruns inference on a trusted server. FlashProve pursues the same goal using cryptography and without relying on trusted hardware.
“We will develop a prototype by September 30, 2026 of provable inference, a technique for reliably, provably ‘signing’ AI model outputs in a way that makes them attributable to a specific set of model weights.”
— Anthropic
Limitations affect real-world use
The current proof covers contexts of up to 1,024 tokens. It also uses integer arithmetic and greedy decoding: at each step, it chooses the most likely next token. The Decoder notes that this does not cover the usual random generation used by chatbots. Therefore, a valid demonstration for the prototype is not equivalent to certifying, without changes, every response produced by a production conversational service.
The method also adds considerable operational overhead. The repository says that full-scale proof generation requires an H100 and a large amount of memory; to run the example with Maverick's actual weights, it specifies requirements of 330 GB of RAM and 245 GB of disk space, in addition to a 232 GB download. These are requirements for the procedure described in the repository, not minimum requirements for verifying a received proof: the verifier can run on an ordinary CPU.
Anthropic sought to separate mathematical trust from software optimization. Claude contributed to developing FlashProve and speeding up the system; the team formalized properties in Lean, such as accepting valid proofs, rejecting forged ones with overwhelming probability, and not revealing the weights beyond what the response itself implies. The project includes a Lean verifier backed by these proofs and a faster one in C++. The latter and the GPU prover were checked against the formal protocol, but do not have the same formal verification guarantees.
This distinction matters to a company considering adopting the system: it is not enough for the cryptographic design to have proven properties; the specific implementations that generate and check certificates also matter. The code, Lean proofs, and documentation are published under the Apache 2.0 license, but GitHub identifies the repository as a research artifact that is unmaintained and does not accept contributions. FlashProve is also not part of the Claude API, and Anthropic has not said whether it will be integrated.
For now, FlashProve demonstrates that it is possible to cryptographically associate a response with private weights and verify that association on a CPU. To turn this into a routine guarantee, it would still need to address the cost of generating proofs, expand the conditions under which inference can be verified, and fit within the response times of the services it aims to make verifiable.
Sources: The New Stack, The Decoder, Anthropic, GitHub
