Anthropic announces FlashProve for checking model identity Anthropic announces FlashProve for checking model identity

A receipt for the computation

Anthropic reports 110 prefill tokens per second at 24 requests per batch on one H100, using a quantized Llama 4 Maverick model. Proofs cover completed requests after the fact, instead of accompanying live generation.

The trusted identifier comes first

The verification guide separates the server supplying a proof from the party identifying the intended model. Clients obtain the commitment identifier and configuration through a trusted channel before sending their prompt. They construct their own request and token files from what they actually sent and received. The verifier does not know the original conversation independently. Acceptance also depends on the reported token range, policy and reply ending. A shortened reply can pass as a shorter sequence, so an end-token check matters when the client needs the complete answer. Changing commitment identifiers introduces another boundary: the public proofs do not establish that two different identifiers represent identical weights. Repeating prompts under both identifiers compares those examples only.

Different routes into the artifact

The repository separates checking an existing example from proving a full model. Its stored demonstration uses synthetic weights and can be checked on a Linux CPU with less than two gigabytes of memory. A separate small-model route exercises eight synthetic layers on a GPU. The full Maverick route downloads a 232-gigabyte public four-bit conversion and lists 330 gigabytes of host memory and 245 gigabytes of disk. The supported prover configuration specifies an otherwise unused H100 with 80 gigabytes of memory and a particular CUDA compiler release. Those requirements describe the supplied research setup, not a lightweight feature that a browser can independently generate. Checking the stored synthetic example establishes that the verifier runs; it does not establish anything about a commercially served model.

What an accepted result establishes

The project distinguishes exact matching from a more permissive policy called clipped gap. Exact matching checks the integer model’s preferred tokens. The looser policy instead evaluates token costs against limits chosen beforehand; its successful result does not establish identical output. The documented mathematical guarantees concern the Lean verifier and protocol under stated assumptions. The commonly used C++ verifier and CUDA prover are tested implementations, not themselves formally verified. This separation matters because a correct mathematical statement and software that faithfully implements it are different things. The repository also reports that it has not undergone an independent security audit. Both acceptance policies return the same successful exit code, making the final result text part of the client’s decision.