Summary: Anthropic’s Frontier Red Team published progress on provable inference on November 2, 2026, releasing FlashProve, an open-source zkSNARK prototype that proves a response came from a specific model without exposing its weights. On a 400B-parameter Llama 4 Maverick in 4-bit quantization, a single H100 generates proofs at roughly 110 tokens/second. It’s an intermediate research release, not production infrastructure — but the gap between “impossible” and “orders of magnitude away” just narrowed a lot.
Why you can’t verify your model today
When you call an API through a router or a hosted endpoint, you take it on faith that the model you paid for is the model that answered. Judging by output quality is unreliable — a cheaper substitute can produce plausible text. Anthropic points at three cases where this matters: evaluators who need to confirm they’re testing the served model, clients behind third-party routing services who want the tokens they paid for, and defenders worried about a tampered token stream, or even a model quietly swapping itself in for another to dodge monitoring.
Recomputing the answer yourself doesn’t work either. You’d need the weights (usually private) and compute far beyond what a typical user or evaluator has. Provable inference flips this: the provider attaches a short cryptographic certificate to each response, and you verify it on a CPU in seconds. zkSNARKs are the right primitive because the proof is succinct (exponentially cheaper to check than to produce) and zero-knowledge (it reveals nothing about the proprietary weights). Only the weights are hidden — hiding the model architecture is not a goal of this system.
The numbers, honestly framed
For Llama 4 Maverick (400B mixture-of-experts, 4-bit quantized weights, integer arithmetic in prefill), FlashProve generates proofs at around 110 tokens/second on one H100, with a proof size of about 19 MB per 1,024-token request. That’s roughly 70–95 times the GPU time of running the same model on vLLM.
So the overhead is still large — this is not something you bolt onto a consumer product tomorrow. But Anthropic states that prior open-source systems were orders of magnitude slower, which is what makes the current numbers notable. The interesting engineering claim: Claude itself found novel ways to apply state-of-the-art tools from the cryptography literature, layered on well-established proof-system design principles. Because an optimizing model’s decisions can be hard to audit in a large system, the team backed the security guarantees with top-level statements formalized in Lean.
What gets released, and who it’s for
Five artifacts shipped under Apache 2.0: the blog post, a technical report, a protocol description, executable code (a prover, a fast C++ verifier, and a provably correct verifier in Lean), and the Lean proofs themselves, plus an interactive visualizer to help with auditing. Anthropic frames this explicitly as intermediate progress, shared so others can take it and improve it.
The use cases go beyond “is my router cheating me”:
- Regulatory pacing. A regulator could require certificates showing hardware was genuinely serving the claimed model during a monitoring period, without learning proprietary model details. The limitation Anthropic notes: this verifies inference happened, not that the hardware isn’t training on the side.
- Tamper detection. Proofs are bound to a specific commitment to the weights, so a compromised server or a substituted model can’t forge them. This pursues the same goal as Anthropic’s earlier signing-based prototype from its Frontier Safety Roadmap, via a different method.
- Provenance claims. A vendor claiming a frontier model scanned their library for vulnerabilities could attach proofs rather than forgeable chat logs.
How to think about it as a builder
None of this changes what you ship this quarter. But it’s worth tracking where verification is heading, because trust mechanisms tend to start as research artifacts and end up as procurement requirements. If you’re building on routed or hosted inference, the problem FlashProve addresses — proving which weights actually served your request — is adjacent to work like Cohere’s Model Vault, where the environment is proven before data is sent. One proves the model, the other proves the environment; together they sketch what verifiable AI infrastructure might look like.
Practical next step: read the technical report if you work anywhere near inference infrastructure, and watch whether proof overhead drops toward the 2–5x range. That’s roughly where this stops being a research demo and starts being a line item in your architecture.
Sources
View the original post on X