Kimi K3's Open Weights Are Live. The 2.8 Trillion Parameter Model Almost Nobody Can Run.

July 30, 2026. Three days ago we published that Kimi K3's open weights had not appeared. We had checked the Hugging Face API twice, at 04:05 and 04:30 UTC on the day Moonshot AI's own deadline expired, and found no repository while weekend posts were already calling the model shipped. That was true when we wrote it. It is not true now. The full weight set is live, and the correction is worth more than the original story.

Kimi K3 is a 2.8 trillion parameter model released under an open licence. Moonshot calls it the world's first open 3T class model. It is also about 1.4 terabytes of files that Moonshot itself recommends running on 64 or more accelerators. Both of those facts matter, and most coverage this week is only carrying the first one.

What actually shipped

1. The complete weight set. The repository now holds 96 safetensors shards plus a 59 MB index file, the licence, the config and the modeling code. This is the whole model, not a preview or a distilled variant.
2. 2.8 trillion total parameters, 104 billion activated per token. A Mixture of Experts design with 896 experts, of which 16 are selected per token, plus 2 shared experts across 93 layers.
3. A 1,048,576 token context window, with native vision. Text and images go through the same model via a 401M parameter MoonViT-V2 encoder.
4. A new attention architecture. Moonshot built K3 on Kimi Delta Attention and Attention Residuals, with a Stable LatentMoE framework, and reports roughly a 2.5 times improvement in scaling efficiency over Kimi K2.
5. Quantization baked in from training. MXFP4 weights with MXFP8 activations, applied through quantization-aware training from the supervised fine-tuning stage onward rather than bolted on afterwards.
6. Its own licence. Not Apache, not MIT. The weights ship under a bespoke Kimi K3 Licence, which anyone planning commercial use needs to read rather than assume.
7. Day one inference support in vLLM, SGLang and TokenSpeed, with Moonshot contributing a prefix caching implementation to vLLM because its new attention design broke the conventional approach.
8. A hosted API alongside the weights, priced at $0.30 per million tokens for cache hit input, $3.00 for cache miss input and $15.00 for output.

The correction, stated plainly

Our July 27 report said the weights had not appeared as of 04:30 UTC that morning. We are not retracting it, because it was accurate at the time of checking and it was more accurate than the roundups that were already calling the release done. But it is now out of date, and readers who acted on it should know the position changed.

There is a lesson in how we got there. Checking the same platform today, two endpoints disagreed within minutes. A listing query for the publisher's models returned a stale cache whose newest entry was six weeks old and contained no K3 at all. A direct request for the exact repository path returned the complete, current manifest. The wrong answer was the one that looked like a comprehensive list. If you build automation that checks whether something exists, that is the failure mode to design against: a listing endpoint that returns successfully but incompletely is more dangerous than one that errors, because nothing in the response tells you it is stale. Query the exact object, not the index.

One more detail worth recording: Moonshot's own announcement blog still reads, in the future tense, that the weights "will be released by July 27, 2026." It was never updated. The vendor's announcement page and the vendor's artefact told different stories, and only the artefact was correct.

Where K3 leads, and where it does not

Moonshot published a large benchmark table comparing K3 against Claude Fable 5, GPT-5.6 Sol and others. Every figure below is vendor reported, produced at maximum reasoning effort, and in several cases each model ran under a different agent harness, which alone can move results. Moonshot's own summary is unusually candid: overall performance "still trails the most powerful proprietary models, Claude Fable 5 and GPT 5.6 Sol." That is the vendor saying it did not win, which makes the places it does lead more interesting rather than less.

On the vendor's numbers, K3 comes out ahead of both Fable 5 and GPT-5.6 Sol on MCPMark-Verified at 94.5, BrowseComp at 91.2, AutomationBench at 30.8, Harvey Lab-AA at 94.6, OmniDocBench at 91.1 and a banking agent benchmark at 33.4. It also posts 42.0 on SWE-Marathon against 35.0 for Fable 5, though Moonshot discloses that Fable 5 hit fallbacks on 35% of tasks in that particular run, which is exactly the kind of footnote that should stop you quoting the headline number.

It trails on the things you would expect a frontier lab to still own. Fable 5 leads on the hardest reasoning set, on FrontierSWE, on a general economic-value benchmark and on OSWorld 2.0 by a wide margin. GPT-5.6 Sol leads on DeepSWE and on the top reasoning benchmark.

Notice the shape of that split. K3's wins cluster in tool use, browsing, document handling and workflow automation. Its losses cluster in raw reasoning and the hardest software engineering. If your interest is "can it operate my stack reliably" rather than "can it solve novel problems," that is the more relevant half of the table.

What it means for operators

Start with the thing that is not true. Open weights do not mean you are going to run this. At roughly 1.4 terabytes, with a vendor recommendation of 64 or more accelerators, self hosting K3 is a data centre project, not an IT project. Any vendor telling a small business it can now "own its AI" because K3 is open is selling something.

What open weights actually buy you is optionality and price pressure. A frontier class model with published weights can be hosted by anyone, so the price is disciplined by competition rather than set by one company, and the model cannot be withdrawn from you. Every business that built on a model tier and then watched its access or price change knows why that matters, and we covered it when Opus 5 held its price line this week.

The second is more specific. One of K3's strongest results is on MCPMark, which measures how well a model drives tools over the Model Context Protocol, the same protocol that just had its largest rewrite since launch. The layer your automations run on is standardising while the models driving it get cheaper and more numerous. The practical consequence is that model choice is becoming a configuration decision rather than an architectural one, provided you built it that way. And if your AI automation costs are dominated by one frontier vendor, a credible open alternative at this level is leverage whether or not you ever switch.

The three limitations Moonshot published itself

Vendors rarely list their model's failure modes, so when one does, read them carefully. Moonshot names three, and two are production risks rather than benchmark footnotes.

First, K3 is unusually sensitive to thinking history. It was trained in a preserved thinking mode, and if your harness does not pass the complete assistant message back, including reasoning content and tool calls rather than just the text, output can become highly unstable. Moonshot also warns against switching an in progress session to K3 from another model. If you route between models mid conversation, and many automation platforms do, that is a direct compatibility problem.

Second, K3 is prone to what Moonshot calls excessive proactiveness. Because it was trained hard on long horizon tasks, it may make unexpected decisions on your behalf when it hits an ambiguity rather than stopping to ask. For an agent that touches customer records, billing or outbound messages, that is the single most important sentence in the release. It is fixable with explicit constraints in the system prompt, but it has to be done deliberately.

Third, Moonshot concedes a noticeable gap in user experience against Fable 5 and GPT-5.6 Sol. Capability and pleasantness to work with are not the same thing.

What to do this week

1. Do not plan to self host it. If someone quotes you for on premise K3, ask how many accelerators are in the quote.
2. If you are paying frontier prices for high volume, low complexity work such as classification, extraction or document handling, price a hosted open model against it. That is where the published gap is widest.
3. Check whether your automation platform can switch models per workflow. If it cannot, that is the thing to fix, well before you decide which model you prefer.
4. If you test K3, test it on the failure modes the vendor named. Give it an ambiguous instruction and see what it does unasked, and check that your harness returns full reasoning content between turns.
5. Treat every number in the launch table as vendor reported until independent benchmarks land. We covered why that distinction matters when independent testing arrived for a previous launch wave and moved several of the headline claims.

The honest summary: an open model reached roughly the frontier this week, it is too big for almost anyone reading this to run, and it still changes the market you buy in. If you want help working out what that means for your own stack, that is what our AI engineers and automation team do.