Anthropic published the FlashProve research prototype on 2 November 2026. It generates a cryptographic proof of model execution, allowing a provider to show that a checked token came from weights tied to a previously published commitment without revealing those weights. The company’s research page lists the publication under its Frontier Red Team work.
As of 3 November 2026, this does not justify switching providers or paying a premium. FlashProve is not an available verification service for Claude or another commercial hosted model. Contracts, logging and vendor due diligence remain the practical controls for model identity today.
What assurance does FlashProve provide?
FlashProve shows that the specified token was produced from the supplied prompt by the model whose weights were tied to an earlier commitment.
The provider first publishes a short commitment bound to a particular set of weights. After running the model, it generates a proof. A user holding the commitment, prompt and response can check the claim without receiving the weights or rerunning the model.
Anthropic says the zkSNARK-based proof hides the weights and intermediate computation. It does not hide the model architecture. The company also describes its hash-based construction as offering post-quantum security.
This assurance is most relevant when a third-party router sits between the buyer and model provider, or when an auditor needs evidence of which model processed a request. Output quality alone cannot reliably establish model identity.
Can it verify Claude or another commercial model today?
The current FlashProve release cannot verify Claude or another hosted commercial model.
The experiment used publicly available 4-bit weights for Llama 4 Maverick. This is a 400-billion-parameter Mixture-of-Experts model that activates about 17 billion parameters per token. FlashProve uses that structure for efficiency, so the results do not transfer automatically to another architecture.
The proof covers an integer version of the model under greedy decoding. Floating-point execution or sampled decoding may diverge at a token and cease to match the proved computation. Context is limited to 1,024 tokens, and each proof checks one token within that request window. Proof generation happens after inference in batches, so it does not automatically attest every token in a long response.
Anthropic describes a separate project that signs its inference traffic and recomputes it on a trusted server. That is not a commercial deployment of FlashProve. The company now uses the broader term “inference verification” for this objective.
What do the reported performance figures show?
Anthropic’s measurements show that a proof can be checked on a CPU in seconds. Under the reported test conditions, generating it required about 72–94 times the GPU time of running the model without proofs.
| Metric | Reported value | Test condition |
|---|---|---|
| Proving throughput | 110 tokens/second | Batch of 24 requests, one H100 and 24 CPU cores |
| Proof size | 18.78 MB | One proof per request |
| Verification time | 17 seconds | 24 CPU threads, no GPU |
| Verification time | 21 seconds | One CPU thread, no GPU |
| GPU-time requirement | About 72 times | Compared per GPU with vLLM on the same 24-request batch |
| GPU-time requirement | About 94 times | At the highest vLLM load tested |
These are vendor-reported measurements. The vLLM comparison used the FP8 model release on eight H100s, while proving used the 4-bit version on one H100. Results were compared on a per-GPU basis. The ratios apply to this test and should not be transferred directly to Claude, dense models or different hardware.
One 80 GB GPU with about 290 GB of host memory suffices for the prover. Creating the model commitment took about 39 minutes. A commitment is good for about 16 million requests before it must be renewed. The release provides no commercial price, SLA or service terms, so these figures cannot support a full deployment cost estimate.
If you need to design model selection, routing and logging as one system, the enterprise AI solutions overview helps define the requirements. Enterprise AI solutions
What should you ask a model provider or router today?
Ask the provider to document which model served each request, when fallback can occur and what evidence supports the model identifier in its logs.
- Ask how the requested and actually served model identifiers are logged.
- Establish when the router may switch model, provider or region.
- Require notice before changes to model versions, routing rules or fallback behaviour.
- Define how long the model identifier, timestamp and routing event are retained.
- Confirm whether audit logs can be exported and reconciled with your application logs.
- Ask whether the log is a contractual representation or a technically verifiable attestation.
Logs show what a system recorded. They do not provide the same cryptographic assurance as a proof bound to committed model weights. For the wider purchasing decision, use the enterprise proprietary model comparison. If you buy through a cloud marketplace, the guide to procuring OpenAI models through Google Cloud Marketplace provides further questions about data terms, regions and support ownership.
Which buyers need to address model identity now?
Organisations using third-party routers or operating audit-heavy workflows should include model identity in procurement now.
Finance, health, legal, public-sector and internal-security workflows may need a record of which model processed particular data. The issue also matters when a router can switch between models based on price, capacity or availability.
Teams buying directly from one provider can wait if output quality is their primary concern and they do not need cryptographic proof of the exact weight set. Workflows that process long documents or rely on sampled decoding should also wait because the current context and decoding limits do not fit them.
| Situation | Decision today | Reason |
|---|---|---|
| Third-party router in an audited workflow | Add model identity to procurement requirements | The router may send the request to another model |
| Direct provider with low verification needs | Keep the technology on a watch list | No commercial FlashProve service is available |
| Evaluating verification for an open-weight MoE model | Review the release | Code, Lean proofs and documentation use Apache 2.0 |
| Long documents or output produced with sampled decoding | Wait for broader technical support | The 1,024-token context and greedy-decoding condition do not fit the workload |
When should you reconsider the procurement decision?
Reconsider the decision when a provider offers verifiable proofs for the model you actually use, with documented pricing and operating terms.
Before buying, confirm support for your decoding method, required context length and the portion of the token stream that is proved. Request proof-generation time, file size, verification cost and a defined process for failed checks. Examine how the fast verifier relates to the formally verified specification. Anthropic gives no formal guarantee for FlashProve’s fast C++ verifier, although it matched the Lean verifier in the company’s tests.
Start by mapping the current path of each request. Record which provider, router and model identifier every application uses. Reconcile application logs with provider logs and document fallback behaviour. This exposes where model selection cannot already be checked after the event.
The open question is whether, and when, hosted providers will offer this type of proof for real commercial inference traffic.
Open full-size chartChart data as a table
| GPU time required to generate proofs | × |
|---|---|
| 24-request comparison | 72 |
| Highest tested vLLM load | 94 |