Anthropic makes a modest move, is the sky about to fall for the AI transit station industry?
Is the AI you paid to call really the exact model the service provider promised?
For instance, a third-party platform claims to have integrated a flagship model, but secretly replaces it with a cheaper smaller or older model on the backend. It is extremely difficult for us to tell the difference only from the tone and quality of the responses; or for the same question, the official website can output the correct answer, but the transit proxy gets stuck when processing the request.
Figure | Some AI API transit proxy recommendation and evaluation projects on GitHub all mention the adulteration rate
For many domestic users who call models through third-party APIs, aggregation platforms or transit proxy services, this is a problem they often have to face.
A seemingly simple model request needs to go through multiple links of "user - transit proxy - upstream service provider - model" in the background. As long as any link lacks transparency, it is hard for us to confirm whether the model we bought matches the one corresponding to the marked price.
Figure | Research link: https://www.anthropic.com/research/provable-inference
Anthropic recently released a research that attempts to turn this problem, which can only be debated based on word-of-mouth, screenshots and personal experience, into a problem that can be mathematically verified.
This open-source research prototype called FlashProve can generate cryptographic proofs for model inference. It tries to enable service providers to provide cryptographic proofs for the model's calculation results. Users do not need to obtain the model weights or re-run the large model by themselves to complete the verification.
Prove "You Are You" Without Disclosing The Model
We can only confirm the model we are using when we use the official application of the model manufacturer or call the API for dialogue from the official website. In most API calls, we submit the question, the server returns the response, and the model actually runs on a remote machine. We have no way of knowing exactly what calculations are performed in the background.
The Stanford University research project "Model Equality Testing" once tested 31 commercial API endpoints of four Llama models released in 2024, and found that the output distribution of 11 of these endpoints had statistical differences from the reference distribution of the weights released by Meta.
The same model name sometimes does not correspond to the same performance. Even if Opus 5.5 is marked on the service page, there is no way to guarantee that users can get the exact same model.
Sometimes we think we can identify the model with a few questions, just like the recent internal test of Opus 5.5. Some netizens said that if you ask where Karpathy went in May 2026, if the model cannot answer that he went to Anthropic, it means the model has not been fully tested.
However, identifying the model through these questions will also encounter the problem of routing set by the model manufacturer itself, and it is often difficult to directly locate the cause. Accidental wrong answers, different parameters, incomplete transmission of context, and model replacement in the background may all eventually lead to the feeling of "the model seems to get dumber" and "this is not the model I want".
The core of FlashProve is a zero-knowledge succinct proof technology called zkSNARK.
First, the model service provider generates a "commitment" for the weights, which is similar to a set of cryptographic fingerprints that can uniquely lock specific weights without disclosing the weights themselves.
Subsequently, the service provider generates a proof for the given input and the output to be checked, to verify whether these outputs conform to the pre-agreed model calculation. After users get the model commitment, prompt, response and proof file, they can check on their own computer: Whether the locked weights will indeed produce these outputs when processing this input.
If the transit proxy secretly replaces the model with another one, or someone modifies the output, the proof will not match the original model commitment.
The zero-knowledge proof used here is also very important. Its purpose is to ensure that the verifier will not obtain the model weights, intermediate calculation values, and which experts are called by each layer of the MoE model while confirming the calculation results.
This also explains why it is more reliable than "letting the AI introduce itself". The model name written in the response no longer serves as identity proof, and what is checked is the calculation relationship between the output and the specified weights.
Verification Can Be Completed On A Laptop
In the past, the biggest obstacle to generating zero-knowledge proofs for large models was the cost. The proof generation process could be several orders of magnitude slower than ordinary inference, and the proof file could also be extremely large.
Anthropic conducted experiments using the publicly available Llama 4 Maverick with 4-bit weights. This is a mixture-of-experts model with 400 billion parameters, and about 17 billion parameters are actually activated for each token. According to the data released by Anthropic:
- The throughput of proof generation on a single H100 is about 110 tokens/sec;
- The proof for each 1,024-token request is about 19 MB;
- Verification does not require a GPU, it takes about 17 seconds on a 24-thread CPU, and about 21 seconds on a single thread;
- The initial commitment of model weights only needs to be generated once, which takes about 39 minutes.
However, the 110 tokens/sec here refers to the proof generation speed, not the model output speed when users chat. Proof generation is still expensive. Under the comparison conditions set by Anthropic, its GPU time is about 70 to 95 times that of ordinary vLLM inference.
Even if it is not free, this solution has pushed a previously almost unaffordable verification method to a stage where it begins to have practical application prospects.
But It Cannot Explain The "Model Performance Degradation"
For transit proxy users, the most direct appeal of this technology is of course to identify model replacement. But there is a key premise here: we must know in advance what the genuine model's commitment is.
If the transit proxy provides a valid proof, but it can only prove that the response comes from model B it chooses, and the user cannot confirm whether model B is the same as model A they purchased, this proof still cannot solve the model identity problem.
The truly effective usage should be that model manufacturers, trusted institutions or an open and transparent registration system publish the model commitment, and users check this expected fingerprint fixedly during verification. Under this premise, FlashProve can be upgraded from "this calculation did happen" to "the calculation we paid for did happen".
On social media, most comments from netizens on this technology are that "it would be great if this can finally put an end to those posts discussing whether they are secretly weakening the model".
After all, the result we most want is definitely "stop arguing, just show the proof".
But even if the weight identity is confirmed, there are other possible reasons for "model performance degradation".
Unchanged model weights do not mean the service has not changed at all. System prompts, security policies, context truncation, retrieved content, quantization methods and decoding parameters may all affect the final experience. To troubleshoot these problems, we need to confirm whether each condition is also covered by verification. A proof bound to the weights cannot automatically answer all product-level questions.
When the Kimi team introduced the Kimi Vendor Verifier, they mentioned that after the release of K2 Thinking, they received feedback from the community about abnormal benchmark scores. After investigation, it was confirmed that a considerable part of the cases came from misuse of decoding parameters. The team then constrained relevant parameters in the Thinking mode, and checked whether the thinking content was transmitted back correctly.
To Get The Proof From Service Providers, Someone Has To Be Willing To Generate It First
Although there is still a long way to go before consumer-level popularization, the direction demonstrated by this technology is important enough.
Anthropic has publicly released the code, technical report and Lean formal proof at the same time. According to the introduction on the technical blog, Claude participated in the system construction and optimization, and the protocol documents and part of the code were also generated by AI.
For transit proxy services, actual integration requires the participation of upstream parties. Model manufacturers or operators holding the weights need to establish trusted model commitments and generate proofs, and then the transit platform will hand over the relevant content to users.
But if service providers can continue to provide such proofs in the future, when we complain "did you replace the model", we will get a response that we can check by ourselves.
For model manufacturers, this technology can also help detect compromised inference servers and confirm whether the weights actually running are authorized.
For evaluation institutions and regulators, it can be used to confirm whether the model under test is consistent with the model officially provided for service, or to check whether service providers use unapproved models.
Of course, all these applications still require lower proof generation costs, longer context support, coverage of real inference configurations, and a trusted model commitment release mechanism.
FlashProve will not immediately put an end to those posts online discussing "whether they are secretly weakening the model". Even if weights can be verified in the future, people can still continue to argue about whether system prompts, decoding strategies and product designs have changed.
But at least for the issue of whether the model has been replaced, we have the opportunity to change from guessing with a few questions and arguing based on feelings in the past, to taking out a