Can You Prove Which AI Model Answered You?

Imagine an organization paying for a specific model to review a security patch. The response may look convincing, but the organization cannot tell from the prose whether it came from that model, a cheaper substitute, or a compromised server. Anthropic’s FlashProve asks a narrower question than “Can I trust this AI?”: can a third party verify which model produced these tokens, without being given the model’s weights? ^[1]

A receipt for the computation

A normal model API returns text. That text does not carry a verifiable record of the model that generated it. A provider could route a request to another model, or an attacker could alter the token stream, while the answer still looked plausible. Logs can record what a system says happened, but logs alone do not establish that the computation actually matched the record. ^[1]

FlashProve applies a cryptographic technique called a zero-knowledge succinct argument to this gap. Before serving requests, a provider commits to one exact set of model weights. The commitment works like a compact fingerprint: it pins down the model while keeping the weights private. For each request, the provider can then produce a proof that the committed model generated the claimed output from the supplied input. A verifier checks the proof without downloading the weights or running the large model again. ^{[1] [2]}

The “zero-knowledge” part concerns the secret model weights: the proof is designed to reveal no additional information about them. It does not hide the architecture in this release. The “succinct” part means the verifier’s work is much smaller than repeating the full model computation. In Anthropic’s benchmark, checking a proof took about 17 seconds on a 24-thread CPU, and the proof itself was about 19 megabytes. ^[2]

A prototype, not a trust badge

Anthropic reports running FlashProve on Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model, using quantized weights and a single NVIDIA H100 for the prover. The reported rate—about 110 tokens per second across a batch of 24 requests—describes proof generation throughput. The report says each request waited around five minutes for its batch of proofs. It also compares the proving workload with ordinary inference and reports roughly 72 times longer per GPU in its benchmark setup. Those numbers are results from the authors’ experiment, not a general performance guarantee for other models or providers. ^{[1] [2]}

The limits matter as much as the headline. FlashProve currently checks an integer version of the published weights under greedy decoding, for contexts up to 1,024 tokens. A sampled or floating-point response may differ from the exact computation being proved. The current system focuses on a mixture-of-experts model and does not conceal its architecture. Anthropic also says the fast C++ verifier has not been formally proven equivalent to the Lean specification, even though the project includes a slower Lean verifier. ^{[1] [2]}

The project repository describes FlashProve as a research prototype and marks it as not maintained. It is an invitation to inspect and improve an early implementation, not a ready-made service a company can switch on for every model call. The authors themselves call the work intermediate progress and document further security, engineering and deployment questions. ^{[3] [1]}

What a proof can—and cannot—settle

Model provenance can be useful when the identity of the system is part of the promise. Independent evaluators could check that they tested the same weights a provider says it served. A customer using a third-party router could verify that the contracted model answered. A compliance auditor could check evidence that a particular approved model processed a request. The proof can make that claim independently checkable without asking the provider to expose its model parameters. ^[1]

But a valid proof says nothing about whether the answer is correct, relevant or safe. It certifies a relationship between a committed model, an input and an output under stated assumptions. If a committed model produces a hallucination, the proof can faithfully certify the hallucination. It also does not establish that a provider is not training another model on the side, or that the response was appropriate for the user’s situation. ^[1]

A proof is one part of a broader record. An auditor still needs to know what model commitment was approved, what prompt and context were included, which output tokens were covered, how the verifier was obtained, and whether the proof pipeline is implemented correctly. Systems also need a way to protect user prompts and outputs, which may themselves contain sensitive information. A cryptographic receipt does not replace access controls, careful logging policy, model evaluation or human review.

The useful next question

For everyday chat, many people care more about getting a helpful answer than about the exact weights behind it. In regulated, security-sensitive or independently evaluated uses, that distinction can matter. Provable inference points toward a future where model providers can make identity claims that customers do not have to accept on trust alone.

The next milestone is not merely faster proofs. It is a complete, independently reviewed service that can produce and verify evidence for realistic models, longer contexts and the decoding methods people actually use, with clear handling of prompts and responses. FlashProve shows a technical path worth examining, while its published limitations make the distance to routine deployment visible. A verifiable model identity would answer one important question at the edge of an AI service. It would leave the much larger question—whether the response deserves your trust—for people and other safeguards to answer. ^{[1] [2]}