Anthropic’s FlashProve repo: falsify a runnable zk inference-proof prototype, not production PI

Anthropic released FlashProve on GitHub. The repo reports Version 0.16.0 under Apache 2.0 and states up front: a research artifact, not maintained, not accepting contributions. The sibling research post “Progress on provable inference for large language models” (2 Nov 2026) already has its own desk treatment here; this piece watches the circulating artifact: what it promises, what it can run, and what it refuses to claim.

The news core is not “Anthropic shipped production provable inference.” A falsifiable reading watches three things: whether a normal Linux user can follow Route 1, build cp_verify in minutes, and get YES on the stored example; whether Lean’s top-level soundness covers the protocol and Lean verifier rather than the CUDA prover programs themselves; and whether clipped-gap acceptance is misread as “the reply equals the committed model.”

Hard facts (repo README + GitHub API at fetch time):

• Three roles: Commit (publish a commitment ID bound to one weight set; weights stay secret), Prove (GPU proof per reply), Verify (cp_verify on CPU without weights).
• Claimed model path: Llama 4 Maverick at full size; 1,024-token context; one NVIDIA H100; about 110 tok/s prefill at batch 24.
• Agent routes: Route 1 needs Linux/bash/g++ 13+, under ~2 GB RAM, builds the verifier and checks a stored example; Route 2 CPU toy proofs; Route 3 small or full-size synthetic models need the GPU stack and large RAM; Route 4 downloads a public 4-bit conversion (~232 GB) and proves one token on real Maverick weights, with higher disk and memory floors.
• Soundness: protocol soundness is stated in Lean 4; the repo puts the catch probability for a cheating reply near q/2^124 + 2^-101 after q hash queries (see lean/THEOREM.md).
• Research-post numbers (secondary): for Llama 4 Maverick (~400B MoE, 4-bit, integer prefill), one H100 generates proofs at ~110 tok/s with ~19 MB per 1,024-token request; about 70-95× the GPU time of running the model on vLLM. Code, Lean proofs, and docs are Apache 2.0.
• Explicit: not accepting contributions; Serving pages and Known limits are required reading before secret weights.

Evidence grade: primary is a clonable repo and its docs; some performance and security figures sit in the README/Lean tree, others in Anthropic’s research post. This desk did not finish H100 Routes 3/4 here, nor re-run the Lean checking scripts; Route 1-class claims are cheap to spot-check on an independent machine.

Mechanically, FlashProve targets the gap where a user cannot tell from the output alone which weight set answered. Commitments hide weights; hiding architecture is not a goal. A verifier accept does not say “this is the provider’s real flagship model.” It says the reply met the check policy for that commitment. Known limits are blunt: build cp_verify yourself; take the commitment ID from a party you trust, never from the server under test; WITHIN LIMITS (clipped-gap) only means token costs meet the policy, not exact-match “this is the model’s output.” The project even recommends accepting only exact match if you cannot assess policy limits.

Steelman: if independent labs can rebuild the verifier, get YES on the stored proof, and (with hardware) run the synthetic full-size path, and if they keep Lean’s top-level theorem distinct from the programs’ printed “bits,” then the artifact supports a narrow claim. zk proof-of-inference has left the paper figure and become an auditable, redistributable prototype, with Not maintained as an intentional brake on over-claim.

The strongest steelman risks are the ones the docs already name. The C++ verifier and CUDA prover are written to follow the same protocol and tested against it; they are not themselves Lean-proved. The honest prover in the theorems is a Lean definition, not the shipped GPU program. Proofs concern a quantized fixed-point integer model; relative to the floating-point original, the repo cites a measurement where the top token differed at about 6.81% of positions, and that gap is outside the proof. Commitments expire after a calculated batch budget; a new commitment gets a new ID with no proof linking old and new. Batch-64 on an 80 GB card is not a settled record in their notes; the example front end started with sudo can be led to emit root-only files.

The research post likewise calls this intermediate progress meant for others to take and improve, not a finished agenda. Reading star counts or the Anthropic name as a production SLA is a reader error, not a repo promise.

For evaluators and buyers, the six-month check is whether third parties publish reproducible Route 1/2 reports, whether anyone posts a synthetic full-size H100 run with the final cp_verify line, and whether clipped-gap gets sold as customer-facing “model identity.” For crypto and security readers, Lean top-level statements sitting beside “Fiat-Shamir attacks not examined against this protocol” is an audit checklist, not a buried flaw.

For maintainers and agent users, the repo assigns long builds and exact comparisons to coding agents and forbids sudo/chmod workarounds. That shifts the default from “hand-try the README” to “scriptable checks,” without promising ongoing product support.

Test a buildable verifier, the documented limits, and whether Not maintained stays in front of the reader. If those hold, FlashProve is a circulating research artifact. If it is retold as “production provable inference is live,” the fault is the narrative, not the repo banner.

【No.2】