Moonshot AI released Kimi-K3, a 2.8T-parameter open-weight model, and the license is once again the story. The model is public on Hugging Face and Moonshot’s platform, but commercial usage for larger Model-as-a-Service operators now comes with a separate agreement requirement instead of a plain permissive grant.
Kimi K3 is positioned as Moonshot’s most capable flagship model so far, with a reported 2.8 trillion parameters, Kimi Delta Attention, attention residuals, native visual understanding, and a 1M-token context window. For production teams, that combination matters less as a demo headline than as an inference and evaluation profile: the model is built for long-context workloads, multimodal inputs, and high-end assistant or coding use cases where memory, throughput, and latency need to be measured under realistic prompts rather than short synthetic benchmarks.
Moonshot also exposes smaller-context variants in its own product docs, including a k3-256k option alongside the 1M-token version. That suggests the serving footprint is being segmented by context tier, which is exactly what you’d expect when an oversized context window becomes a quota and cost lever rather than a universal default.
Kimi K2 shipped with a modified MIT license that kept the familiar structure and then added a commercial attribution clause for very large products. Kimi K3 drops the “modified MIT” framing entirely and tightens the commercial restriction further.
The key clause says that if the licensee or any affiliate operates a Model as a Service business and the aggregate revenue of the licensee and affiliates exceeds $20 million over any consecutive 12 months, the licensee must enter into a separate agreement with Moonshot AI before using the software or derivative works for any commercial purpose.
That has a few immediate implications:
To Moonshot’s credit, the company does not label K3 as open source in its own materials. It consistently uses “open weight,” which is the right term for a model that can be downloaded but not necessarily used under standard permissive commercial terms.
For most teams, the practical question is not whether the weights exist, but whether they can be safely integrated into a product roadmap, customer contract, and compliance review.
If a team plans to self-host K3 for internal use, prototyping, or a product that does not cross the revenue and business-model threshold in the license, the main work is operational: benchmark it, validate quality on target tasks, and decide whether the model’s cost/performance envelope is better than existing options.
If a team runs a Model-as-a-Service product at meaningful scale, the license is the gating factor, not the architecture. Legal review is unavoidable before any rollout, especially if the business is near or above the revenue threshold or if affiliates complicate the accounting boundary. This is the kind of clause that can turn a technically attractive model into a procurement non-starter for a large provider, even if the model itself is strong.
The distribution ecosystem reflects that tension. OpenRouter already offers K3 through multiple providers, apparently at pricing that often matches Moonshot’s own API rates. That makes the model easy to try, but it does not change the underlying licensing constraints for anyone planning to embed the weights directly into a commercial service.
For engineering teams, K3 should be evaluated on the same axes as any large open-weight frontier model: task quality on your own benchmark set, long-context degradation, multimodal reliability, serving cost, and failure modes under tool use or structured output constraints. The model size and 1M context window make it especially important to test memory pressure, batching behavior, and how much quality actually holds when prompts are long enough to stress attention and cache efficiency.
The licensing story is simple enough to understand: K3 is available, but not broadly permissive. That distinction matters more than the benchmark charts when deciding whether it belongs in a production stack.