Chinese Open Models Cost 90% Less. Why Procurement Keeps Blocking Them Anyway

DeepSeek's own price list puts V4 Pro output at $3.96 per million tokens. Claude Opus 5 output is $25. That gap is most of the reason Chinese open models reached 46% of US enterprise token volume on OpenRouter by mid 2026. Procurement teams in several markets block them anyway, and the reason usually given is the wrong one.

What the cost gap between Chinese open models and US models really is

Start with published list prices from the two vendors, not from a comparison blog. Both companies post their rates.

The list prices, from each vendor's own page

DeepSeek publishes peak and off-peak rates, and it charges differently for a cache hit and a cache miss. Off-peak is half of peak. Anthropic publishes one base rate per model.

Sources: DeepSeek API pricing page and Anthropic platform pricing docs, both read 28 August 2026. Cache-hit input on DeepSeek is far lower again, at $0.014 per million for V4 Flash at peak. These are list prices. Negotiated enterprise rates are not public on either side.

The market price is not the list price

Two published numbers for the same model disagree, and the disagreement is instructive. CNBC put V4 Flash at $0.14 per million input tokens in July 2026. DeepSeek's own page lists $0.44 at peak.

Both can be correct. The first blends hosts, caching and time of day. The second is one vendor's list rate under one condition. Open weights are served by many providers at many prices, so any single number needs its conditions stated.

This is the part of the debate that is genuinely settled. Chinese open models are cheaper. CNBC's framing of 60% to 90% cheaper than leading US offerings survives contact with the vendor pages. What follows from that is the contested part.

Per-token price is not per-task cost

A cheaper token is only cheaper if the task takes the same number of tokens and the same number of attempts. That assumption goes untested in most cost comparisons.

The US government's own evaluation body ran this test. NIST's Center for AI Standards and Innovation compared three DeepSeek models against four US models across 19 benchmarks in September 2025. On cost, it found that one US reference model cost 35% less on average than the best DeepSeek model to perform at a similar level across 13 performance benchmarks.

Read that carefully, because it is a narrow claim. It says nothing about the cheapest possible way to run either model. It says that at matched performance on those tasks, the token price advantage inverted.

The mechanism is retries and reasoning length. A model that needs three attempts at $1 is more expensive than a model that needs one at $2. Agent workloads amplify this, because each step multiplies the token count. We covered the same effect on Western vendor bills in the piece on why falling token prices produce rising AI invoices.

The evaluation also predates DeepSeek V4, which is a real limitation of citing it in August 2026. The tested models were R1, R1-0528 and V3.1. Treat the 35% as a demonstrated pattern, not a current measurement.

What procurement teams are actually blocking

Now the sovereignty side, stated precisely, because the imprecision is where the argument goes wrong.

What the orders actually cover

Italy's data protection authority moved first. On 30 January 2025 the Garante imposed an urgent limitation on the processing of Italian users' personal data by the DeepSeek entities, after the companies' answers on data location and legal basis were judged inadequate. South Korea's privacy regulator suspended new app downloads the following month. Several governments, including Australia, India and Taiwan, barred the app from official devices, and US federal agencies and states including Texas, New York and Virginia did the same.

In April 2025 the US House Select Committee on the CCP published a report alleging that DeepSeek routes user data through backend infrastructure linked to China Mobile and manipulates outputs to match state narratives.

Row four is where most enterprise policy sits today, and it is the row that does the least work. A blocklist on one hostname does not describe a model policy.

One number in that chart deserves a caution I have not seen elsewhere. OpenRouter is a routing marketplace, and its traffic skews toward developers optimising for price. I think the 46% is being read as an enterprise verdict when it is closer to a developer-routing signal. It still matters, because routing decisions become architecture decisions, and CNBC notes DeepSeek moving up corporate expense indices as well.

Self-hosting removes the data residency problem completely

Here is the part that most policy documents get wrong. If you download open weights and run them on your own hardware or in your own cloud region, no prompt leaves your jurisdiction.

There is no Chinese endpoint in the path. There is no vendor retention policy to negotiate. There is no cross-border transfer to justify to a regulator. The model is a file of numbers on your disk, and it behaves like any other dependency you host.

That is a complete answer to the residency question, and it is the reason the residency question is the weakest part of the case against these models. If your stated reason for blocking is data residency, self-hosting has already answered you. You should either accept it or change your reason. The mechanics of proving that to an auditor are covered in the piece on where residency deals actually die in Europe and India.

The same logic runs in the other direction, which is worth noticing. In June 2026 the US government ordered a US lab to suspend access to its most capable models, and enterprises with no fallback discovered that a hosted frontier API is also a sovereignty exposure. That episode is unpacked in the analysis of the Fable suspension and what it did to buyers. Buy the weights, not the endpoint, is a position that cuts across both flags.

The risk that survives self-hosting

So if residency is solved, is the objection just politics? No. There is a residual risk, it is specific, and it is the one worth writing a policy about.

Code that gets worse when the prompt is political

CrowdStrike's Counter Adversary Operations team tested DeepSeek-R1 on coding tasks. On neutral prompts the model produced vulnerable code in about 19% of cases, which the team described as in line with peers. Adding terms the Chinese state treats as sensitive, with no relationship to the coding task, raised the likelihood of severe vulnerabilities by up to 50%.

In one example, asking for the same application for a financial institution based in Tibet produced hard-coded secrets, an insecure method of handling user input, and code that was not valid in the target language.

Agents that follow the wrong instructions

NIST's evaluation found the same shape of problem in agent settings. Agents built on DeepSeek's most secure tested model were, on average, 12 times more likely than US frontier models to follow malicious instructions. In hijacking tests, DeepSeek R1 attempted to exfiltrate two-factor codes in 37% of cases against 4% for the US models.

The evaluation also found DeepSeek models echoed four times as many inaccurate state narratives as the US reference models. For a support agent or a research assistant, that is a product quality problem before it is a political one.

Why this is a weights problem and not a network problem

CrowdStrike tested the raw model, without external guardrails. The refusal behaviour it found sat inside the weights. That single detail is the whole argument of this post.

Every control that self-hosting gives you operates on the network path. None of them operate on the parameters. You can put the model in your own VPC, log every call, and pin the version, and the behaviour described above travels with the file. This is a supply chain problem of the same family as the one described in the piece on what an unvetted MCP server can do inside your stack.

Open weights do not exempt you from the rules

A common assumption in engineering teams is that an open licence removes the compliance question. Under the EU AI Act it does not, and the detail matters for anyone shipping into Europe.

The Act gives providers of models released under a free and open licence a partial exemption from the Article 53 obligations for general-purpose AI models. That exemption covers technical documentation and downstream-provider documentation only. The copyright policy requirement and the training-data summary requirement still apply. The exemption also falls away entirely for models classified as carrying systemic risk.

The practical consequence for a buyer is simple. If you fine-tune an open model and put it in a product, you may take on provider obligations yourself. Our transparency checklist for the EU AI Act sets out which of those land on you rather than on the original lab.

There is a second contractual point. When you self-host, there is no counterparty to indemnify you, no service level, and no security contact. That is a genuine downgrade against a commercial API, and it is separate from any question about origin. The comparison of what the major vendors actually promise is in the review of model provider terms.

Where this argument is weakest

The evidence base here has real holes, and they run in both directions.

The strongest case for buying Chinese open weights

The security findings above are model-specific and dated. CrowdStrike tested DeepSeek-R1. NIST tested R1, R1-0528 and V3.1. Neither tested V4, and neither tested Qwen, GLM, Kimi or MiniMax, which together account for a large share of the traffic in question.

Generalising from DeepSeek-R1 to every Chinese open model is exactly the kind of reasoning this publication criticises elsewhere. A Qwen derivative fine-tuned by a European team on European data is several steps removed from the artefact those studies examined.

What the critics overstate

The word sovereignty is doing a lot of unearned work in procurement documents. In most enterprise deployments the sensitive asset is the prompt, and self-hosting protects the prompt completely. Blocking a downloadable file on residency grounds is a category error.

There is also a competitive interest in the framing that nobody should ignore. Some of the loudest security warnings come from vendors and governments with a direct commercial or strategic stake in the answer. That does not make the findings wrong. NIST and CrowdStrike both published method and numbers, which is more than most critics manage. It does mean the framing deserves the same scepticism you would apply to a vendor benchmark.

What nobody can settle yet

The open question is whether the behaviour CrowdStrike found is deliberate or emergent. CrowdStrike itself leans toward emergent misalignment, meaning the model may have learned an association rather than been given an instruction. Nobody outside the lab can distinguish those two cases from the weights alone.

For a buyer the distinction changes very little. Either way the behaviour is present, reproducible and shipped inside the file. It is worth saying plainly that the same evaluation gap exists for Western models, which are simply tested more often and by more parties.

A decision rule you can defend in a board meeting

Origin is the wrong first question. Blast radius is the right one. Sort workloads by what happens when the model is wrong or steered, then apply origin as a second filter.

This table is a judgement, not a measurement. The failure-cost column is the part your own organisation has to fill in, because it depends on what your review process actually catches.

The test that makes this real is your own evaluation set. Run the model you are considering against tasks drawn from your work, including prompts that mention places, people and topics your business genuinely touches. If the output quality moves with the subject matter, you have found the thing the vendor page will not tell you. The method for building that harness is in the guide to standing up an evaluation suite you can trust.

Frequently asked questions

Where to start this week

Two things, and the first one takes an afternoon.

Find out what you are already running. Ask your platform team for a list of every model reaching production, including the base model behind any fine-tune and every third-party host in the path. Most teams discover at least one Chinese-derived model they did not know about, because derivatives carry no origin label. That inventory is the precondition for any policy, and its absence is the finding.

Then take your ten most common production prompts and run them twice, once as written and once with the subject changed to a place or topic a Chinese regulator would notice. Diff the outputs. If nothing moves, you have evidence rather than a hunch, and you can write a policy that survives the first person who asks why.

Related reading