How Do You Prove an API Didn't Swap Models? Anthropic Opens FlashProve

On 2026-11-02, Anthropic’s Frontier Red Team published the research post *Progress on provable inference for large language models* and released FlashProve, an open-source zkSNARK research prototype for provable inference. The problem it targets is simple to state and hard to solve from text alone: when an API returns tokens, there is usually no cryptographic way to check that those tokens came from the specific weights a provider claimed to run—rather than a cheaper substitute, a tampered stream, or another model presenting itself as the paid one. FlashProve’s answer is a three-step loop: Commit → Prove → Verify.

Related reading: Anthropic Used Claude to Formally Verify 123 Open-Source Libraries, Anthropic: Unreleased Claude Model Finds Critical Real-World Vulnerabilities, Anthropic Finds Experts Often Defer Judgment Calls to AI Agents, and Same Open Model, Different API: Why Speed and Cost Both Change. Those pieces cover formal verification of libraries, cybersecurity research models, agent judgment calls, and inference-provider variance. They are neighboring Anthropic / inference topics—not the same article as FlashProve’s zero-knowledge inference proofs.

Why “the reply looks good” is not a proof

Quality of output is a weak identity signal. A cheaper model, a quantized stand-in, or an attacker who edits the token stream can still produce fluent text. Independent evaluators, buyers who route through a third-party gateway, and operators watching for server compromise all face the same gap: re-running the claimed frontier weights locally is usually impossible (weights are private and the hardware bill is huge), while trusting the provider’s word alone leaves substitution undetectable.

Provable inference aims at a narrower, checkable claim: a party with limited compute and no weight access can still verify that a response was produced by a previously committed model. FlashProve implements that claim with a zkSNARK—a short certificate that is zero-knowledge (reveals nothing about the weights beyond what the statement already implies) and succinct (far cheaper to check than re-running the model).

Commit → Prove → Verify

FlashProve’s public narrative, matching both the research post and the GitHub README, is three phases:

1. Commit (offline). The provider publishes a short commitment ID that binds one exact choice of weights. The weights stay secret; later proofs are checked against that fingerprint.
2. Prove (online, GPU). For a prompt and the reply tokens, the prover produces a proof file asserting: *the committed model produces these output tokens when evaluated.*
3. Verify (CPU). Anyone who holds the commitment, the prompt, and the reply can run a verifier such as cp_verify and accept or reject the claim—without the weights and without a GPU for the check itself.

Completeness says an honest proof is accepted. Soundness says forging a valid proof of a false statement is effectively infeasible under the cryptographic assumptions. Zero-knowledge says the proof itself does not leak the weights, intermediate activations, or which MoE experts fired. Succinctness is why an auditor can check megabyte-scale proofs on a CPU instead of replaying a 400B-class forward pass.

What is proved—and what is not

The proved statement is model identity along the inference path: the committed weights, on this prompt, produce exactly these tokens under the protocol’s computation. That is not a certificate that the answer is factually correct, safe, or policy-compliant. A truthful model can still hallucinate; a wrong model that somehow matched the committed computation would be a soundness failure, not a “facts” failure.

Several protocol boundaries matter in practice:

• Integer model + greedy decoding. The proof is about an exact integer version of the published weights and asserts each checked token is that model’s greedy choice. A floating-point server path, or sampled decoding, can diverge at some position and no longer match the proved computation.
• Weights hidden; architecture not hidden. FlashProve hides weights. Architecture hiding is not a goal of this system (called out as future work). The design assumes a Mixture-of-Experts layout and uses MoE sparsity for prover efficiency.
• Context cap: 1,024 tokens. Windows longer than that are outside the current prototype.
• Post-hoc, not in-line. Proofs are generated after the fact for finished text (batch-friendly prefill-style work), not necessarily alongside every live token with in-line latency goals.

Lean formalizes top-level Completeness, Soundness, and Zero knowledge in the random-oracle model. The release includes an executable Lean verifier (slower, tied to the formal statements) and a fast C++ verifier for day-to-day use. The research post is explicit: the paper and fast code are derived from the Lean protocol, but there is no guarantee that Lean, the paper, and the fast executable all match each other. Side-channel leakage from proving time is out of scope.

Official Maverick example (self-reported; unretested)

The research post and README use Llama 4 Maverick—a 400B-parameter MoE (~17B parameters active per token)—with a public 4-bit weight conversion as the large-model demonstration. These figures are Anthropic’s published measurements. We have not retested throughput, proof size, verification latency, or vLLM ratios on DigIntoAI hardware.

The GitHub README banners the same ~110 tok/s at 24 requests/batch for full-size Maverick on one H100. README route tables further separate verify-only (ordinary Linux, low RAM) from full Maverick prove paths that need the GPU stack, on the order of 280–330 GB host RAM, large disk for the ~232 GB 4-bit download, and CUDA—not a “anyone can prove on a laptop” story. Toy / small-model routes exist for agents and CI; they are not substitute measurements for the Maverick numbers above.

Research prototype status, not a Claude API switch

FlashProve’s repository description reads: *A research prototype for zero-knowledge proofs of AI inference. Not maintained.* The README header states Version 0.16.0, a research artifact: not maintained, not accepting contributions, under Apache 2.0. GitHub API metadata matches Apache-2.0, archived=false, description “Not maintained.” Repository created_at 2026-10-30T19:29:59Z = 2026-10-31 03:29:59 Asia/Shanghai; pushed_at 2026-10-30T21:00:23Z = 2026-10-31 05:00:23 Asia/Shanghai—the public repo clock sits before the research post’s Published Nov 2, 2026 date.

This release is not “Claude API now ships end-user verification for every chat.” Code, Lean proofs, and documentation are under Apache 2.0 with an explicit research-prototype framing and a long limitations list.

On the Frontier Safety / RSP side, Anthropic had set a public goal to produce a prototype for verifying inference traffic by 2026-09-30. The research post states that goal was met through a separate but related project that signs inference traffic and recomputes inference on a trusted server. FlashProve pursues the same objective by a different method—cryptographic zkSNARK proofs rather than that signing-and-recompute path. A footnote dated from the 2026-10-19 RSP update notes the goal name shifted to “inference verification”, framed as broader than “provable inference” alone.

Operator checklist

1. Clock. Research post Published Nov 2, 2026; team Frontier Red Team. Repo created 2026-10-31 03:29:59 Asia/Shanghai (UTC 2026-10-30T19:29:59Z).
2. Loop. Offline Commit → GPU Prove → CPU Verify (cp_verify). Statement: committed weights produce these tokens.
3. Boundary. Proves identity / inference process—does not prove factual correctness.
4. Decode. Integer + greedy; float or sampling can mismatch.
5. Privacy. Weights hidden; architecture not hidden; MoE-oriented.
6. Window / timing. Max 1,024 tokens; post-hoc batches, not in-line.
7. Trust split. Lean theorems + slow Lean verifier vs fast C++ verifier without a three-way formal match guarantee.
8. Numbers. ~110 tok/s, ~19 MB, ~17–21 s verify, ~70–95× vs vLLM = official self-report; we have not retested.
9. Hardware. Verify can be light; full Maverick prove needs H100-class GPU and large host RAM—not universal laptop proving.
10. Status. Apache 2.0; v0.16.0; not maintained / not accepting contributions; not a shipped Claude API verification product. RSP signing+recompute track is related but separate.

Bottom line

FlashProve is Anthropic Frontier Red Team’s open zkSNARK research prototype for proving that an API reply came from committed weights without publishing those weights. The useful mental model is Commit → Prove → Verify, with sharp edges: greedy integer semantics, 1,024-token windows, post-hoc proving, architecture still visible, and a research-artifact maintenance stance. Official Maverick throughput and overhead numbers are on the research page and README as provider measurements—we have not retested them. For teams that care whether a router or a compromised host swapped models, the cryptographic claim is about which weights ran, not whether the tokens are true. Live notes can go through the site-owner contact in the footer.