Moonshot AI just released Kimi K3 along with its weights. It is a 2.8T parameter model, with 1M context window and competitive results on several agent evaluations, placing this new model very close to frontier level.

Training a model of this size takes a huge amount of compute, data, and engineering work. At first, it seems counterintuitive to make that investment and then publish the weights. Moonshot could keep K3 behind its own API, serve all inference itself, and try to recover more of the training cost directly from the customers using it.

So why publish the weights at all? I think the more important strategic reason is distribution, because publishing the weights gives labs like Moonshot a route to the distribution that OpenAI, Anthropic, and Google already have.

Open weights is not open source

Before getting into strategy, it helps to separate two ideas that are constantly mixed together. Publishing weights means someone else can download the trained parameters and use them to run the model, fine-tune it, or fit it into their own inference stack. In practice, an open weight release usually ships enough information to load the model, such as an architecture configuration and tokenizer. That is enough for an inference provider to operate the model without calling the lab’s API.

It still does not make the model fully reproducible or fully transparent. The training data, training code, post-training pipeline, and much of the evaluation work remain private. The release gives access to the result of that work, not necessarily to the process that created it. In the strict sense, many of these releases are open weight rather than open source. The distinction matters in the rest of the post because releasing weights lets other operators serve the model, but it does not mean the lab has made all of its research public.

Distribution

A new lab does not compete on model quality alone, it competes with an API that is already integrated into projects, SDKs, agents, cloud providers, and development tools. OpenAI, Anthropic, and Google have that distribution. In many applications, changing models within the same provider is just changing the model handle and maybe some tweaks to system prompts.

Subscriptions lower friction too, as they give many people a cheap way to try a model inside a polished tool and, at the same time, get teams used to its APIs and SDKs. Serious billing often arrives when those flows become automated processes and B2B products.

A lab that arrives later can have a very good model and still lack that network, but publishing weights lets it turn other companies into distributors. Companies like Together AI, Fireworks, DeepInfra, Modal, and even cloud providers like Google Cloud and AWS can deploy the model, offer an endpoint compatible with their customers, and place it in the catalogues that developers and companies already use. These providers already have the billing, support, and API that their customers know how to operate.

Open weights are not strictly necessary to achieve this. OpenAI and Anthropic models are available through traditional cloud providers too, but those arrangements exist because the models already have demand and because the companies have made commercial agreements. A Chinese lab with less enterprise traction may have a harder time securing the same distribution agreements with major US cloud providers. If the weights are available, an inference provider can deploy the model independently as soon as its serving stack supports it.

Chinese labs

Consuming an API from a Chinese provider can add friction that does not exist with Western providers. There are questions about data residency, support, and compliance that can block a change even if the model is interesting. Serving the same weights through an independent US- or EU-based provider can remove some of that friction, particularly around data residency, billing, and existing vendor relationships.

There is also a compute context. A lab has to split its compute between serving the current model and building the next one. GPUs used for inference are not running experiments or training a new model. If a lab allocates most of its compute to research and training, it is left with slower inference and less capacity to serve users, and if it allocates most of it to inference, research and training for the next generation slow down.

Western labs have the same trade off, but Chinese labs can have it more tightly constrained. US export controls have restricted the sale to China of high-performance GPUs and the systems that incorporate them, which can make it harder to simultaneously serve all the traffic to trained models and keep iterating on research and training.

An open release can let third-party providers take on part of the inference demand, potentially leaving more of the lab’s own compute available for research and training.

Open weights does not mean cheap to run

When a model is released as open weights, people usually assume that one of its strengths is that it will be cheaper than frontier models and that it can be run locally, and this does not have to be true. Frontier models can improve through architecture, data, post-training RL, and test-time compute, but they often remain expensive to run despite architectural efficiency. Companies that are trying to compete at the frontier are not going to lower their capability targets just to make a model more accessible to local users.

Kimi K3 has 2.8T parameters. Qwen 3.8 Max has 2.4T. GLM-5.2 does not reach one trillion parameters, but it’s expensive to run. With models at these sizes, it is difficult to make them cheap to serve, so their token prices do not necessarily differ much from frontier models. The more useful comparison is cost per completed task. Depending on the model, workload, tool calls, and reasoning length, an open-weight model with similar performance can cost the same or more than an OpenAI or Anthropic model. Artificial Analysis’ Kimi K3 evaluation is a good example of that distinction.

It is important that open-weight models can now compete with OpenAI and Anthropic models, but it is a mistake to assume that they are always cheaper.

The other assumption is that an open-weight model can be run locally regardless of its size. The community has done many experiments with loading weights from SSDs, offloading layers, and running inference one layer at a time when there is not enough hardware. These are useful experiments, but local inference on models of this size is not practical outside experimentation and hobby use. Producing a token eventually is very different from serving a coding agent or several users at usable speeds and concurrency.

These models are not designed around inference on consumer hardware. They can be self-hosted with enough infrastructure, but practical private deployment is very different from running them locally on a workstation.

Open weights releases are very important

The useful question is what changes when a frontier model is released as open weights and can be served outside the lab that trained it.

Open weights give the user more control over where their data goes. A company can choose an inference provider based on its data region or security requirements instead of sending every request to the original lab. It can also rent capacity in a datacenter and run the model there, privately. That does not remove the work of securing the deployment, but it gives the company a choice that does not exist with a model that can only be called through one provider’s API.

When a model is only available through an API, the company hosting it decides what it can and cannot be used for. Those limits can clash directly with the interests of the person who needs the model, even when the use is legitimate. Anthropic’s initial Fable 5 system card described safeguards for a narrow set of frontier LLM development tasks that would not be visible to the user. Those requests could be routed to a less capable model without a clear indication that Fable had been limited. After community backlash, Anthropic changed the fallback so users can see when affected requests fall back to Opus 4.8.

Recently, HuggingFace reported that its initial attempts to analyse an agent driven intrusion with frontier models were blocked by the provider’s safety guardrails. The investigation required submitting real attacker commands and exploit payloads, and the guardrails could not tell an incident responder apart from an attacker. HuggingFace ran the forensic analysis using GLM-5.2, an open-weight model, on its own infrastructure. That kept attacker data and the credentials referenced by it inside its environment. Their incident disclosure is a useful example of why a defensive team may need a capable model it can operate itself, without being blocked by a provider’s cyber refusals.

Frontier open-weight models do not need to be cheaper, more cost-effective, or easy to run locally to be important. They give us more control over where our data goes and the uses we can make of a model.