Running Chinese open models mostly safely: EU hosting changes the picture

Last week I let an open model implement a real feature in my app. Kimi, from the Chinese company Moonshot, wrote most of the production code, and a DeepSeek model reviewed it. When I tell people this, the first question is always the same: “So your source code went to China?”

It didn’t. And that was news to me too, a few weeks ago.

Honestly, I had never looked. Like most people, I take the path of least resistance and least risk. As long as my Claude Max subscription carried me through a full month, I saw no reason to explore open models. I rarely even switch between frontier models for my daily work. Why change a running system I’ve learned to trust? And I was sceptical that anything open could write code of comparable quality.

Sometimes it takes a painful experience to leave your comfort zone. Mine was my usage limit suddenly running out after an hour. When your main tool stops working in the middle of the week, you start looking at alternatives.

This is the first of a few posts about working with open models next to Claude. Before I write about cost and quality, I want to get the question out of the way that stops most people from trying them at all.

Open weights don’t mean “run it yourself”

My mental model was: open-weight model means download the weights and run them on your own machine. So my first plan was to run Qwen locally. On my ThinkPad with an integrated Radeon GPU, a repo investigation of 20 agent turns would have taken an estimated 20 to 40 minutes. Local runtimes do cache the prompt, but every file the agent reads and every test output still has to be processed on a laptop GPU, and one cache in your RAM is easily lost when something else runs in between. Local inference makes sense for small jobs where privacy matters more than speed. For agentic coding it doesn’t.

What I hadn’t realized: because the weights are open, anyone can host them. Next to the vendors’ own APIs, there are inference providers in the US and in Europe that serve the same models behind an ordinary OpenAI-compatible API. You pay per token, like with any other model. And yes, contrary to popular belief, there are datacenters in Europe with serious GPUs in them. Not everything worth having gets invented in California and runs in Virginia. I say that partly at my own expense. The public debate keeps telling us how far behind Europe is in AI, and after hearing it often enough, we Europeans start to believe we have no choice but to rely on the US or China. I believed it too, and never checked.

The host decides where your data goes

The model is a file that does math. Where your prompts go, who logs them and whose law applies is decided by whoever runs that file. For the models I use, that looks like this (as of September 2026, from the providers’ own pages):

Two things stand out. First, “Chinese model” doesn’t even mean “Chinese servers” when you use the vendor directly: several run their international APIs from Singapore. Second, the terms differ a lot between hosts, and even between hosts in the same country. You have to read them for the one you pick. And keep in mind that the right column is what each provider promises on its website. How much such a promise is worth depends on the law behind it, more on that below.

I use TensorX. The provider is European, the models are not: everything in my setup is Chinese-origin (DeepSeek, Kimi, Qwen, GLM, MiniMax). Non-Chinese open models exist too, for example OpenAI’s gpt-oss or Mistral’s own models. I haven’t tested them for coding yet.

If you want many hosts behind one API, OpenRouter lets you pin providers and require zero data retention per request:

"provider": {
  "only": ["<provider>"],
  "zdr": true,
  "data_collection": "deny",
  "allow_fallbacks": false
}

Without allow_fallbacks: false, a request can quietly land on a different upstream than the one you picked.

One catch with any gateway like this: to the upstream provider, all OpenRouter traffic looks like one customer. A 2026 paper showed that this can switch off the providers’ per-customer cache isolation, so one OpenRouter user could detect prompts another one had sent (more on why that matters below). Bringing your own provider key (OpenRouter’s BYOK mode) restored the isolation in those tests.

The cheapest option is the vendor, and that’s the trade

Here is the uncomfortable part. Take the token mix of my test run and price it for DeepSeek’s strongest model. On DeepSeek’s own API during its off-peak hours it would have cost about $2.40. The same model on my EU host: about $37. That’s a factor of 15, and it is almost entirely the price of the data path. The cheap option stores your code in the PRC under a policy that allows training.

For hobby code that might be fine. For client code, or anything with personal data in it, it isn’t. The app I work on handles health-related user data, so for me the answer was clear.

What EU hosting secures

• The vendor never sees a request. Moonshot, DeepSeek or Z.ai aren’t in the loop at all. They published weights, someone else runs them.
• Promises you can enforce. Under GDPR, an EU host processing your data is a processor bound by a data processing agreement, and a data protection authority can fine it if it breaks that agreement. “Zero data retention” stops being a line on a website and becomes an obligation. GDPR covers personal data, which is exactly the part that matters most for me: the app handles health-related user data. US hosts can be held to their promises too, but the US has no comparable general data protection law, and under the CLOUD Act US authorities can demand data from US companies even when it’s stored abroad.
• Zero retention. No logging of prompts, no training on them. TensorX keeps its prompt cache in GPU memory only, never on disk.
• No phoning home. The weights have no network access of their own. They can’t send anything anywhere.

That covers the risk most people actually mean when they say “Chinese model”. It’s also the risk I’d worry about most, because it’s the one that would leak everything, all the time, silently.

Zero retention: easier with open models than with frontier models

If you really need zero data retention, open models on an EU host are currently the easy way to get it. With the frontier providers it’s the exception, not the default.

Anthropic offers it only to qualified enterprise accounts after review. When I tried to request it, the form rejected the Gmail address my account runs on, so as a solo developer I didn’t even get to the review. And its most capable models, Fable 5 and 5.1, keep prompts for 30 days even then.

OpenAI keeps API data for up to 30 days unless you’re approved for zero retention. On Google’s Gemini API you have to configure it per feature, and some features can’t be made zero-retention at all. For guaranteed zero retention Google points you to its enterprise platform, Vertex AI.

At TensorX it’s simply the default for every request. No form, no review, no enterprise contract.

What EU hosting can’t fix: the model itself

Some risks travel with the weights to any host, European or not. This could be its own article, but in short:

• Sleeper behaviour. A model can be trained to behave normally and switch behaviour on a trigger: a phrase, a date, a code pattern. Anthropic’s Sleeper Agents paper showed that such behaviour can be trained in and survives later safety training. With open weights, nobody outside the vendor can audit how the model was trained.
• Subtly insecure code. Not dramatic sabotage, but a weak default, a skipped check, a permissive config. Exactly the kind of thing that looks like an ordinary model mistake.
• Trained-in bias. Chinese models are known to follow PRC content rules on political topics. For coding that rarely matters. It does if the model writes or judges text your users see.
• Prompt injection. Instructions hidden in repo files, web pages or tool output. That applies to every model, open or frontier.

And the most important one: the attack surface is the agent, not the model. The weights can’t phone home, but a coding agent with a shell can run curl. The harness I use, pi, deliberately has no permission prompts. It hands the model a normal shell, so network and write access are whatever your machine allows.

Why “mostly” safe, then, and not “unsafe”? Because with a hosted frontier model you trust the company behind it completely too: its training, its filters, its logging. I can’t audit Anthropic’s training any more than Moonshot’s. The difference is where the trust sits, not whether you need it.

Controls for what remains

These come from building my own multi-model harness, and most of them I learned the hard way:

• An agent with bash can write, whatever its prompt says. I had an agent whose instructions said it was read-only. To check its own access, it created a file called test write. Read-only by prompt is a wish.
• Worktrees limit accidents, not intent. A separate git worktree keeps a confused agent out of your main checkout. An agent that wants out just runs cd.
• A git tripwire. Run git status --porcelain before and after each agent call that should not change anything. Any difference is a breach. Use --porcelain, because git diff --quiet misses newly created files.
• Review every change, with a different vendor. Reviewers get a prepared diff, and ideally the reviewer comes from a different model family than the author. A backdoor trained into one family is unlikely to be waved through by another. More on that in a later post.
• No secrets in the working tree. Before I used pi, my first experiment was a small MCP server that let Claude Code hand tasks to open models. The open model worked inside a sandbox that refused to read .env files and blocked git push, rm -rf and curl. It passed all 19 escape tests I threw at it. There is no such sandbox in pi, so a container or a user without network access is the equivalent there.
• If you paste a key into a chat, rotate it. It ends up in the session transcript and in the tool’s prompt history, where any agent that later reads those files can see it. Claude will usually warn you when you do this. Don’t count on an open model to do the same. I did it once myself, and rotated the key. The better fix is to never have a secret in the chat at all: a password vault for AI agents is how I solved that for good.

None of these are specific to Chinese models. They’re what I’d want around any coding agent. That’s really the point: once the data path is handled by the host, the remaining risk is agent risk, and you manage it the same way for every model.

Choosing a host: my checklist

1. Where are the servers, and whose law applies?
2. Is zero data retention the default, a setting, or “on request”?
3. Does the privacy policy allow training on API data?
4. Does the host document caching, and what does a cache read cost? For agentic work this decides the bill, more than the headline price per token.
5. Which precision is served? The same model name runs as int4, fp4 or fp8 depending on the host, and that can change quality.
6. Is the prompt cache isolated per customer? A cached prompt answers faster, and if the cache is shared between customers, someone can send a guessed prompt beginning and time the reply. A fast answer means someone else sent exactly that recently. Researchers at Stanford found such shared caches at seven API providers in 2025, including OpenAI. Since then, most providers isolate caches per account: Anthropic and Fireworks say so explicitly. TensorX’s and Mistral’s caching docs don’t say either way.

The fourth point turned out to be bigger than I expected. Of all the hosts I looked at that offer caching, mine charges the highest rate for cache reads, and there are cheaper European options. That’s a post of its own, and I’m probably switching.

What I take away

• Using a Chinese open model doesn’t mean sending your code to China. The host decides that.
• EU hosting with zero retention removes the risk most people are afraid of.
• If you need zero data retention, an EU host for open models gives it to you by default. With the frontier providers it’s an enterprise exception.
• What remains is trust in the weights, and you handle that like any agent risk: no secrets, limited access, every change reviewed by a different model.
• The cheapest API is often the vendor’s own. Know what you’re trading for the price.