Which model scores highest stops mattering the moment a policy move can strand a workload. Here is how to know which of your model dependencies are exposed.
The most important AI date this week was not a launch. It was the day the gap between owning a model and renting one turned into a policy question.
On July 27, Moonshot AI released the full weights for Kimi K3, a 2.8-trillion-parameter model from the same family of Chinese-origin systems teams have quietly been routing to for months. This open-weight drop was not routine. Its maker is under active US investigation: a White House official accused Moonshot of building K3 by covertly distilling Anthropic's Fable and training on export-banned Nvidia chips routed through Thailand, the Commerce Department's Bureau of Industry and Security opened a formal case and floated adding Moonshot to its Entity List, and the Treasury Department raised the possibility of sanctions.
I want to be precise about what is and is not established here, because it matters for the argument. The accusation is real and it came from a named official. The investigation is real. What is not established is guilt: no supporting evidence has been made public, several researchers dispute that the timeline even allows for the distillation described, and Moonshot has not been charged with anything. This piece does not adjudicate whether Moonshot stole Fable. It does not need to.
Here is the point. You do not have to know how the investigation ends to know that your exposure just changed. A model your teams depend on is now the subject of a federal probe with sanctions on the table. The question a CTO should be able to answer today has nothing to do with guilt. If the answer turns out to be yes, which of my workloads stop working on Monday, and which do not?
Most teams cannot answer that. That is the actual problem.
We rank models on capability and cost, and we under-weight the axis that a policy move just made decisive. Every model-selection conversation I sit in is about which model tops the coding benchmark, which one is cheapest per million tokens, which one has the longest context window. Those are real questions, andthe capability frontier keeps shifting under them. They are also the questions that a policy move renders irrelevant overnight.
The durable axis is how you get to the model, and whether a government can cut that path. Sort your dependencies that way and three categories fall out.
Weights in Hand. You have downloaded the weights and you run the model on infrastructure you control. This is the category that is durable against export controls, and the reason is almost embarrassingly simple: you already have the artifact. Published model weights sit outside the export rules to begin with, and an export restriction governs what crosses a border going forward regardless. It does not reach into your data center and delete a file you pulled last week.
An API you were planning to call has no such durability, because either government can sever it. Be precise about the two limits, though, because a careful CTO will push on exactly these. A downloaded file is frozen at the version you pulled, with no upstream security or safety updates, so durable means runnable, not evergreen. And the durability runs through export policy, not sanctions: if Treasury sanctions the vendor, whether you may keep running a model you already downloaded is an unsettled question with no guidance yet, so treat that as the edge case rather than the base case. Even with both caveats, the asymmetry holds. The bytes on your disk are yours in a way an API call never is.
Rented American. You call a US vendor's API: OpenAI, Anthropic, Google. This category is durable against a foreign export action, which is worth something, but it is not free of policy risk. It carries the ordinary vendor risks (price changes, deprecations, rate limits) plus US-side policy on who can be served. It is a rental. The landlord is domestic, which is a different risk profile, not the absence of one.
Rented Abroad. You call a Chinese-origin model through a hosted endpoint, or you reach it through an aggregator without controlling the weights. This is the most exposed category, because a single policy move on either side of the Pacific can sever the connection with no notice and no fast migration path. The same K3 you could have in the Weights in Hand column sits in Rented Abroad the moment you depend on someone else's endpoint to serve it.
Read those last two sentences again, because that is the whole insight compressed. The identical model can be your most durable dependency or your most fragile one. The difference is not the model. It is whether the bytes live on your side of the line.
There is a failure mode underneath all of this, and it is the reason the inventory is not optional. Call it the Invisible Dependency.
A meaningful number of teams are in Rented Abroad right now and do not know it, especially the ones without a governed model catalog to funnel those choices through. If you cannot produce a list today of which of your workloads touch a Chinese-origin model, you do not have a model strategy. You have a bill.
Here is how they got there. A large and growing share of the tokens developers route through the OpenRouter gateway now go to Chinese-origin models. US models' share of that traffic fell from roughly 70% to roughly 30% over the past year, and Chinese-origin models became the single largest bloc, a plurality of all routed tokens and a clear majority of the volume among the most-used models. OpenRouter skews toward developers and indie builders, so its numbers lead the market rather than mirror a governed enterprise, but the pull they show is the same one your teams feel.
That shift did not happen because CTOs made a sovereign-risk decision. It happened one service at a time. On most requests through a gateway like OpenRouter, a developer names the model and the router only picks which provider serves it. So automation did not choose this for you. Many individual developers did, each naming the cheapest capable model for their own workload, and the cheapest capable model was increasingly a Chinese one, at a price 60% to 90% below the US frontier.
No single person chose that exposure at the level where it lives. Local, rational decisions produced it, each engineer picking a cheaper model in their own service, and nobody aggregating those choices into a dependency anyone owned. That is the trap. No rogue router did this. No one had a view of the whole.
The fix is not glamorous and it is not a self-hosting mandate. Running a 2.8T-parameter model is a 1.4-terabyte download and a serious infrastructure commitment, and most workloads have no business doing it. The point of the inventory is to know, per workload, which column you are in and what strands you if policy moves. Choosing the right tool over the most advanced one is a theme we return to in Reasonable AI: a balanced approach.
Build the smallest version that tells the truth. For every AI workload in production, write down four things:
1. The model it actually uses, resolved through any router or aggregator to the specific model a developer named and the provider actually serving the token.
2. Its dependency category: Weights in Hand, Rented American, or Rented Abroad.
3. What happens to that workload if the path is cut tomorrow, and how long a migration takes.
4. Its provenance exposure, separate from its continuity exposure.
That fourth line is where the K3 case earns its keep, and it is the honest caveat to the whole "downloaded weights are durable" claim. Durable is a statement about continuity. It means you can still run the model. It says nothing about whether the model is clean. If a court eventually finds that K3 was built by improperly distilling another company's model, the file on your servers keeps executing, but you now own an intellectual-property and compliance question that the API customer who got cut off does not. A serious inventory tracks both columns, because they are different risks and they do not move together.
Portability and provenance stopped being paperwork this week. They are architecture concerns again, the same way they were when we argued about cloud lock-in and data residency, and they respond to the same discipline: know your dependencies, name them honestly, and design the ones that matter to be movable. For a workload you find sitting in Rented Abroad, movable is concrete: pre-qualify a US or self-hostable fallback, and keep the prompt and the eval harness provider-agnostic so a forced switch is a config change rather than a rewrite.
The teams that will be calm on the Monday after a policy decision are not the ones who guessed right about Moonshot. They are the ones who could already name, on any given morning, exactly which models they depend on and exactly which of those dependencies a single government signature could take away. Inventorying your top handful of production workloads takes an afternoon. A sprawling estate with dynamic routing takes longer, which is exactly why you start now, before you need it, not after.
We build model-dependency inventories with enterprise teams. We resolve every production workload to the model actually serving it, sort each one into Weights in Hand, Rented American, or Rented Abroad, and flag exactly what a single policy move would strand. It is the same discipline we brought to cloud portability and data residency: know your dependencies, name them honestly, and design the ones that matter to be movable. It is the core of our enterprise AI work.
If you cannot yet name which of your workloads touch a Chinese-origin model, that is the place to start. We will inventory your top production workloads in an afternoon and hand you a prioritized plan for the dependencies a government signature could take away. Book an AI readiness assessment to get started.