Say you reach a model through a routing service. The bill names the expensive model, and the answers read about right. Still, nothing lets you confirm that nobody quietly sent your request to a cheaper model to save money, or tampered with the token stream on the way back. Anthropic says as much at the top of its research post: users today cannot check this, and judging by output quality alone is unreliable. On November 2, 2026, Anthropic's Frontier Red Team, working with researchers from EPFL, MIT and elsewhere, released FlashProve, a prototype for provable inference. The post says plainly that it is meant to share intermediate progress, not a completed research agenda.
It proves that the committed weights produce this token for this prompt
FlashProve uses a zkSNARK, a succinct zero-knowledge proof, in two phases. Offline, the provider publishes a commitment to the model weights, a short fingerprint that pins down one exact set of weights without revealing them. Online, the provider produces a proof file for a given request stating that the committed model produces these output tokens for this prompt. Anyone holding the commitment, the prompt and the response can check that proof without the weights and with modest compute.
The proofs come with four properties. Honest proofs are accepted. Forged ones essentially cannot pass, so you don't have to trust the provider. The proof reveals nothing about the weights, the intermediate values, or which experts each layer picked. And proofs are small and cheap to check. Anthropic machine-checked completeness, soundness and zero-knowledge in Lean, ships a slow Lean verifier with formal guarantees alongside a faster C++ one for everyday use, and released the code, Lean proofs and docs under Apache 2.0 on GitHub. The post also says Claude produced these improvements, and that the team leaned on auditable top-level Lean statements to offset design decisions by Claude that are hard to evaluate.
The uses the post sketches: an evaluator confirming that the model it tested is the one being served, a customer behind a third-party router confirming tokens came from the model they paid for, a company checking which weights actually run on its servers to catch a compromised machine or a swapped model, and a regulator requiring that only approved models be served.
What it can't prove is longer than the headline suggests
The technical report draws the boundaries more sharply than the blog, and several of them decide whether you can rely on it.
The proofs concern an integer version of Llama 4 Maverick, a 400B-parameter mixture-of-experts model, under greedy decoding. Per the report's abstract, each proof checks one output token, the token that follows the prompt. Real services mostly run floating point and often sample. In the report, of 96 greedy outputs from each of two floating-point engines, 16-bit and FP8, none matched the integer model at every position, so meeting the exact-match standard means the provider has to serve that integer model directly. A looser clipped-gap policy exists, but it accepts most outputs with one token replaced and most outputs sampled at temperature 0.7, and the report itself labels it weak.
Context is capped at 1,024 tokens, far from the long contexts you use in chat. Only the weights are hidden: the architecture is not, the system assumes a mixture-of-experts design, the report says each request leaks one bit that depends on the weights, and side channels such as timing are out of scope.
The formal guarantees cover the protocol and the verifier in Lean. The C++ verifier and prover you would actually run carry none, and the report notes that almost no attack was sought, so the absence of a described attack is not a finding of safety. Serving and proving have also not yet run together as one service.
Finally, this is not a Claude feature. The experiments use Meta's public Llama 4 Maverick weights, and neither the post nor the report says whether or when the Claude API might offer such proofs. For the regulatory case, the post concedes it can show hardware is doing inference but not that the same hardware isn't also training on the side.
The cost lands on the provider: one H100, 70 to 95 times the GPU time
On the provider side, the prover runs on one H100 with 24 CPU cores, streaming weights from host memory into the GPU segment by segment, and needs about 290 GB of host memory. The offline commitment happens once per model and takes about 39 minutes. One commitment covers roughly 16 million requests before the provider has to recommit. Online, a batch of 24 requests takes about 223 seconds, around 110 tokens per second. Read the report's fine print here: that rate counts prefill tokens, and with a single request per batch it drops to about 17 per second. Proving happens in batches after the fact, not inline, so your guarantee arrives with a delay.
Against vLLM, per GPU, proving a batch of 24 takes about 72 times as long as vLLM serving the same requests, between 66 and 77 across runs, and about 94 times at the highest load tested, 93.0x in the technical report. The report adds that this multiple leaves out committing and serving, so the true figure could be higher.
Your side is far lighter. You need only a CPU. You download a commitment of about 6.5 MB once, then roughly a 19 MB proof per request, which takes about 17 seconds to check on 24 threads and about 21 seconds on one.
Within this line of research the jump is real. VerInf, which the post cites, also targets Llama 4 Maverick and took 14.3 hours to prove 1,000 tokens, with a 93.6 GB proof that took nearly a day to verify. VerInf used its own integer model of Maverick on a DGX Spark and proves a different statement, though, so its numbers can't be compared directly with FlashProve's. The company Attestable reports 53 to 77 tokens per second on Gemma 4 31B, a dense model, on one H100, but has not open-sourced its work.
What the sources leave open
Neither the post nor the report says whether Anthropic will apply this to Claude or its own API, how long or how costly longer contexts, sampled decoding or a hidden architecture would be, or what end-to-end latency looks like once serving and proving are wired together on real traffic. A footnote does supply context: Anthropic's Frontier Safety Roadmap set a goal of a provable-inference prototype by September 30, 2026, and Anthropic says it met that goal through a separate project that signs inference traffic and recomputes it on a trusted server. FlashProve is the cryptographic route to the same end.
If you run model evaluations, or buy or audit third-party model services, read the limitations in Section 8 of the report and run the open-source code on a GPU machine now. Proofs attached to every API call are still far off, but checking a 400B-class model yourself now has public, reproducible numbers behind it.