Short answer: Moonshot AI released Kimi K3 on July 16, 2026, with the open weights published later that month — a 2.8-trillion-parameter mixture-of-experts model with 104B active parameters and a 1M-token context window, released under a custom “Kimi K3 License.” The model card’s self-reported coding scores approach closed frontier models. For teams that self-host AI coding platforms, this is a meaningful new option — but the license is not a standard OSI license, the deployment footprint is large, and the benchmark numbers are vendor-reported. Evaluate it like any other model: in your repository, on your tasks, behind your boundary.
What happened
Moonshot AI released Kimi K3 on July 16, 2026, and published the open weights on Hugging Face in late July; Reuters described it a day later as the largest open-weight model published to date. The headline specifications from the official model card:
| Specification | Model-card value | What to verify for yourself |
|---|---|---|
| Total parameters | 2.8T (mixture-of-experts) | Actual serving cost at your latency target |
| Active parameters | 104B per forward pass | Real GPU memory footprint with your serving stack |
| Context window | 1M tokens | Effective quality at long context, not just the maximum |
| Quantization | MXFP4 quantization-aware training | Accuracy of the quantized artifacts you would actually run |
| License | Custom “Kimi K3 License” | Exact commercial-use, redistribution, and attribution terms |
The model card also reports coding-agent benchmark results — including Terminal-Bench 2.1 and SWE-Marathon scores in the range of closed frontier models. Those numbers are vendor self-reported and, as with every launch, should be treated as screening evidence rather than proof of fitness.
Why this matters for self-hosted coding platforms
Open-weight releases change the option space for organizations that keep code inside their own boundary. A platform that manages models at the platform level can, in principle, route bounded coding tasks to a model hosted entirely on infrastructure the organization controls — which is the core promise of self-hosted AI development platforms like self-hosted MonkeyCode.
Three practical caveats before anyone updates a procurement document:
- The license is custom. “Open weights” is not the same as OSI-approved open source. The Kimi K3 License must be reviewed by counsel for commercial use, redistribution, and any usage restrictions — the same discipline we recommend for AGPL-3.0 obligations.
- The footprint is real. A 2.8T-parameter MoE with 104B active parameters is not a workstation deployment. Serving economics — GPUs, memory, throughput at agent-length contexts — will dominate the total cost. Model our self-hosting TCO estimator with your own numbers.
- Vendor scores are a starting line. Terminal-Bench and SWE-style scores screen candidates; they do not predict acceptance rates in your repositories. Run the same acceptance-tested pilot you would run for any closed model.
How to evaluate it without hype
- Define 10–20 bounded tasks with written acceptance criteria in a representative repository.
- Compare accepted outcomes, reviewer effort, and reproducibility against your current default model — not against a leaderboard.
- If data sovereignty is the driver, verify the entire route: weights hosting, serving stack, logs, and retention, not only the model file’s location.
- Record license review as an explicit gate. A model your legal team cannot approve is not an available model.
Open weights vs open source: the distinction that trips up procurement
The phrase “open-weight” is doing a lot of work in launch coverage, and it is not a synonym for “open source.” An OSI-approved open-source license (MIT, Apache-2.0, AGPL-3.0) grants well-understood rights to use, modify, and redistribute. A custom model license like the Kimi K3 License is a bespoke contract: it may restrict commercial use, impose usage caps, require attribution, or carve out categories of users. None of that is implied by the word “open.”
For a self-hosted coding platform this matters twice over. The platform’s own license (MonkeyCode is AGPL-3.0) and the model’s license are two separate legal reviews, and a permissive platform license does not soften a restrictive model license or vice versa. Treat them as independent gates:
| Layer | Example | Review question |
|---|---|---|
| Platform license | AGPL-3.0 (MonkeyCode) | What are our obligations if we modify it or expose it over a network? |
| Model license | Custom “Kimi K3 License” | Does it permit our commercial use, at our scale, without prohibited-use conflicts? |
| Serving stack | Inference server, quantization tooling | Are those components’ licenses compatible with the above? |
If any one of the three fails legal review, the combination is not deployable — regardless of how strong the benchmark table looks.
The takeaway
Kimi K3 is significant less for its size than for what it signals: near-frontier coding capability is now arriving in weights that organizations can host themselves. For regulated and sovereignty-constrained teams, the question shifts from “can we get a capable model inside our boundary?” to “can we operate one economically, and does its license survive legal review?” Both questions are answerable — with your own pilot, not with launch-day numbers.