FlashProve is Anthropic’s open-source research prototype for provable inference, letting a model provider generate a cryptographic proof that a reply came from a specific set of committed weights without revealing those weights. Released in November 2026 and demonstrated on Meta’s Llama 4 Maverick, it cannot yet be switched on for Claude API traffic or third-party routers.
Can an API router secretly swap your model?
Yes, a third-party routing service or reseller can substitute a cheaper or smaller model behind the scenes, and you cannot reliably catch the swap just by reading the replies.
When you look at an official AI API pricing comparison, the appeal of discount API routers and resold proxy endpoints is obvious. Frontier models are expensive at high volume, and a middleman promising the same model ID at a steep discount is tempting for any developer or team lead watching their monthly bill.
The catch is that an API response’s model field is just a string the server sends back. In its November 2, 2026 research post, Anthropic’s Frontier Red Team stated the problem plainly: a user querying a model today cannot check that responses came from the specific model a developer claims is responding, rather than one “secretly substituted in by a routing service for cost reasons, or even by an attacker who has tampered with the token stream.” Anthropic’s technical report adds that a provider could use a smaller or weaker model, or even switch models between requests.
Many developers assume they would notice a downgrade through “vibe checks” or spot-testing prompts. Anthropic explicitly warns that judging from a model’s output alone is unreliable, even when the responses look high quality. Smaller models and quantized variants often handle routine prompts well enough to pass casual inspection while failing on harder edge cases you only notice in production.
What is FlashProve?
FlashProve is a software-only cryptographic system that uses a zero-knowledge succinct argument of knowledge (zkSNARK) to prove a specific committed model produced a given sequence of output tokens.
Instead of relying on trusted hardware enclaves—which Anthropic notes are complementary to cryptography—FlashProve relies on math. The workflow involves two parties, the model provider (the prover) and the user (the verifier), operating across three steps:
- Commit (offline): Before serving requests, the provider computes and publishes a cryptographic commitment to the model weights. You can think of this commitment as a short, unforgeable fingerprint that pins down one exact set of weights while keeping the weights themselves secret.
- Prove (online, post-hoc): After generating output tokens for a prompt, the provider runs the prover to generate a proof file showing that evaluating the committed model on that prompt produces those exact tokens. Proofs are generated in batches after the fact rather than in-line while tokens stream to the user.
- Verify: Anyone holding the commitment, the prompt, and the reply can run a lightweight verifier program on a standard CPU to check the proof in seconds, without ever seeing the model’s weights.
For developers who aren’t cryptographers, a zkSNARK provides four practical guarantees that Anthropic highlights in its release:
- Completeness: If the provider actually ran the committed model as claimed, an honest proof will pass verification.
- Soundness: A provider cannot forge a passing proof for a different model short of breaking widely believed cryptographic assumptions.
- Zero-knowledge: The verifier learns nothing about the secret weights, the intermediate activations, or even which specific experts ran inside a mixture-of-experts model. (The model’s overall architecture, however, is not hidden.)
- Succinctness: The proof is small enough to download easily and fast to check compared to re-running a massive model yourself.
Anthropic released five artifacts under an Apache 2.0 license on GitHub (anthropics/FlashProve, version 0.16.0): the research post, the technical report, a Claude-written protocol specification, the codebase (including a CUDA prover, a fast C++ verifier called cp_verify, and a provably correct Lean verifier), and formal Lean proofs paired with an interactive visualizer. Anthropic notes that Claude produced the underlying zkSNARK improvements, and the team used formal statements in the Lean proof assistant to make Claude’s complex design decisions auditable.
How fast is FlashProve, and how big are the proofs?
As of November 4, 2026, Anthropic reports that FlashProve can generate proofs for a 400-billion-parameter mixture-of-experts model at roughly 110 tokens per second on a single NVIDIA H100 GPU, producing proofs under 19 MB that verify in 17 seconds on a CPU.
Anthropic benchmarked FlashProve on Meta’s Llama 4 Maverick, a prominent example among open-weight models that uses 400B total parameters with roughly 17B parameters active per token (about 232 GB in public 4-bit quantized weights). Here are the exact numbers Anthropic reported on November 2, 2026:
| Metric | Anthropic FlashProve Result (Llama 4 Maverick) |
|---|---|
| Model tested | Meta Llama 4 Maverick (400B total, ~17B active/token, 4-bit weights, ~232 GB) |
| Prover hardware | 1× NVIDIA H100 GPU + 24 CPU cores |
| Offline commitment time | ~39 minutes once per model (valid for ~16 million requests before re-committing) |
| Proving speed | ~223 seconds for a batch of 24 requests (~110 tokens/second) |
| Proof size | 18.78 MB per request (~19 MB for a 1,024-token request) |
| Client commitment download | ~6.5 MB total |
| Verification time (CPU only) | 17 seconds on 24 CPU threads (21 seconds on a single thread) |
| Compute overhead vs. vLLM | ~72× per-GPU time (66–77× across runs); ~94× at vLLM’s highest tested load (~70–95× range) |
| Context length limit | Up to 1,024 tokens |
To put those numbers in perspective, Anthropic compared FlashProve against prior open-source art (VerInf) on the same Llama 4 Maverick model. According to Anthropic, VerInf ran at roughly 0.02 tokens per second—taking 14.3 hours to prove 1,000 tokens, generating a 93.6 GB proof, and requiring almost a full day to verify. Shrinking a 93.6 GB proof down to 18.78 MB moves cryptographic inference verification from theoretical math into something a client machine can actually download and check.
Still, a 70× to 95× compute overhead compared to standard vLLM serving explains why proofs are produced post-hoc in batches rather than attached to every live chat reply for free.
What FlashProve does not prove
FlashProve is an unmaintained research prototype with strict technical constraints, meaning a passing check does not guarantee floating-point equivalence, full-conversation coverage, or audited production security.
If you read Anthropic’s known-limits.md and what-is-proved.md guides in the repository, the team is commendably candid about where the boundaries lie as of November 4, 2026:
- Integer model and greedy decoding only: The proof applies to a quantized, fixed-point integer version of the model running greedy decoding (always picking the single highest-scoring token). Real-world APIs usually use floating-point arithmetic and random temperature sampling. Anthropic reports that in one measurement, the top token differed at 6.81% of positions between the integer model and a floating-point implementation.
- Looser “clipped-gap” acceptance policy: Because serving systems can diverge slightly from the integer reference, the verifier supports a looser policy that outputs
WITHIN LIMITS. Anthropic warns that an accept under this looser policy does not by itself prove the reply is the model’s; if you cannot independently assess those tolerance limits, you should accept only an exact match. - Short context limit: Proofs currently support contexts up to 1,024 tokens, which Anthropic calls “quite short” compared to normal coding or chat sessions.
- MoE architectures only: The current implementation only supports mixture-of-experts architectures and does not hide the model’s architecture or protect against side channels like timing attacks.
- Token-level scope with no metadata: A valid proof covers only the specific tokens checked, and it embeds no client identity or timestamp.
- No independent security audit: While the reference verifier written in Lean is formally proved sound, the fast C++ verifier (
cp_verify), the CUDA prover, and the committer do not have formal guarantees—cp_verifyis merely tested against the Lean verifier. Furthermore, Anthropic states that the programs and proofs have had no independent security audit, and the repo is published as a research artifact that is neither maintained nor accepting contributions.
Why the commitment ID matters more than the proof
A valid FlashProve proof only confirms that a reply came from whichever weights match the commitment ID, so a dishonest router could commit to a cheap model and hand you a mathematically valid proof for the wrong model.
This is the single most important takeaway for anyone worried about third-party API routers. In the repository’s “Known limits” guide, under the heading The provider chooses the model, Anthropic writes: “A yes does not say whose weights they are… A provider can commit to any model it likes, a small or degenerate one included.”
Imagine you are paying a sketchy API router for access to a frontier 400B model. To save money, the router secretly runs a cheap 8B model instead. If the router generates its own FlashProve commitment to that 8B model, runs your prompt through the 8B model, and sends you the reply alongside the proof and its commitment file, the C++ verifier on your laptop will output a pass. The math is completely valid—the 8B model really did produce those tokens.
That is why Anthropic gives a strict operational rule: “Get the commitment ID from a party you trust, never from the server you check or from files sent with a proof.”
For provable inference to catch a dishonest router, the original model creator (such as Anthropic or Meta) or a trusted independent auditor must publish the official commitment ID for the real weights. Only when you verify the router’s proof against the owner’s official commitment ID does the cryptography trap a model swap.
What this means for routers, resellers, and evaluators
If model creators eventually publish official commitment IDs and support provable inference, third-party routers and cloud hosts will be able to prove they served the exact weights you paid for without exposing proprietary model files.
In its announcements on November 2 and November 3, 2026, Anthropic outlined several groups that stand to benefit as this technology matures:
- API router customers: Teams routing traffic through third-party inference providers could audit a sample of their requests post-hoc against the model creator’s published commitment ID, so a silent downgrade would fail the check.
- Independent safety evaluators: Pre- and post-release evaluators can verify that the model they are testing for safety is the exact same model later served to customers.
- Security teams watching for tampered streams: Because the proof binds the prompt and output tokens to the committed weights, Anthropic notes it makes it harder for attackers on compromised servers to hijack a chat or modify the token stream in transit—a concern adjacent to application-level threats like prompt injection.
- Regulators and provenance checks: Anthropic also points to hardware “pacing” (verifying compute is used for inference rather than unauthorized training), text provenance (proving a specific model wrote or reviewed a document), and enforcing model approval rules.
What about Anthropic’s own Claude traffic? In the November 2, 2026 post, Anthropic noted that its Frontier Safety Roadmap included a goal to develop a prototype of provable inference (which Anthropic calls “inference verification” following an October 19, 2026 update) by September 30, 2026. Anthropic says it met that September deadline through a separate, related project that cryptographically signs its inference traffic and recomputes inference on a trusted server. FlashProve pursues the same verification goal via zero-knowledge cryptography rather than trusted recomputation.
What I’d do today if I buy model access through a third party
Because no commercial API or router attaches FlashProve proofs to live traffic as of November 4, 2026, your only reliable defense against model substitution today is buying directly from first-party providers or vetted partners you trust contractually.
If you are a developer or engineering lead weighing a discount proxy or third-party router right now, here is how I would handle it:
- Treat the
modelstring in a third-party response as an unverified claim. Do not assume a reseller is serving the frontier model just because the JSON payload says so. - Do not rely on prompt spot-checks to catch a swap. Take Anthropic’s warning seriously: output quality checks alone cannot reliably distinguish a frontier model from a cheaper substitute across everyday prompts.
- Keep mission-critical workloads on first-party APIs or major cloud hosts. If your product’s accuracy, safety, or compliance depends on a specific frontier model, pay the official list price or use an official cloud partner with binding service-level agreements.
- Know how to verify if proofs roll out later. If your inference provider eventually adopts FlashProve or a similar zkSNARK scheme, never use the commitment file bundled with the provider’s response. Fetch the commitment ID directly from the model creator, compile the verifier yourself, check which tokens are covered, and require exact-match acceptance unless you can evaluate the numerical tolerance limits yourself.
Frequently Asked Questions
Can FlashProve verify Claude API responses today?
No. As of November 4, 2026, FlashProve is an open-source research prototype demonstrated on Meta’s open-weight Llama 4 Maverick model. Neither the Claude API, OpenAI, nor commercial API routers attach FlashProve proofs to responses today. Anthropic separately noted that it met its internal September 30, 2026 roadmap goal for inference verification through a different project that signs traffic and recomputes inference on a trusted server.
Does FlashProve reveal the model’s secret weights?
No. FlashProve uses a zero-knowledge proof (zkSNARK), which guarantees that the verifier learns nothing about the model’s secret weights, intermediate layer values, or which specific experts were activated during inference. The model’s general architecture is not hidden, and timing side channels are out of scope, but proprietary weights remain completely private while still allowing anyone to verify the computation on a CPU.
Can I run the FlashProve verifier myself?
Yes. Anthropic published the code under an Apache 2.0 license on GitHub (anthropics/FlashProve). You can build the fast C++ verifier (cp_verify) on Linux and check proofs on an ordinary CPU without needing a GPU or the model weights. The repository includes a stored example using a small synthetic model so developers can test the Commit → Prove → Verify workflow locally.
Is provable inference the same as a digital signature?
No. A standard digital signature only proves who sent a message, requiring you to trust that the sender ran the right model honestly. Provable inference with FlashProve proves which committed weights computed the output tokens. Even then, you must obtain the commitment ID from a trusted party, because a dishonest server could otherwise commit to a cheap model and generate valid proofs for it.
Details last checked November 4, 2026. Next review: December 4, 2026.
Sources
- Anthropic Research: Progress on provable inference for large language models (Nov 2, 2026)
- Anthropic announcement on X (Nov 3, 2026)
- GitHub: anthropics/FlashProve repository (v0.16.0)
- FlashProve Guide: Known limits
- FlashProve Guide: What is proved
- Anthropic FlashProve Technical Report (PDF)
- lotook: AI API pricing comparison (official list prices)
