Moonshot AI releases Kimi K3 open weights: 2.8T-parameter MoE, Modified MIT license
# When the largest open-weight model in history ships, what actually changes
The Kimi K3 open weights went live at 00:00 UTC this morning. Moonshot AI released a 2.8-trillion-parameter mixture-of-experts model on Hugging Face under a Modified MIT license. In BF16 that is roughly 594 GB of weights; in MXFP4 four-bit quantization it drops to 300 to 400 GB. Community GGUFs will land within the week. This is the largest open-weight release in history, by a factor of about three.
I flagged the K3 preview in Brief 64. The interesting question was never whether Moonshot would ship; they have been reliable about weight drops. The question was what would actually change on the morning after. Three things.
## The frontier is a build-versus-buy question in more domains than it was yesterday
K3 sits fourth on Artificial Analysis' Intelligence Index at 57, behind Claude Fable 5 and two GPT-5.6 Sol reasoning settings, and ahead of Claude Opus 4.8, GPT-5.5 at xhigh, Claude Sonnet 5, and GLM-5.2. For a proprietary flagship comparison that reads "close enough," open weights are the thing that closes the deal for workloads where you cannot send data out. Health records, legal privilege, sovereign compliance, anything where the audit path matters more than the last three points of a benchmark score. If you were paying frontier API prices for those calls this quarter, you have a new option to price against.
## The sovereignty math shifts
The Hugging Face incident three weeks ago closed with Hugging Face's own security team reaching for an open-weight model, not a US flagship, because the flagship's guardrails got in the way of incident response. The next team that has to do incident response will find a bigger, more capable open-weight model waiting on the shelf. If you are a European bank, a UAE regulator, or a Nigerian fintech, the "we do not have a credible self-host option for frontier-class capability" argument no longer holds. It never really held for narrow verticals; today it stops holding for general capability.
## The hardware bill matters more than the model bill
Running K3 in production takes 4 to 8 H100 80 GB GPUs at minimum for experimental use, and multiples of that for anything resembling latency SLOs. The people who benefit today are not startups doing on-prem. They are hyperscalers and sovereign clouds who already have the fleet and can spin up K3 endpoints tomorrow. Watch which clouds ship first-day K3 inference. That is a good proxy for who is serious about the sovereign story and who is only talking.
## The caveats matter
Independent testing on the pre-release API found a 51% hallucination rate that Moonshot omitted from its benchmark charts. Most of the K3 coding wins were published by Moonshot, not by the benchmark owners' live boards. Human-preference arenas like Frontend Code Arena show K3 doing well; automated agent evals show it doing less well; the harnesses, thinking tiers, and task mixes differ enough that head-to-head comparability is genuinely hard right now. If you are considering a production adoption today, do not use vendor-published numbers. Run your own eval on your own top-200 queries. If you do not have a top-200-queries eval, that is the first thing to build, before the model choice.
The license terms are Modified MIT, the same family K2.7 shipped under, which means commercial use is permitted with a handful of specific carve-outs. Read the actual license before you make the call. I have watched a team lock themselves into a compliance rewrite because they optimistically parsed "MIT" as "MIT."
## Two priors worth revisiting
Was I wrong about how fast the open-weight frontier would close the gap? Partly. In Brief 46 I wrote that the narrower the task, the earlier small models win, and I would still write that today. What I did not price correctly was how quickly a general open-weight model would arrive that is credible on a wide task mix. A year ago I would have said not this year. K3 makes it this year. I owe that update to anyone who took the earlier framing at face value.
Was I right about incident-response models? Yes, and the counterintuitive part matters. The team most likely to trust an open-weight model for a critical task is a security team, not a research team. Security work rewards observability, reproducibility, and control. Guardrails that trip on the wrong thing are worse than a slightly weaker model you can inspect. K3 makes the case easier to make internally.
## What to do this week
If you were roadmapping toward self-hosted frontier by end of year, this is not a plan change. Keep going.
If you were roadmapping toward always using API frontier because open weights were not close enough, this is the week to redo the calculation. Take three of your API-heaviest workloads, price them at K3 self-host on your existing fleet, and see whether the sum is smaller than the API bill you paid last month. On most product mixes I look at, the answer will surprise the CFO in the right direction.
If you were on the fence about whether to have a sovereign inference path at all, the fence just got taller. The vendors of "we host K3 for you" endpoints will start ringing your phone this week. Take the meeting; do not sign anything before you have run your own eval.
I will re-run my clients' routing tables against a K3 endpoint over the coming week and report back on what actually flips. Reply if you want the eval harness I use for those comparisons; I will send it over.