Anthropic's FlashProve Proves Which Model Answered

Anthropic's Frontier Red Team published FlashProve on Tuesday, an open-source prototype that lets a user cryptographically check that a response really came from the model they asked for. The work closes a gap most agent stacks quietly ignore: nothing in a normal API call proves which model produced the tokens.

What happened

FlashProve is a proof of inference built on zkSNARKs. A provider commits to a model, then attaches a short cryptographic proof to each response that a client can verify without ever seeing the weights. For Llama 4 Maverick, a 400-billion-parameter mixture of experts in 4-bit quantization, a single H100 generates proofs at roughly 110 tokens per second, with a proof size of about 19 MB per 1,024-token request.

That is still expensive. Anthropic puts it at roughly 70 to 95 times the GPU time of plain inference on vLLM, so this is a research prototype, not something you switch on in production tomorrow.

Anthropic released five artifacts under the Apache 2.0 license: the research post, a technical report, a protocol specification written by Claude, executable prover and verifier code, and Lean proofs for the top-level security claims. The verifier ships in two forms, a fast C++ build and a formally verified Lean build, so a client device can check a proof in seconds on a normal CPU. The commitment hides model weights, but not model architecture. Anthropic says there are no plans to deploy it in Claude or at any other lab yet.

Why it matters

Model routing is everywhere and almost entirely opaque. Aggregators, resellers and multi-model agent frameworks can substitute a cheaper model behind an expensive model's name, and the user cannot tell from output quality alone. A proof of inference turns that from a trust problem into a checkable claim.

Anthropic frames it around three buyers: independent evaluators who need to know the model they test is the model being served, clients buying through third-party routers who want what they paid for, and eventually regulators or labs enforcing AI pacing commitments. Verification is designed to be cheap on the client side, which is the whole point: a laptop can audit a frontier model it could never run.

Builder impact

Today the practical takeaway is not to bolt on proofs, but to make your stack ready for them. Log the model identifier, provider and response metadata for every call your agents make, so a later provenance claim can be checked against your own records. Keep your evaluation harnesses pinned to exact model versions you can name, and treat silent provider swaps as a risk to test rather than a hypothetical. If a vendor starts publishing model commitments, verification code is already public and small enough to run inside your own audit pipeline. Agent stacks that route requests across providers have a related trust problem, as we wrote about in why AI agents need egress control, not just better prompts.