Anthropic's FlashProve: what provable inference proves, and what it doesn't

On 2 November 2026, Anthropic's Frontier Red Team released FlashProve, an open-source prototype for what it calls provable inference: a way for an AI provider to prove that a reply came from one specific set of model weights, without showing the weights.¹ Anyone who holds the provider's commitment, the prompt and the reply can check the proof on an ordinary computer, without a GPU, in seconds.

The demonstration runs on Llama 4 Maverick, Meta's open-weights model of 400 billion parameters. One H100 GPU produces proofs at about 110 tokens a second, a proof is about 19 MB for a 1,024-token request, and checking it takes about 17 seconds. Anthropic presents the release as "intermediate progress, and not a completed research agenda", and the code repository calls itself a research artifact that is not maintained.³

Below: the problem provable inference addresses, how FlashProve's commit, prove and verify steps work, what it costs, how it compares with earlier systems, exactly what a proof says and what it does not, what you can run today, and what it would change for research records that name the AI models behind a result. Every source was checked on 3 November 2026.

What problem does provable inference solve?#

When you send a prompt to an AI model, you see the reply and the model name the service shows you. You cannot check that the two belong together. Anthropic's post puts it this way: "A user querying a model today cannot check that the responses came from the specific model that a developer claims is responding, as opposed to one secretly substituted in by a routing service for cost reasons, or even by an attacker who has tampered with the token stream."¹ And: "Judging from the model’s output alone is unreliable, even if it produces high-quality responses."

The obvious check does not work either. Most frontier models' weights are private, and even with the weights, running a large model again to compare its output takes hardware that few users, or even evaluators, have. The goal of provable inference, in the post's words, is "to enable a user with limited computational resources and without any information about the weights to verify that a response came from the requested model."

The post names four situations where that would matter:

• Pacing. A regulator that wants a provider's chips spent on serving models, not on training a new one, could ask for proofs covering the requests served in a period. Anthropic states the limit itself: this "does not establish that the hardware is not, e.g., training on the side."
• Tamper detection. An attacker who compromises an inference server, or a stronger model that passes itself off as a weaker one, would have to produce valid proofs for the expected weights to stay hidden, and could not.
• Text provenance. A developer says a software library was scanned by a frontier security model, or a company says a plan was approved by a particular model. "Even publishing the chat logs gives no absolute guarantees," the post says: logs could be made with a cheaper or degraded model.
• Model approval. If rules allowed only models approved as safe to be served, a proof attached to each reply would show which model answered.

The third case is the one closest to research. A paper, a disclosure statement or a record that says an analysis was done with a named model is, today, the author's word.

The work also answers a public goal. Anthropic's Frontier Safety Roadmap promised a prototype, by 30 September 2026, of "a technique for reliably, provably ‘signing’ AI model outputs in a way that makes them attributable to a specific set of model weights." The post says Anthropic met that goal through a separate project, which "signs our inference traffic and recomputes inference on a trusted server", and that FlashProve pursues the same objective by a different method. In an update of 19 October 2026 the goal was renamed "inference verification", because high assurance in the token stream "can be achieved in several ways."

How does FlashProve work?#

FlashProve has two parties, the provider (the prover) and the user (the verifier), and it runs in two phases, plus the check.¹

The proof is a zkSNARK, short for zero-knowledge succinct argument of knowledge. Anthropic lists four properties:

• Completeness. An honest prover's proof is accepted.
• Soundness. "It is effectively impossible (i.e., tantamount to breaking widely believed cryptographic assumptions) to produce a valid proof of a false statement, so the verifier does not have to trust the prover."
• Zero knowledge. The verifier "learns nothing about the weights, the intermediate values of the computation, or which experts ran at every layer." The model's architecture is not hidden.
• Succinctness. A run of a model of about 232 GB, in its quantized form, is checked from a proof of about 19 MB, in seconds.

The construction follows a well-known recipe: an interactive oracle proof, turned into a single proof file with hash functions, the same family of proof systems that Ethereum layer-2 networks such as Starknet use. The technical report adds that it relies on the security of hash functions, which also gives it plausible security against quantum computers.² It uses no trusted hardware. Anthropic describes trusted execution environments, chips that attest to what they ran, as a complementary approach: their guarantees rest on the manufacturer, while a zkSNARK's rest on problems believed to be infeasible to solve.

Part of the speed comes from the model's design. Maverick is a mixture-of-experts model: each token passes through a few expert sub-networks, about 17 billion of its 400 billion parameters, and FlashProve's work per token follows those, while the proof still hides which experts ran. The prover also streams the weights from ordinary memory, so one 80 GB GPU, with about 290 GB of host memory beside it, is enough.

How fast is FlashProve, and what does it cost?#

Anthropic measured FlashProve on Llama 4 Maverick with a public 4-bit version of its weights, one 1,024-token window per request.¹

Proving costs about two orders of magnitude more GPU time than serving the reply. That is far less than earlier systems needed (next section), but it is still much more than serving, and Anthropic describes its approach as post-hoc proving, "proving after-the-fact, for a subset of tokens", not proving every token as it is served. The technical report is plain about what that means: post-hoc proving "does not prevent users from being served incorrect responses, it only ensures tampering will be detected."²

How does it compare with earlier proofs of inference?#

Proving that a neural network ran correctly has a name in cryptography, zkML, and a short history of very slow results. Anthropic's post lists them:¹

The clearest comparison is on the same model. VerInf proved Maverick at about 0.02 tokens a second, with a 93.6 GB proof; FlashProve proves it at about 110, with 19 MB. Anthropic's conclusion is that the overhead of proving, "roughly 2 orders of magnitude", is "much less than previously expected", and that the progress "should transfer to more models and architectures." That last part is an expectation: FlashProve has been shown on one model.

What does a FlashProve proof say, and what does it not?#

The statement a proof makes is narrow on purpose: "The committed model produces these output tokens when evaluated."¹ For anyone thinking of relying on it, the limits matter as much as the speed.

What it shows. That the weights behind the commitment, run on this prompt, give exactly these tokens. Precisely, it is about an exact integer version of the published weights, and each checked token is that model's most likely next token: "The proof is about an integer model under greedy decoding." In the repository's soundness theorem, a proof of a false claim is accepted with a probability of at most about q/2^124 + 2^-101 after q hash queries, and Lean checks that theorem by machine, for the verifier written in Lean.⁴

What it does not show.

• That the reply is right. A proof is about which computation produced the text, not whether the text is true, sensible or safe.
• What the model is called. A proof ties a reply to a commitment, and the commitment to one set of weights. Which model those weights are is what the commitment's publisher says; for secret weights, nobody else can look.
• Sampled or floating-point replies. Models are usually served in floating point and with sampling. Such a reply "could depart at some position and no longer exactly match the computation proved." The integer model is "empirically tested to be within some small error rate" of floating-point inference, "though this does not cover adversarially designed prompts." The technical report points to statistical methods that tell benign numerical noise from tampering.²
• Long conversations. Contexts are limited to 1,024 tokens, "quite short in comparison to the contexts accumulated in chat settings."
• Everything else the hardware did. As noted above, a proof of serving does not show that the same chips were not also training.
• The architecture. Only the weights are hidden.
• Timing. Side-channel attacks, "such as measuring the time it takes to produce a proof", are "out of scope for this release."
• That the fast code is the proved code. Lean proves soundness for the Lean verifier. The C++ verifier, the one users run, and the CUDA prover "are written to follow the same protocol and are tested against it, not themselves proved." On hiding the weights the repository is candid: "We expect, rather than know, that the programs hide the weights."⁴

How did Anthropic use AI to build FlashProve?#

The release is also an example of AI-assisted research that says which parts the AI did. The post says "Claude has produced improvements on zkSNARKs for inference", and explains the safeguard: "Claude is good at optimization, but often makes decisions that are hard to evaluate, especially in large complex systems. We counter this by providing top-level auditable statements in Lean (a formal verification language) for the claimed security guarantees."¹

The technical report goes further:²

• The C++ prover and verifier "are obtained by AI agents from their Lean representations", and "formal equivalence of the C++ code to the Lean specification is not proved."
• The long protocol description in the repository "was AI-generated, and we did not review it in detail. A carefully-reviewed paper will follow later. This report, by contrast, was written by its authors."
• The formal statements "have been checked for correctness both by hand and by an AI agent. We expect that it should not take an expert more than a few hours to independently audit them."

The repository's README has a section headed "Built to be run by an agent", with a prompt to give a coding agent: build the verifier, check a stored proof, report back, and ask before starting anything heavier.³ It is the kind of statement of who did what that the Harvard CMSA report asks of AI-assisted mathematics (see what the CMSA report recommends): the AI's part, the humans' part, and what a reader still has to check.

Can you use FlashProve today?#

Not as a service. The release has no API, it proves only Llama 4 Maverick run by whoever runs the prover, and it makes no proofs for replies from Claude, ChatGPT or Gemini. FlashProve is code under the Apache 2.0 licence, version 0.16.0, described as "A research artifact: not maintained, not accepting contributions."³ The model's weights are not in the release: readers download Maverick from Hugging Face themselves, under Meta's licence.¹

The repository describes four routes:

Route 1 is cheap, but its example is a small model with synthetic weights: it "shows only that the verifier works, not anything about a served model." Proving anything real needs a dedicated H100 and a few hundred gigabytes of memory. A provider that wants to commit to and serve its own model is pointed to the repository's serving guide and a list of the operator's duties, "required reading before using weights that must stay secret."

What would it change for research records?#

Journal and funder policies on AI ask authors to name the tools and models they used (see how to disclose AI use in research). Those names are statements: nothing in a paper lets a reader check them. The same holds for research records on Papex today. A record lists the AI apps and models that the researcher, or their AI app, reported, and Papex treats those names as self-reported, because it has no way to check them.

Proofs of inference are the kind of evidence that could change that, for the steps they cover. A provider's commitment, the prompt, the reply and the proof are files; kept with a record, they would let anyone run the verifier again, years later, without trusting the provider or the record's author. A signature and an independent timestamp say who stood behind a version and when it existed; a proof of inference would say which weights produced a given text.

It would still be narrow. A proof would show which weights produced which text, not whether the analysis was sound, whether a person checked it, or whether the result holds. Those stay with people: review, replication and, in mathematics, formal proof. And three things stand in the way today. Research sessions with AI apps run far past 1,024 tokens and use sampling. The models most researchers use are closed, and we know of no provider of a closed model that offers such proofs with its replies. And a proof costs about 70 to 95 times the GPU time of the reply.

One idea in Anthropic's post deserves a second look from science. A provider could give a developer a "Proof-of-Failure that the model-provider spent at least X tokens on a specific model, and did not achieve a specific result", for example that a model found no bugs in a patch after at least a million tokens.¹ Failed attempts are what AI agents tend to leave out of their reports (see AI agents and negative results). A checkable record of an attempt that did not work would be new.

Key terms#

Sources#

1. Anthropic (Frontier Red Team), Progress on provable inference for large language models (2 November 2026), checked 3 November 2026 ↩ a b c d e f g h i
2. Roy Rinberg, Alex Allain, Alessandro Chiesa, Miranda Christ, Rahul Dalal, Giacomo Fenzi, Ben Mayer and Guy Weissenberg, FlashProve: an open-source library for provable inference, technical report (November 2026), 23 pages, checked 3 November 2026 ↩ a b c d
3. anthropics/FlashProve on GitHub, README (version 0.16.0), checked 3 November 2026 ↩ a b c
4. FlashProve guide, What is proved, and of what, checked 3 November 2026 ↩ a b