On Monday, Moonshot AI publishes the full weights for Kimi K3. The company has said so plainly: "The full model weights will be released by July 27, 2026." It is a 2.8-trillion-parameter mixture-of-experts model activating 16 of 896 experts, with a million-token context window and native vision. At four-bit quantisation, 2.8 trillion parameters works out to about 1.4 terabytes on disk. That is the artifact. It goes on the internet in three days.

On Wednesday, Michael Kratsios, director of the White House Office of Science and Technology Policy, accused Moonshot of building that model by distilling Anthropic's Fable. His phrasing was careful and worth reading twice, because he drew a line rather than condemning a technique: legitimate distillation "plays a vital role in this open innovation ecosystem," but "large-scale, covert industrial distillation aimed at stealing proprietary U.S. technology" is not that. He alleged Moonshot ran a purpose-built internal platform to switch between access methods and avoid detection, and that it trained on Nvidia GB300 servers reached either directly or through Thailand.

The day before that, Treasury Secretary Scott Bessent went on Fox Business and put sanctions on the table: "If we see, especially, that overseas models are stealing from our great companies, we have the ability to sanction them because of this theft." He was equally careful to add that the administration "supports open source models, but what we do not support is IP theft."

So a serious model with a contested birth certificate arrives on Monday, and a lot of engineering teams are going to spend the weekend arguing about the wrong question.

Three gates wearing one coat

Adopting a model into a production stack has always been three separate decisions that most procurement processes squash into one meeting. This week pulls them apart with unusual clarity.

Does it work? Measurable, and the answer is yes. Nathan Lambert, who tracks open models more closely than almost anyone, calls K3 the strongest open model ever released, placing it second on the Vals AI index, third on Artificial Analysis's Intelligence Index behind only Claude Fable and GPT-5.6 Sol Max while costing less, and first in Frontend Code Arena. Whatever else is true, this is not a weak artifact riding a news cycle.

What may you do with it? Unresolved. Moonshot's technical blog announces the release date. It does not state the licence. The terms arrive with the download, which means nobody can evaluate them before Monday, which means every "we'll decide when we see it" plan is a plan to decide under time pressure with the artifact already sitting in someone's cache.

Where did it come from? Alleged, contested, and here is the part that matters: not answerable by looking at the thing. This is the gate almost no procurement checklist has a row for, and it is the only one of the three that a government can resolve retroactively.

The defect you cannot scan for

I have spent a lot of time in this workshop on supply-chain hygiene that actually works. A CVE has a fix; you patch and move on. A licence has text; you read it and your counsel gives a verdict. A dependency has a maintainer; you can ask who governs the project if the key decision-maker leaves tomorrow. Every one of those is a question the artifact itself will eventually answer if you interrogate it hard enough.

A provenance allegation answers to none of that. The weights are byte-identical whatever their lineage. There is no scanner, no SBOM field, no hash you can compare against a known-good. The evidence base lives entirely outside the file, in API access logs held by the company making the accusation. Anthropic published its own accounting in February, naming DeepSeek, Moonshot AI, and MiniMax across roughly 24,000 fraudulent accounts and more than 16 million exchanges, with over 3.4 million of those attributed to Moonshot. That is a real document with real numbers, and it is still evidence about accounts, not about the tensor file you are about to download.

The closest analogy I can find is a title dispute on a house you have already moved into. The roof does not leak. The wiring is sound. An inspection will return a clean report every single time, because nothing being contested is a property of the building. What is contested is whether you get to keep living there, and that gets decided in a room you are not in.

It is worth noting the dissent, because this is not settled fact. Hugging Face CEO Clem Delangue disputes that distillation explains Chinese labs' progress at all, crediting strong research teams and open collaboration. He may well be right. The operational point survives either way: your stack now carries a risk whose resolution has nothing to do with your engineering and everything to do with a policy announcement you will read about on a Tuesday.

The inversion nobody has priced yet

Here is where the standard advice inverts, and I find it genuinely delightful in the way that only a good structural surprise is.

Self-hosting is normally the sovereignty move. You take the weights, you run them on your own metal, nobody can deprecate you, nobody can raise your rates. That instinct is usually correct and it is exactly wrong for this artifact.

Holding 1.4 terabytes warm is not a laptop project. Published estimates put it around eighteen 80GB accelerators simply to load the model, before you serve a single token. If you commit capital expenditure to standing up one specific artifact whose legal standing is contested, your exit cost is hardware. If instead you rent K3 through an inference provider sitting behind an abstraction layer, your exit cost is a configuration line and an afternoon of regression tests.

I argued for model swappability when Apple shipped its LanguageModel protocol on grounds of cost and ergonomics: nice to be able to route the cheap queries somewhere cheap. This week reframes the same abstraction as legal insurance. The interface you build to save money on tokens is the same interface that lets you comply with a sanctions determination in an afternoon rather than a quarter.

Who should adopt K3 on Monday: teams with a genuine abstraction layer already in place, no US federal contracting exposure, and a price-to-performance problem that a frontier-class open model actually solves.

Who should wait: anyone whose customer contracts contain IP-provenance warranties, anyone selling into government, and anyone whose plan for the licence is to read it after deployment.

The takeaway

Write your swap test down before Monday, not after. One page: which component holds the model reference, how many places name a provider by string, what your regression suite would need to prove that a substitute is acceptable, and how many working days the whole exercise takes. Then run it once against a model you already have.

If that page cannot be written, then the provenance question was never really about Kimi K3. It was about the fact that you have a dependency you cannot put down, and this week simply told you what its name is.

What happens the first time a capable open model becomes legally undeployable in one jurisdiction and perfectly fine in another? The weights will not have changed. Your architecture will need to have anticipated it.