Kimi K3Open-Weights LLM

Kimi K3 is not MIT-licensed, and that is the most important thing to know about it. Its predecessor Kimi K2.6 shipped under Modified MIT, one paragraph away from plain MIT. K3 ships under a bespoke document titled the Kimi K3 License, tagged on Hugging Face as license:other. Between one generation and the next, Moonshot tightened terms. Most coverage of this release led with the parameter count and treated the license as a footnote, which is backwards for anyone deciding whether to build on it.

The terms are still broadly permissive, and for the large majority of teams reading this they will never bind. But "broadly permissive with conditions" is a different procurement conversation from "Apache 2.0", and the difference shows up in legal review, not in a benchmark table.

What it actually is

Kimi K3 (Moonshot AI, launched July 16, 2026 on Kimi Code and the Kimi app, with open weights following later that month) is the largest open-weight model released to date. Per the official repository:

• 2.8 trillion total parameters, 104 billion activated per token. A Mixture-of-Experts model with 896 experts, 16 selected per token, which is a far sparser configuration than the field has been shipping.
• 93 layers, split as 69 Kimi Delta Attention (KDA) layers and 24 Gated MLA layers.
• A 1,048,576-token context window, a full million tokens.
• SiTU-GLU activation, with MXFP4 weights and MXFP8 activations, so the released checkpoint is natively low-precision rather than a post-hoc quantization of something larger.
• Text and image input, with agentic tool use as a first-class target.

Moonshot attributes the efficiency story to a Stable LatentMoE framework and reports roughly a 2.5x improvement in scaling efficiency over Kimi K2. Treat that as a vendor claim: it is a statement about their training economics, not a benchmark you can reproduce, and we quote no leaderboard numbers here for the usual reason. The numbers that decide a deployment are the ones from evals on your task.

The license, read properly

This is where the engineering decision actually gets made. The LICENSE file grants the rights you would expect from an open-weights release: use, copy, modify, merge, publish, distribute, sublicense, and sell. Download, self-host, fine-tune, and quantize are all permitted. Then it adds conditions:

• The Model-as-a-Service threshold. If the aggregate revenue of the licensee and its affiliates exceeds 20 million US dollars over any consecutive 12 months, offering the model as a service requires a separate agreement with Moonshot AI. This is the clause that matters most and gets quoted least.
• The branding threshold. A product or service with more than 100 million monthly active users, or more than 20 million US dollars in monthly revenue, must display "Kimi K3" prominently on its user interface.
• Section 4 exemptions, which are broader than the thresholds suggest. The restrictions do not apply to internal use, defined as any use that does not make the software, its outputs, or its underlying capabilities available to third parties. They also do not apply to use accessed through Moonshot's official products or certified inference partners.

Read those together and a clear map falls out:

• Internal deployment: unconditionally fine. If you are running K3 inside your own company on your own work, no threshold applies to you at any revenue. This covers most enterprise adoption.
• Building a product on top of it: fine until you are very large. The branding clause needs 100 million monthly active users or 20 million dollars of *monthly* revenue. If you cross that, a wordmark on your interface is not the constraint that will be keeping you up at night.
• Reselling inference: read carefully. If your business is serving this model to other people and your group revenue clears 20 million dollars annually, you need a signed agreement before you start, not after. The threshold is on *your* revenue, not on your K3 revenue, which is easy to misread.

Compare this to Qwen 3 under plain Apache 2.0, where legal review is a lookup rather than an analysis, and the practical trade becomes visible. Apache 2.0 has no thresholds to monitor and no clause that changes behavior as you grow. The Kimi K3 License has two, plus an obligation to notice when you cross them.

The constraint nobody is talking about: you are not self-hosting this

2.8 trillion parameters is not a number most organizations can serve, and the released weights run to well over a terabyte. Even at MXFP4, this is a multi-node deployment with an interconnect budget, not a model you stand up on a spare box to evaluate. For the overwhelming majority of teams, "open weights" here means *auditable and portable in principle*, not *self-hosted in practice*.

That reframes the license question. If you are consuming K3 through an API, the branding clause is almost certainly irrelevant to you and the Model-as-a-Service clause belongs to your provider. The reason to care about the license at all is the reason open weights matter generally: the model cannot be deprecated out from under you, you can move providers, and if the economics ever justify bringing it in-house the door is open. Those are real properties. They are just not the same as running it next week.

When to use it, and when not

Consider Kimi K3 when:

• The workload is long-horizon agentic work and the million-token context is doing real work rather than padding a spec sheet.
• You want frontier-class capability with an exit path from any single API vendor, and you are willing to accept a conditional license to get it.
• Your usage is internal, where Section 4 removes the conditions entirely.
• Multimodal input matters and you would otherwise be running a separate vision model.

Do not reach for it when:

• Your procurement process requires a standard OSI license with no thresholds. That is a legitimate policy, and Qwen 3 or DeepSeek R1 satisfy it where K3 does not.
• You intend to build a Model-as-a-Service business on it and your group revenue is already past 20 million dollars, unless you have the separate agreement signed first.
• You need on-premise deployment on hardware you already own. At this scale, that is a datacenter project, and a smaller model that clears your quality bar is the better engineering answer.
• The task is well-served by a 30B-class model. Sparsity helps the serving cost, but 104B activated parameters per token is still 104B activated parameters per token.

How we would evaluate it for a client

The procedure does not change because the model got bigger:

1. Build the eval set before touching the model. Our model engineering engagements start with the client's task-level evals, because a million-token context and a trillion-parameter count tell you nothing about whether the thing answers your questions correctly.
2. Run the license question in parallel with the technical one. Legal review and evaluation should finish in the same week. Discovering a threshold clause after a successful pilot is how a project loses a quarter.
3. Assume API access first. Rent before you buy is always the right sequencing, and at 2.8T it is the only sequencing. Reserve the self-hosting conversation for the point where volume, latency, or data residency makes it unavoidable.
4. Check whether a smaller model wins. In our evaluations the frontier model usually is not the answer. It sets the ceiling, and then something four rungs down clears the client's bar at a fraction of the cost.

The genuinely notable thing about Kimi K3 is not the parameter count, which will be beaten. It is that the largest open-weight release to date arrived with more license conditions than the smaller one before it. If that becomes the pattern as open-weight models approach frontier capability, "open weights" stops being a single category and starts being a spectrum that needs reading every time.