What did Anthropic release on November 2?
Anthropic published a research post and a code release for FlashProve on November 2, 2026. The system lets an AI provider prove that a reply came from a specific set of model weights. It does so without publishing those weights. The code, Lean proofs and documentation sit on GitHub under the Apache 2.0 licence.
The release is a prototype, not a product. Anthropic describes the post as "intermediate progress" and invites outsiders to take the work and improve it. TechCrunch reports that Anthropic has no plans to deploy the system in Claude or at any other lab.
FlashProve was tested on Meta's Llama 4 Maverick, not on a Claude model. Maverick is a mixture-of-experts model with 400 billion parameters and 128 experts, and about 17 billion are active per token. Anthropic ran a third-party 4-bit conversion hosted on Hugging Face. The weights stay on Hugging Face under Meta's licence.
The author list mixes Anthropic staff with academic cryptographers. Contributors came from EPFL, MIT, StarkWare and Succinct. The technical report is dated November 2026 and runs to 23 pages. It covers the protocol, its Lean formalisation and its measured performance.
How does provable inference work?
The idea is to turn a model provider into a cryptographic prover. In an offline step, the provider commits to the weights and publishes a short digest. That commitment binds the provider to one exact model, while the weights themselves remain secret.
For each request, the provider's GPU produces a proof about that commitment. The proof says the committed model generated the claimed token from the given prompt. Anyone holding the digest, the prompt and the reply can check it. The checker needs no weights and no GPU.
FlashProve uses a hash-based zkSNARK. A zkSNARK is zero-knowledge, so the proof reveals nothing about the weights. It is also succinct, so verification costs far less than running the model. Those two properties are what make the approach practical for closed models.
The construction relies only on hash functions, specifically the compression function inside BLAKE2, rather than elliptic curves. Anthropic argues this basis offers plausible post-quantum security. The report notes that the same family of proofs secures Ethereum layer-2 networks such as Starknet and Mantle.
Trusted execution environments are a common alternative to this approach. They use hardware attestation to show which code is running inside a protected enclave. That places trust in the chip manufacturer rather than in a mathematical argument. Anthropic describes trusted hardware and cryptography as complementary, with different guarantees and different failure modes. FlashProve tests the software-only path.
Clients download 6.24 megabytes once, covering the commitment and the offline proof. After that, each reply arrives with its own proof. A consumer CPU checks the proof in seconds. The provider keeps the expensive work on its own hardware.
The security claim is narrow and precise. A dishonest provider cannot pass off a different model's output unless it breaks the underlying hash assumption. The proof does not establish that the model is good, safe or unbiased; it establishes only which weights produced the tokens.
Anthropic proves soundness in Lean 4, a proof assistant that machine-checks mathematical arguments. The verifier is released as open code, so outside researchers can inspect it. That matters because cryptographic code is easy to get subtly wrong, and a flawed verifier would undermine the whole guarantee.
How fast is FlashProve, and what does it cost?
The prover is a single Nvidia H100 with 80 gigabytes of memory and 24 CPU cores. Maverick's 4-bit weights occupy 232 gigabytes, so they live in host memory and stream to the GPU. The GPU holds one segment of the computation trace at a time.
Anthropic batches up to 64 requests. A batch of 24 takes about 223 seconds, which works out to 110 tokens per second. Each proof is 18.78 megabytes for a 1,024-token request. The offline commitment step runs once per model and takes about 39 minutes.
Latency is a separate matter: an individual request waits about five minutes for its batch to finish, according to the report. Proving requests one at a time cuts that wait to 58 seconds, but throughput falls to 17.6 tokens per second.
Proving is expensive relative to ordinary serving. Anthropic compared it with vLLM running the same model in FP8 across eight H100s. Proving a 24-request batch took 66 to 77 times longer per GPU. At the highest load tested, the gap reached about 94 times.
Verification is cheap by comparison. Checking a proof takes 17 seconds on 24 threads and 21 seconds on one thread. Bankless reports the same 17-to-21-second range. That asymmetry is the design goal: providers absorb the cost, while auditors and users get a quick check.
The report is candid about the trade-off. Proving costs roughly two orders of magnitude more than inference, which is better than earlier zero-knowledge systems but still far from free. The authors also note that recomputation adds only 1% to 1.5% of the prover's work, because proving dominates.
That overhead is lower than earlier zkSNARK work. The report says even specialised provers often run more than 200 times slower than the computations they certify. FlashProve's margin is therefore an engineering result as much as a cryptographic one.
There is a subtlety in the throughput figure. A 1,024-token request is processed in full, but each proof certifies only one token: the one that follows the prompt. Checking every token of a reply made no measurable difference to speed, the authors say. Counted that way, the rate is 39.1 certified tokens per second.
Why does model identity matter to users and regulators?
Most people assume the model they pay for is the model that answers. That assumption is hard to test from the outside. A routing service could quietly substitute a cheaper model and keep the difference. Output quality alone is weak evidence of provenance.
Independent evaluators face the same problem before and after release. They need proof that the system they are testing is the system being served. Benchmark results lose value if the underlying model can change between runs.
The buyers most exposed are companies that resell model access. Aggregators and routers bill customers for one model while choosing among several backends. Anthropic cites third-party routing services as one of the main cases for provable inference. Procurement teams would gain a way to check a vendor's claim instead of accepting it on trust.
The mechanism could also support third-party claims. A developer might say a frontier security model scanned its code for bugs. A company might say an approved model signed off on a plan. Proofs could turn those statements into checkable receipts.
Security is the second motive. A compromised inference server could tamper with replies while hiding among genuine traffic. A model capable of improving and deploying itself could impersonate a weaker, less monitored system. Proofs bound to committed weights make both tricks harder to sustain.
Regulators are the third audience. Some policy proposals would monitor whether AI hardware serves inference rather than training. Proofs could show which model handled each request without exposing proprietary weights. Anthropic notes a limit: a proof cannot show that the same hardware is not training on the side.
The company had already promised work in this area. Its Frontier Safety Roadmap set a goal to build a provable-inference prototype by September 30, 2026. Anthropic says it met that goal through a separate project that signs traffic and recomputes responses on a trusted server. FlashProve is a different, purely cryptographic route to the same objective.
Anthropic also changed its terminology. An October 19, 2026 update replaced the term provable inference with inference verification. The broader label covers several ways to assure the integrity of a token stream. That shift matters for how the company frames future compliance claims.
What can't FlashProve do yet?
The first limit is timing: FlashProve proves responses after they are served, not before. It can detect tampering, but it cannot stop a bad answer from reaching a user.
That leaves a window for data exfiltration. An attacker could leak information through a tampered reply before a failed proof raises an alarm. Operators must also trust their logs, which a compromised server could rewrite. Anthropic presents post-hoc proofs as one layer of defence, not a cure.
The second limit is decoding. The proof covers an integer version of the weights under greedy decoding or a fixed seed. It certifies that the checked token is the one that version would produce. A floating-point run, or sampling with a different seed, may diverge and stop matching the proof.
Scale is the third limit: requests are capped at 1,024 tokens, far below the long contexts agents now use. The prover runs on one GPU, and multi-GPU tensor parallelism is not supported. The architecture is also visible, even though the weights are hidden.
The formal guarantees have gaps. Lean proves the protocol at the information-theoretic layer. Zero knowledge is proved for single-request proofs, not yet for batched ones. The GPU prover code was generated by AI from its Lean description and is not proved equivalent to it.
The report itself carries an unusual warning. "The technical paper that describes the protocol was AI-generated, and we did not review it in detail," it states. A carefully reviewed paper is promised later. The repository is labelled version 0.16.0, not maintained and not accepting contributions.
A provider that adopted the design would also change how it serves traffic. Proofs are generated after the fact on separate proving machines, not on the inference servers themselves. That keeps latency intact, but it adds separate proving infrastructure to operate. For now, no lab has announced such a deployment.
None of this undermines the core result, but it sets the right expectation. FlashProve is a research artifact for external cryptographers to test, not a certified system for banks or regulators.
How does it compare with earlier zero-knowledge AI work?
FlashProve builds on a decade of zero-knowledge machine learning, often shortened to zkML. Early systems proved tiny networks: SafetyNets handled a two-convolution-layer MNIST network in 2017.
Progress since then has been steady. zkCNN reached VGG-16, a 15-million-parameter model, at 88.3 seconds per proof in 2021. zkLLM proved LLaMA-2-13B on a 2,048-token input in about 15 minutes in 2024.
The leap to very large models is recent. VerInf proved the same 400-billion-parameter Maverick at about 0.02 tokens per second. SASH reached about 1.25 tokens per second on Llama 3.1 8B with a single H100 in 2026.
Commercial systems now post faster numbers. Attestable reports 53 to 77 tokens per second for Gemma 4 31B on one H100. It has not released a matching open-source library, Anthropic says, so its methods cannot be independently checked yet.
FlashProve's 110 tokens per second at 400 billion parameters is therefore a notable open-source result. The comparison is not like for like, though. Models, quantization, batch sizes and the number of tokens actually certified all differ. Anthropic measures prefill throughput on batches while checking one token per request.
The lineage matters for credibility. Zero-knowledge proofs spent years as a blockchain curiosity with heavy costs. Each generation has cut overhead and raised model size. FlashProve continues that curve and applies it to a question the AI industry now faces directly: how do you know what answered?
What happens next for provable inference?
Anthropic has framed FlashProve as a starting point for others. The immediate test is external scrutiny. Cryptographers will check the protocol, the Lean statements and the claim that the AI-generated code matches its specification.
Cost is the next hurdle. A 66-to-94-fold overhead is acceptable for audits, spot checks and high-value claims. It is not acceptable for every chat reply at consumer scale. Proving also needs a dedicated H100, which most providers would rather use for serving.
Technical work could narrow the gap. Multi-GPU proving, support for sampled decoding and longer contexts are obvious targets. The authors also point to optimisations they deliberately skipped in this release, including prover memory and argument size.
Adoption matters more than speed. Proofs only help if providers publish commitments and routing services pass them through. Enterprises and auditors would then have a way to demand evidence rather than assurances. Model marketplaces could make provenance a standard field.
Standards are the missing layer. A commitment is only useful if auditors know where to find it and how to check it. Whether labs settle on a common format will shape how quickly proofs move from demos to procurement requirements.
Watch three signals. Does any lab commit to publishing weight commitments for production models? Do model marketplaces expose proofs alongside responses? Does Anthropic's reviewed paper survive inspection? Until those questions have answers, FlashProve is a credible demonstration, not a deployed safeguard.