The short version: After the July 22 accusation that Moonshot distilled Anthropic's Fable to build Kimi K3 — and Treasury's threat of sanctions and Entity List designations — every Chinese open-weight model became a supply-chain risk, independent of whether the charge is true. You don't resolve that by picking a side. You resolve it by building so that losing any one model is a config change, not a rewrite. Here's the checklist.

Why this is a supply-chain problem, not a morality problem#

You can't adjudicate the distillation debate from your desk, and you don't have to. What matters is the enforcement mechanics. An Entity List designation is an administrative action by the US Bureau of Industry and Security — not a court verdict — which means it can land fast and without the technical question ever being settled. When it does, US-based clouds and inference providers that serve you the model may be required to stop.

So the risk isn't "is Kimi K3 stolen." The risk is: the cheap, capable model at the center of your product could become undeliverable on a government timeline, not yours. That reframing is the whole game. Treat these models like any single-supplier component with geopolitical exposure — useful, worth using, and never something you can't swap out.

The checklist#

1. Wire a tested fallback before you ship. Pick one Western open-weight model (or a hosted frontier API) that can do the job at acceptable quality, and route to it behind a feature flag. The bar is one afternoon to switch, not one quarter. A fallback you've never run in anger is not a fallback.

2. Decide where the weights physically live — this is the highest-leverage choice. Weights you've already downloaded and self-host keep running even if a provider is forced to delist. Weights you only rent through a US inference host disappear when they do. If the model is core to your product, self-hosting a pinned checkpoint is the strongest hedge; see our rent-vs-self-host math on K3 and just add a "provider gets delisted" row to the risk column.

3. Pin and back up the exact checkpoint. Don't assume you can re-download later. If you're depending on a specific version, store it like you'd store a critical dependency — because that's what it is.

4. Keep the model swappable in code. Abstract every model call behind one interface. Keep prompts and output formats model-agnostic — no reliance on a particular model's quirks, token habits, or formatting tells. The teams that get hurt in a forced migration are the ones who let a single model's personality leak into their core loop.

**5. Run your eval suite against primary and fallback on every release.** A swap only saves you if the fallback still passes your quality bar. Test both, every time, so the day you need to flip the switch you already know what breaks.

6. Know your provider's jurisdiction. Renting through a non-US host changes your exposure — sometimes helpfully, sometimes not. Read the data-residency and compliance terms before you build on it, not after.

The decision, in one line#

If a Chinese open-weight model is doing substitutable, non-critical work, use it and keep a fallback — the risk is low and the price-performance is real. If it's the core of your product, self-host a pinned checkpoint and treat the hosted version as a convenience, not a dependency.

This is a portable playbook. The trigger this week was Kimi K3, but the same enforcement lever hangs over Qwen, GLM, DeepSeek, and whatever gets named next. We covered the same fault line when China's persona law took effect: the models keep getting cheaper and better, and the political surface around them keeps growing. Build for the swap, and you get to keep using the cheap, strong models without betting your company on a headline you can't control.