The model you paid for may be a "second-hand model."

Image source: Internet (please contact us for removal if infringing). Partially AI-generated.

A friend of mine founded an Agent startup, and last week he ran into something that really got under his skin.

With the same set of prompts and the same document, the structured results last week still boasted an accuracy rate above 90%. This week, the model suddenly started "getting muddled" left and right: key fields left blank, reasoning steps truncated, and the occasional mix-up of two entities.

He combed through the call logs. The model field clearly showed the flagship model, and the billed unit price hadn't dropped by a single cent.

He suspected the backend model had been swapped, but he couldn't produce any evidence. When he confronted the relay platform, they shot back with "the model vendor updated the version—this is normal fluctuation," and he was left speechless.

He's not alone in this predicament. Over the past year or so, "bait-and-switch" in large model APIs has gone from scattered rumors to a semi-open secret in the supply chain.

You pay for a flagship model, but what's actually doing the work in the backend may be a watered-down version that's several times—or even dozens of times—cheaper. You think you're connected directly to the official service, but there may actually be two layers of routing, a round of quantization compression, or even a round of prompt rewriting in between.

The crux of the problem isn't "whether anyone does this"—after all, the answer is yes. The key issue is that the victim has no hard evidence in hand to take to a confrontation.

Your flagship model may have already been "downgraded."

The large model API business appears to sell tokens, but in reality it sells trust.

You can't open up the API like inspecting a graphics card to see what weights are running inside, nor can you track which nodes a request passed through like checking courier logistics.

The only things you can see are the returned text and the model name on the bill. And both of these are exactly the things the backend can generate.

A research team at Stanford University once conducted a systematic audit, testing 31 commercial API endpoints of four Llama models in 2024, and found that the output distributions of 11 of them had statistically significant differences from the reference distribution of Meta's officially released weights.

In other words, for more than one-third of the tested endpoints, the "same model" you get is not statistically the same thing as what the official weights produce.

In a laboratory, this ratio is paper data; in the commercial world, it's a subtext: bait-and-switch in the API supply chain is not an occasional accident, but a structural risk.

What's more troublesome is that ordinary developers have almost no low-cost countermeasures.

If you ask the model "who are you," of course it will answer according to the self-cognition in its training data; if you throw a few math problems at it to probe, the fact that it happens to answer correctly proves nothing.

The sentence in which the model identifies itself is itself generated by the backend. Using it as identity proof is like letting the suspect write their own confession.

So the whole industry falls into a strange tacit understanding: everyone knows bait-and-switch may exist, everyone assumes they may be switched, but no one can produce evidence.

Platforms explain every anomaly with "version update," "normal fluctuation," and "load balancing," while customers comfort themselves with "maybe my prompt wasn't written well."

This is the trust deficit of the API supply chain: the cost of verification and the burden of proof are systematically misallocated.

Those who suspect cannot get evidence, and those who can provide evidence have no incentive to provide it.

Putting a "fingerprint" on model weights

What really loosened this situation was an event in early November 2026. Anthropic's frontier red team open-sourced a research prototype called FlashProve, attempting to use zero-knowledge proofs to turn "whether this answer was really generated by the model you bought" from a question that can only be argued through gut feeling and reputation into a mathematical judgment that can produce a result in 17 seconds on an ordinary laptop.

Its process design is clever, but the logic is not complicated.

Before a model goes online, the service provider uses an H100 for about 39 minutes to generate a unique cryptographic "commitment" for the model weights. You can actually understand it as a digital DNA fingerprint of the weights.

This fingerprint is public, but no one can reverse-derive the weights themselves from the fingerprint, so the vendor's intellectual property is not affected.

After that, each time a request is processed, the GPU conveniently generates a proof file of about 19MB and attaches it next to the output.

The user or auditor obtains the output and proof, runs a verification program on an ordinary CPU, and within 17 seconds can determine whether this output was computed from the "fingerprinted" weights.

The keyword here is zero-knowledge. The service provider proves one thing: "this output indeed comes from the committed weights," yet does not need to hand over the weights, intermediate activations, or even expose which experts the MoE model invoked.

The verifier does not need to trust the service provider, nor Anthropic; they only need to trust mathematics.

What supports this mechanism is zkSNARK, with security based on the BLAKE2 hash function, not relying on elliptic curves, and in theory resistant to future quantum attacks.

If you look only at this layer, the story is beautiful: mathematical verifiability has been inserted into the large model API supply chain for the first time, and "trusting the service provider" has begun to have a technical path to be replaced by "verifying the proof."

In the future, when customers again raise the question "why has it gotten dumber this week," platforms can no longer fob them off with "normal fluctuation"; they will have to produce the proof.

But in the FlashProve paper, there is a data point that instantly drops this story from idealism back to realism.

Math is cheap, compute is expensive

The GPU time required to generate proofs is about 70 to 95 times that of ordinary inference.

The proof generation throughput of a single H100 is about 110 tokens/second, and the current context limit is only 1024 tokens.

Moreover, Anthropic itself explicitly labels this as a research prototype, with no deployment plan, and the repository is not maintained.

What does 70 to 95 times mean? If you are a service provider, the request volume a single H100 can normally process per hour for inference will collapse to one-seventieth to one-ninety-fifth of the original once proof generation is enabled.

The extra compute cost will not automatically disappear just because "the math is elegant." Someone has to pay for it.

This is the most intriguing part of the whole matter.

The party that needs verification is the customer, but the party that must pay to generate proofs is the service provider.

The customer's pain of being switched is real, but this pain is dispersed, individual, and perceptible only after the fact; the cost of deploying proofs for the service provider is concentrated, upfront, and burning with every request.

A relay station that makes money through bait-and-switch has no reason to proactively install this "anti-counterfeiting system" on itself—after all, it's equivalent to putting on electronic shackles that bill every second.

Even a compliant service provider, under competitive pressure, will do the math: if the 70x GPU overhead is spread into the API unit price, customers will immediately vote with their feet and flow to cheaper unproven endpoints; if it's not spread in, their gross margin is directly eaten away.

Honesty has become a luxury that requires extra payment, and the market is not yet ready to price it.

More subtly, FlashProve currently covers only integer models plus greedy decoding, with context stuck at 1024 tokens, while real production calls often involve contexts of tens of thousands of tokens, complex sampling strategies, and multi-turn tool calls.

Even if the technology continues to iterate and the cost curve declines, the incentive structure will not automatically repair itself.

Service providers can choose to enable proofs only for "high-value customers," can selectively generate proofs for audit scenarios while silently skipping daily calls, and can also play with the granularity of proofs. Proving "this output comes from this model" and proving "this request was not tampered with by a man-in-the-middle and was not routed to a quantized version" are not the same thing in engineering.

Technology has solved "whether it can be proven," but the question "who has the incentive to prove it" is beyond technology's reach.

Verification is a public good, cost is a private good

If you break down FlashProve's dilemma, you'll find that it has run into a classic economic problem: the public goods dilemma.

A relay station customer will not be willing to pay double just because "this call of mine came with a 19MB zero-knowledge proof," because what they want is not a proof, but the certainty that nothing goes wrong.

But certainty is a public good: once someone provides a proof, all customers using the same endpoint benefit, while the cost is borne by the service provider alone.

This leads to an awkward situation: the more incentive a service provider has to engage in bait-and-switch, the less likely it is to proactively adopt proofs; the more capable a compliant service provider is of adopting proofs, the more it must bear the price disadvantage brought by cost pass-through.

The old script of bad money driving out good money is being staged again in the AI supply chain under a new technical shell.

Some will say, then let customers mandate in contracts that service providers provide proofs. Logically correct, but in reality most small and medium-sized customers have no bargaining power at all.

If you, a developer spending a few hundred dollars a month, go to a platform and say, "Please generate zero-knowledge proofs for each of my calls," the other party will only think you're joking.

Only enterprise customers with sufficiently large procurement volume and sufficiently hard compliance requirements can possibly write "verifiable inference" into contract terms.

So the true significance of FlashProve is not whether it can be used now, but that it puts a multiple-choice question on the table.

In the past, the industry's default answer was "trust the brand, trust the contract, trust the reputation." Now mathematics offers another option, but this option is marked with a price that most service providers are unwilling to proactively pay.

Technology has proven that "verification is possible," but economics has not yet solved "who has the incentive to verify."

If you pull your view back a little, you'll find that a security research release from OpenAI at almost the same time happened to illuminate the same problem from another direction.

They used an unreleased cybersecurity model to build an automated pipeline, marking 2.8 million lines of high-value targets within more than 40 million lines of Linux kernel code, running for 12 hours to deliver 2,308 suspected vulnerabilities, reproducing 1,724 within 30 hours, and ultimately generating 948 usable privilege-escalation exploit programs.

The API cost of the entire process was $1.21 million, with an average development cost of $1,279 per exploit program.

The reason this figure is worth looking at together with FlashProve is that it demonstrates another incentive structure.

In the vulnerability discovery scenario, who benefits, who pays, and who verifies are the same party: OpenAI bears the API cost itself, verifies the exploitability of the vulnerabilities itself, and submits the resulting patches to the kernel community. The ownership of security value is clear.

At $1,279 per exploit program, it doesn't sound cheap, but compared with the efficiency of top human security researchers, who can find only about 20 similar vulnerabilities a year, the cost-benefit ratio is overwhelming.

When the output of proofs can be precisely priced and directly priced by the market, the 70x compute overhead is just an engineering parameter that needs optimization, not an unsolvable political economy dilemma.

The trouble with API model verification is precisely that the "proof" it produces is itself hard to price.

It's hard to tell a customer: because I attached a proof for you, this call costs 70 times more.

The customer will ask: then how do I know your proof isn't fake? See, we're back in the loop.

Exploits are private goods: whoever uses them pays. Model verification is a public good: everyone benefits, and the service provider pays.

Two incentive structures determine completely different fates for the same type of cryptographic technology in two scenarios.

Anti-counterfeiting ID: who will it be sold to first?

In the short term, the scenarios most likely to implement this logic first are not the daily calls of consumer-grade chatbots, but those where verification costs can be passed on or verification benefits can be internalized.

The first category is regulated financial and healthcare procurement, where contracts can explicitly require service providers to furnish proof and pay a premium for it.

For these customers, compliance costs are already built into the budget. Adding an extra layer of cryptographic verification is far more cost-effective than being fined by regulators after the fact.

The second category is internal model auditing within enterprises. Security teams already have an independent budget line, and they need to prove to the board that "the models we use have not been swapped." Tools like FlashProve at least offer an actionable handle.

The third category is "mutual verification" among model vendors. When a lab claims that its benchmark scores come from a certain model, competitors have ample incentive to check whether that "fingerprint" matches.

In this scenario, the beneficiaries and the payers of verification are one and the same, and the incentives are self-consistent.

As for ordinary developers and small to medium-sized teams, expecting service providers to attach proof spontaneously, freely, and universally is, until the incentive structure is reshaped by external forces, most likely unrealistic.

A more realistic path may come from regulatory intervention. If "model source verifiability" becomes an admission requirement in certain regulated industries, service providers will have no choice.

Alternatively, it may come from collective bargaining on the buyer side. When enough enterprise customers make "verifiable inference" a mandatory item in procurement contracts, the cost of proof will shift from "an extra burden on service providers" to "a market entry ticket."

But both paths take time, and the trust deficit in the API supply chain is producing new victims every day.

FlashProve is a beautiful technical starting point, but it has pierced the most awkward layer of window paper in the AI supply chain:

When it comes to verification, those who most need evidence are farthest from it, and those most capable of providing evidence have the least incentive to do so.

Mathematics has solved the question of "whether proof is possible," but the question of "who pays for the proof" lies beyond the reach of mathematics.

The 70 to 95 times computational overhead will not disappear out of thin air. It will either become a cost for service providers, a price for customers, or some kind of public expenditure for third-party auditing.

None of these three outcomes will happen automatically.

Therefore, the next truly noteworthy milestone is not how many times FlashProve's performance has been optimized, nor how many tokens the context window has expanded from 1024 to, but rather:

when the first commercial contract that writes "cryptographic proof" into an SLA appears; when the first service provider is eliminated from the procurement process because it "cannot provide proof."

Until then, the anti-counterfeiting ID card remains merely a sample sitting in a display cabinet—nice to look at, but not yet wearable around the neck of any real model.