Anthropic Open-Sources FlashProve: A Zero-Knowledge Proof of Which Model Actually Answered You

In one line: an answer can be faked, a proof cannot

You ask a service that claims to run a flagship model. The answer is fluent, professional, and looks impeccable. But can you be sure that model actually answered you? Anthropic's research post of 2 November 2026 gives a blunt answer: from the output alone, you cannot. A routing service might quietly swap in a cheaper model to save money, an attacker might tamper with the token stream, or a stronger model might impersonate a weaker one to dodge the monitoring that should apply to it. Once model calls pass through layers of proxies, gateways, and third-party routers, this is a real trust gap, not a thought experiment.

FlashProve, the open-source prototype Anthropic released with that post, is an attempt to close part of the gap. It is a system for provable inference: using a zero-knowledge proof, a zkSNARK, it lets a provider mathematically prove that a response came from a previously committed set of weights, without revealing those weights. This is not a product launch. There is no deployment timeline and no plan to wire it into Claude. Its value lies precisely in how plainly Anthropic says so: this is intermediate research progress, with code, proofs, and documentation released openly so others can improve on it. Keep that framing in mind, and the rest of the story falls into place.

What FlashProve actually proves

Provable inference has a one-sentence goal: let someone with limited compute and no access to the weights verify that a response came from the model they asked for. FlashProve splits the job into two phases. In the offline phase, the provider publishes a commitment to the model weights — a short fingerprint that pins down one exact set of weights while keeping the weights themselves hidden. In the online phase, the provider attaches a proof to each request, proving a single statement: the committed model produces these output tokens on this prompt. Anyone holding the commitment, the prompt, and the reply can check it, without the weights and without running the model.

Four properties have to hold at once, or the whole thing falls apart. Completeness: an honest provider's proof is always accepted. Soundness: forging a proof of a false statement is effectively impossible, tantamount to breaking widely believed cryptographic assumptions. Zero knowledge: the proof reveals nothing about the weights, the intermediate values, or which experts ran at each layer. Succinctness: the proof must be small and cheap enough to check on an ordinary CPU, rather than requiring the verifier to build another data centre.

One boundary is easy to misread, and Anthropic states it explicitly: FlashProve hides the weights, not the model architecture. The proof does not promise to conceal what the model looks like, and the system exploits the mixture-of-experts structure for efficiency. If you wanted a proof that hides even the architecture, this is not it. Likewise, it proves that a reply came from the committed weights — not that the organisation behind the commitment is trustworthy in some broader moral sense. Who issued the commitment, and whether that source is worth trusting, remains a question outside the proof.

The numbers: much faster, still extremely expensive

The demonstration model is Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model with roughly 17 billion parameters active per token, using publicly available 4-bit weights. On a single H100 GPU, proof generation runs at around 110 tokens per second, with a proof of about 19 MB per 1,024-token request. The offline commitment step runs once per model and takes about 39 minutes; one commitment covers roughly 16 million requests before the provider must commit again. Verification is far lighter: the client downloads a commitment of about 6.5 MB, and checking one proof takes 17 seconds on 24 CPU threads, or 21 seconds on a single thread, with no GPU required.

But "lighter" only describes verification. Anthropic's own comparison is admirably frank: per GPU, proving a batch of 24 requests takes about 70 to 95 times as long as running the same requests with vLLM, a widely used inference engine. That reframes the whole idea. FlashProve is not a path to proving every token of a production traffic stream tomorrow; it is a path to auditing a sample of traffic, or to proving high-value requests where the cost of doubt exceeds the cost of proof. Treat proof generation as an audit cost, not an inference cost, and the positioning finally makes sense.

Against the history of zero-knowledge machine learning, the jump is real. Anthropic's survey recalls zkCNN in 2021 proving a VGG-16-scale model at 88.3 seconds per proof, GPT-2-scale proofs once taking well over a hundred seconds per token, and the only earlier proof of Llama 4 Maverick itself, VerInf, needing 14.3 hours for 1,000 tokens with a 93.6 GB proof that took almost a day to verify. FlashProve proves the same model at 110 tokens per second with 19 MB proofs verifiable in seconds. That is why the release is worth reporting: not because it is ready, but because it moves provable inference for a frontier-scale model from "implausible" to "expensive but possible".

Why prove the proof again, in Lean

Cryptographic code is notoriously brittle: one wrong edge case can silently void the entire guarantee. The second notable part of this release is that Anthropic formalised the protocol's top-level security properties — completeness, soundness, and zero knowledge — in Lean, a proof assistant that produces machine-checkable proofs. The properties are stated in the random-oracle model, the standard idealised setting for analysing hash-based protocols. Anthropic also ships an interactive visualiser for the Lean theorems, to help auditors check that the formal statements actually match what people intend them to mean.

Here, too, the boundary matters. Lean proves the protocol, not the fast C++ verifier you would actually run day to day. Anthropic is explicit: it provides an executable Lean verifier that is slower but provably accepts only what the soundness theorem accepts, while the everyday C++ verifier carries no formal guarantee — it merely agrees with the Lean verifier on every proof tested so far. Formal verification sharply reduces the risk that the protocol itself is wrong, but it does not eliminate the risk that the implementation diverges from the protocol. Auditing therefore has two layers: first, do the Lean statements capture the intended properties; second, does the executable code faithfully implement the protocol. Conflating those layers would overstate the assurance on offer.

There is a further detail worth noting: Anthropic says Claude itself produced improvements on zkSNARKs for inference, finding novel combinations of state-of-the-art tools from the cryptography literature. That is both a highlight and a caution. AI can accelerate cryptographic engineering, but the larger and more complex the AI-assisted system, the more you need a human-auditable, top-level statement of what it is supposed to guarantee. Lean's role here is not decoration; it is a hedge against the difficulty of evaluating AI-generated decisions in large systems. That idea may prove more transferable than any single performance number in the post.

What it cannot do yet: five hard limits

First, context is capped at 1,024 tokens — very short next to frontier chat sessions that accumulate hundreds of thousands or millions of tokens. Anthropic concedes that full context windows are the ideal, but not yet achievable. Second, the proof concerns an integer version of the model under greedy decoding. Real services run floating-point implementations and may use sampled decoding, so a reply can diverge from the proved computation at some position and no longer match it exactly. Anthropic says the integer version is generally close to floating-point inference, but that does not cover adversarially designed prompts.

Third, the architecture is not hidden, and the system is optimised around mixture-of-experts structure; dense models are not on the same optimisation path. Fourth, side-channel attacks are out of scope: the proof itself reveals nothing about the weights, but the time taken to produce a proof could in principle leak information, and Anthropic explicitly excludes that from this release's guarantee. Fifth, FlashProve proves after the fact, not inline. Post-hoc proving can afford to be slower and more secure, but it brings delay, recomputation complexity, and floating-point non-determinism with it.

Taken together, these limits draw a clear picture: FlashProve is not a universal "authenticity label for every answer". It is a prototype that holds under specific constraints, best suited to settings where after-the-fact sampling matters more than real-time interception — an independent evaluator wanting to confirm it tested the model it thinks it tested, a customer wanting to confirm a routing layer did not substitute a cheaper model, or a regulator wanting to check that only approved models were served without demanding trade secrets. For an ordinary chat user, there is currently no reason to wait extra seconds verifying every reply.

What this means for developers and buyers

For developers, the most useful takeaway is not "integrate FlashProve now" but "re-examine what you assume about model identity". If you call a model through a third-party gateway, does your contract say anything about model identity? When the gateway says it runs a particular model, do you have any way to verify that after the fact? If the answer is no, FlashProve at least sketches a technical shape for the future: commitment plus proof plus independent verification, written into contracts and audit processes, rather than reliance on a provider's word alone.

For buyers and compliance teams, the release turns a regulatory thought experiment into a discussable engineering option. Rules like "serve only approved models" or "use this hardware for inference, not training" have long stumbled on the same question: how do you check without seizing trade secrets? Zero-knowledge proofs answer by verifying the claim itself, not by inspecting the weights. But they are not a skeleton key: proving that inference traffic came from a committed model does not prove the hardware was not also training on the side, nor does it prove the committing organisation behaved honestly elsewhere. Treat proof as one tool in a compliance toolkit, not as compliance itself.

For model providers, FlashProve is a signal that model identity is shifting from a brand promise to a verifiable attribute. Not building it today is defensible; claiming to be "provably" serving a model while merely writing a model name in a log is not. The honest test, if any vendor starts marketing provable inference, is three questions: is the commitment public, can it be verified independently, and does the proof cover the specific request you care about? Those three questions separate a real guarantee from a marketing label.

Judgement: worth excitement, not premature celebration

My judgement is that FlashProve is solid research progress, not a product turning point. The progress is genuine — the same model going from a 14-hour proof to 110 tokens per second, from a 93.6 GB proof to 19 MB, from a day of verification to seconds, is a real discontinuity on the zkML curve. The restraint is equally genuine: open code, stated limits, no deployment plan, and a candid account of what formal verification does and does not cover, rather than a prototype dressed up as a solution.

But that restraint also measures the distance remaining. A 1,024-token window, 70 to 95 times proving overhead, integer and greedy-decoding assumptions, no architecture hiding, and post-hoc rather than real-time proving — any one of these blocks most production uses. More fundamentally, FlashProve answers "did this reply come from the committed model?", not "is the commitment worth trusting?" If the commitment comes from the provider itself, the verifier still needs an independent source for that commitment; otherwise the proof only certifies consistency inside a circle the provider drew itself. Anthropic notes that proofs need to be combined with trustworthy commitment distribution, and that piece does not ship with the prototype.

The right expectation, then, is neither waiting for a launch nor ignoring the work. Think of it as a milestone on a roadmap: zero-knowledge proofs for large-model inference have moved from "possible in papers" to "expensive but feasible in a prototype". The next things worth watching are not whether Anthropic plugs it into Claude, but whether independent teams reproduce it, audit it, extend the context, cut the overhead, or deploy it in a real evaluation or procurement setting. Only then will "which model answered you?" stop being a slogan and become a question with a checkable answer.