Anthropic Cut a 93.6 GB Proof to 19 MB and Made 'Which Model Answered?' Checkable

Summary card titled Proving which model actually answered; stat strip reads 19 MB proof, 17 seconds to verify on 24 threads, 110 tokens per second on one H100 and 72 to 95 times the GPU time of plain inference; four cards explain what a proof states, the measured numbers, the jump over prior work, and the current limits — Original graphic by Guruji Corporation. Source: Anthropic, "Progress on provable inference for large language models", 3 November 2026.

Every AI proposal that lands on an Indian procurement desk contains a sentence nobody can verify: we use a frontier model for this step. The buyer cannot check it, the auditor cannot check it, and the vendor knows neither can. On 3 November 2026 Anthropic published a working answer — not a policy, not a pledge, but a cryptographically checkable certificate — and the numbers are the interesting part.

What was actually released

Anthropic published FlashProve, an open-source system for provable inference: a model provider first commits to one exact set of weights, then attaches a short proof to each response showing that those weights produced those tokens. The proof is zero-knowledge, so weights and chosen experts stay secret, and succinct, so the check runs on an ordinary CPU rather than the provider's cluster.

What shipped: the post, a technical report, a protocol description, executable code — a prover, a fast C++ verifier and a formally verified Lean verifier — and Lean proofs of the top-level security statements, all under Apache 2.0. The announcement thread names the motivation: proofs make it harder to hijack a chat session, and they let a safety evaluator confirm that the model it is testing is the model being served to customers.

The structure matters more than the mechanism. In the offline phase the provider publishes a commitment — a fingerprint pinning down one exact choice of weights — which took about 39 minutes to produce and is good for roughly 16 million requests. In the online phase, each request carries a proof that the committed model produced these tokens. The verifier downloads about 6.5 MB of commitment once, then one proof per request. Nothing else about the model is disclosed.

The numbers, and why they are the story

Anthropic measured on Llama 4 Maverick, a 400-billion-parameter mixture of experts that uses about 17 billion parameters per token, with publicly available 4-bit weights:

A single H100 generates proofs at 110 tokens per second on a batch of 24 requests, with each proof 18.78 MB covering a 1,024-token request.
The verifier needs 17 seconds on 24 threads (21 seconds on one thread) to check a proof, with no GPU.
Proving a batch of 24 requests takes about 72× longer per GPU than vLLM needs to process the same batch, in a range of 66–77× across runs, and about 94× at the highest vLLM load Anthropic tried.

Now compare against the state of the art it is stepping over. VerInf, the only earlier proof of the same Llama 4 Maverick model that Anthropic knows of, reported 14.3 hours for 1,000 tokens on a DGX Spark, with a 93.6 GB proof that took almost a day to verify. DeepProve, the current peer-reviewed best, reaches about 2.9 tokens/second for GPT-2 and 1.4 tokens/second for Gemma 3 on one machine. FlashProve is the same 400B model at 110 tokens/second with 19 MB proofs that check in seconds.

Two engineering decisions carry most of that. The prover's work is proportional only to the experts that actually ran — roughly 17B of the 400B parameters per token — and requests are proved in batches after the fact, opening the weight commitment once per batch instead of once per token.

One detail matters for anyone defending a system to an auditor. Anthropic states that Claude produced the zkSNARK optimisations, and that Claude "often makes decisions that are hard to evaluate, especially in large complex systems." So the security properties are written as auditable statements in Lean, and a provably correct Lean verifier ships beside the fast C++ one. The fast verifier carries no formal guarantee; it agrees with the Lean verifier on every proof in the test suite. That is a more honest framing of AI-written code than most vendors ship.

What it does not do — read this before quoting it

The release is explicit about its own limits:

Integer model, greedy decoding. The proof covers an exact integer version of the published weights and asserts that each checked token is that model's greedy choice. A reply from a floating-point implementation or from sampled decoding can drift and no longer match the proved computation.
1,024-token context. Real chat sessions accumulate far more. Extending to full context windows is listed as future work.
Mixture-of-experts only. The efficiency gains come from the MoE structure; the architecture itself is not hidden, only the weights.
Side channels excluded. Timing the proof generation could leak information about weights, and that is out of scope.
No guarantee that Lean, paper and code all match. Anthropic says so directly.

And the one that decides the timeline: TechCrunch reports that this is intermediate research with no plans to deploy it at Anthropic or any other lab. Nobody is selling you a provable-inference contract this quarter.

Why it matters for Indian SMBs and mid-market teams

Because "which model" is now a commercial claim, and commercial claims get checked. An Indian mid-market firm buying an AI-enabled product is usually buying a reseller's wrapper over somebody else's API. A routing service has a direct financial incentive to swap in a cheaper model at peak load, and the output looks fine — Anthropic names that exact scenario as a motivation. Until certificates are standard, "which model, which version, per request" is the cheap substitute.

Because auditors and regulators are asking for evidence, not descriptions. TRAI's draft AI guidelines, DPDP obligations, and any serious SOC audit converge on the same shape: an inventory, a named owner, an incident log, and evidence of what actually ran. A model-identity log is the primitive version of that evidence, and every API already returns the model name in its response. If your application does not store it, you have no record that the right model answered.

Because "we scanned it with a frontier model" is now a claim with a mechanism behind it. Anthropic sketches a proof-of-failure: a provider showing it spent at least a million tokens on a specific model and did not find a bug in a patch. Today that is a marketing sentence. In two years it may be a file in a due-diligence pack.

Because the overhead is 72–95×, and that is a budget line, not a detail. Read 110 tokens/second on one H100 as the cost of the certificate, on top of the cost of inference. That is affordable for audits, evaluation runs and regulated workloads, and not affordable for every chat message — which is why Anthropic proves batches after the fact rather than inline.

Where Guruji Corporation fits in

We do not build proof systems and we will not tell you a certificate is available today. What we build is the record layer the certificate eventually plugs into: an inventory that names the model and version behind each AI feature, per-request logging that survives an audit, a vendor register carrying "which model, which version, which contract clause", and the procurement trail that shows what was deployed versus what was invoiced.

That is our IT/OT asset portal work pointed at AI systems instead of servers — finishable in weeks, not quarters. If you have an AI feature in production and cannot answer which model answered on 14 October, fix that gap before the next audit, proof or no proof. Start with a short project brief.

Sources