Anthropic open-sources FlashProve: verify the right model generated an answer in 17 seconds

You pay for a top-tier model, but the response you receive looks suspiciously simple. Verifying what happened is almost impossible: the weights are closed, the answer looks plausible, and a router between you and the provider can quietly substitute a cheaper model. Anthropic has open-sourced FlashProve, the first attempt to make this kind of verification practical.

How it works

The idea resembles a notary's seal. The provider publishes a digital fingerprint of its weights in advance: a commitment from which the weights themselves cannot be recovered. It then attaches a proof file to every answer. If the proof matches the published fingerprint, the answer was computed by that exact model using those exact weights.

The verifier needs neither the weights nor a GPU. A regular computer is enough. Under the hood is zkSNARK, a well-established cryptographic method that can prove a computation was performed correctly without revealing the computation's inputs, which in this case are the weights.

Imagine using an aggregation service that promises to answer through the most powerful model. Without a protocol like this, you have to take its word for it. With FlashProve, you receive an answer and a file, verify it in seconds, and know for certain that no substitution occurred.

What changed, in numbers

zkSNARK itself is not new. The breakthrough is bringing it up to practical speeds. According to Anthropic, the proof for a 1,024-token request is about 19 MB, and verification takes about 17 seconds. The previous result in this area required about 14 hours of verification and produced a 93 GB proof. The improvement is severalfold in time and multiple orders of magnitude in size, all for models of up to 400B parameters.

One separate detail: the paper says Claude handled most of the acceleration and optimization work. This does not prove that the approach is universal, but it shows that models are already helping with low-level cryptographic engineering.

Why it matters in practice

The first use case is routing services and proxies. If you are building a product on top of an aggregator, you can demand a proof and make sure it has not supplied a cheap model instead of the one advertised.

The second is security inside a company. If attackers replace a model within a corporate environment, a mismatch with the public fingerprint will expose the substitution.

The third is regulated industries, where it is important to prove to an auditor exactly which model made a decision.

Limitations

The main issue is that this remains far more expensive than ordinary inference. Generating a proof is computationally demanding, so enabling it for every production request is not yet practical. Seventeen seconds of verification and 19 MB per request may work for selective audits, but not for real-time chat. The protocol is also described as a prototype, meaning that the implementation still needs independent review and provider support: there is nothing to verify unless the provider publishes the fingerprint of its weights.

Finally, the protocol verifies the model's identity, not the quality or safety of its answers.

What to do

If you are building an aggregator or gateway, examine the repository and consider how to add selective verification, for example for a random percentage of requests. If you buy inference from resellers, start asking for verifiability clauses in contracts. If your product operates in a regulated field, keep the technology on your radar: within a year or two, verifiable inference requirements could become the norm.

The author of the original post jokes that this could also lead to a detector for the origin of texts. That remains speculation, but the direction is clear: away from taking claims on trust and toward verifiable guarantees.