Kimi K3: The Parameter Count Is the Least Useful Number

Moonshot AI never claimed Kimi K3 was the largest model ever released. The 47-page technical report says "unprecedented 3T-class parameters" and names its competitive set as models "within or slightly above the 1T-class regime." Then, in the abstract, it concedes that overall performance "still trails the most powerful proprietary models, namely Claude Fable 5 and GPT-5.6 Sol."

The superlative belongs to the coverage, not the vendor. So does the sense that something was settled on July 27. By the time the weights finished uploading, the one leaderboard K3 genuinely led had already changed hands.

None of this makes K3 uninteresting. It makes the interesting part hard to see, because the number in every headline is the number that matters least to anyone deciding whether to use it.

What Moonshot shipped, and what three widely repeated facts get wrong

The model card and the technical report agree on the shape of the thing.

Three things circulating widely are wrong, and they are worth correcting because each one changes a decision.

The license is neither Modified MIT nor Apache 2.0. Both appeared in early coverage. It is a bespoke license, structurally MIT plus three clauses, and the text has real teeth for resellers: a managed-service provider whose total company revenue passes USD 20 million in twelve months has to sign a separate agreement. Clause 4 exempts internal use. For most enterprises deploying K3 inside their own product, the license is a non-event, which is the opposite of what the phrase "open with a caveat" implies.

The download is not 594 GB. That figure propagated through a cluster of low-quality sites and is arithmetically impossible for this model at this precision. The Hugging Face API reports 1,561,018,243,668 bytes of used storage, which is 1.561 TB in decimal and 1.420 TiB in binary. A long argument on the model's discussion board about whether it is "1.4 TB" turns out to be a units disagreement rather than a factual one.

And there is no FP16 checkpoint. MXFP4 is the trained format, not a post-hoc compression, so the commonly quoted "5.6 TB at full precision" describes a file that does not exist. That detail matters more than it sounds: Hopper-generation accelerators lack native MXFP4 support, which constrains who can serve this model more tightly than raw memory capacity does.

The record expired before the download finished

K3 reached first place on Arena's Code Arena Frontend category at 1,679 Elo, a result Moonshot reports in its own paper as 1,678 out of 99 models. That was 2026-07-16, the day the API opened. The weights landed ten days later.

Checked on 2026-07-28, the Code Arena leaderboard reads differently.

Arena marks both of the top two scores preliminary, and the intervals are wide enough that the ordering could move again. The direction is what matters: K3 held the top slot for about eleven days and lost it before the thing the headlines were about, the weights, was public. The launch coverage is describing a standing that no longer exists.

The confusion runs deeper than one stale ranking. Arena runs several boards, and K3 sits in very different places on them. It led Code Arena. On the same operator's Text Arena it ranks eighth of two hundred at 1,486, behind Fable 5 at 1,507. On Agent Arena it is fourth of thirty-seven. One row up K3 leads by 44 Elo; two rows down it trails by 21. Any of those rows can be quoted as the headline, and in the past week all of them have been.

One number in this launch is worth acting on

Datacurve's DeepSWE leaderboard does something almost nothing else in this launch does: it runs every model through the same agent harness, mini-SWE-agent, across the same 113 tasks, and publishes cost alongside capability. Updated 2026-07-25, it puts K3 at 69% plus or minus 5% at $4.65 per task, and Claude Fable 5 at 70% plus or minus 4% at $21.63.

Read that carefully. The capability difference is inside the error bars. The cost difference is a factor of 4.6.

That is the whole commercial argument for K3, and it survives scrutiny in a way that none of the leaderboard placements do, because the harness is held constant, the operator has no stake, the confidence intervals are published, and the price is in the same table as the score. Artificial Analysis lands in a similar place on blended token cost, at $2.31 per million against $7.70.

If a team is running high-volume coding or agentic work where cost per completed task dominates, that comparison is worth a week of evaluation. Everything else in the launch is noise by comparison.

Why most of the other numbers are not

It would be easy, and wrong, to say the benchmark claims are unverified. They largely are not. Section 6.3 of the technical report points at Artificial Analysis, Vals AI, LMArena, and a joint UK AI Safety Institute and NIST CAISI assessment, and those independent evaluations broadly agree with Moonshot's own modest framing of a strong second-tier model. On the question of whether K3 is roughly as good as Moonshot says, the answer is yes.

The problem is narrower and more specific. Moonshot's forty-row comparison table spans six different agent harnesses: Kimi Code, Claude Code, Codex, mini-SWE-agent, Terminus 2, and Harbor. One row substitutes H20 hardware for H100. Another runs SWE-Marathon on a July 9 pre-release branch on which Fable 5 fell back on 35% of tasks.

Harness choice is not a footnote. Researchers at Tulane and Virginia Tech measured swings of 8.5 to 13.0 points from harness alone, and found harness-driven variance 7.80 times larger than model-driven variance. Several of the margins in Moonshot's table are smaller than that.

The cleanest illustration has nothing to do with K3. Fable 5, running Terminus 2, scores 80.4 on the official Terminal-Bench board and 88.0 at Artificial Analysis. Same model, same named harness, 7.6 points apart. K3 does not appear on the official board at all.

In fairness to Moonshot, the asymmetry does not obviously favor them. On Kimi Code Bench 2.0, their own in-house benchmark, K3 scores 72.9 under its own Kimi Code harness and 73.7 under Claude Code, while Fable 5 takes the row at 76.9. Their harness makes their model look worse than their competitor's harness does, on the benchmark they built, and the model card says so in a footnote. A vendor cherry-picking harnesses would not publish that.

Two other things deserve mention. Ofir Press, who maintains ProgramBench and co-created SWE-bench, objected that Moonshot used a metric he does not recommend, averaging implementation percentage rather than counting fully working programs, which he said can overstate usefulness. The original post could not be retrieved directly for this article, so that quote is as relayed by secondary coverage and should be read with that caveat.

The second is buried rather than disputed. Artificial Analysis measured K3's hallucination rate rising from 39% to 51% between K2 and K3, while accuracy rose from 33% to 46%. The model got more capable and less reliable at the same time. That trade appears in none of Moonshot's charts, and for anyone chaining tool calls in an agent loop it compounds.

Three figures are circulating that a careful reader should reject outright. "K3 scores 76.8% on SWE-bench Verified" is a phantom: Moonshot never reports SWE-bench Verified, and 76.8 is Fable 5's ProgramBench score, misattributed by aggregators. "Kimi Delta Attention makes long context six times cheaper" comes from the Kimi Linear paper, measured on a 48-billion-parameter research model, and appears nowhere in the K3 report. "Four times slower than Fable 5" is closer to 2.3 times on decode, and K3 is roughly twice as fast to first token.

Open weights moved the model, not the ability to serve it

Here is the finding that reframes the release.

Artificial Analysis measured five providers serving identical K3 weights. Fireworks returns 164.4 tokens per second with 13.27 seconds to first token. Moonshot's own endpoint, serving its own model, returns 32.0 tokens per second with 160.75 seconds to first token. That is a 5.1x spread in throughput and a 12.1x spread in latency, on the same files. Moonshot serves at mxfp4; Baseten serves at fp8, at the same list price.

The weights are the easy part to copy. The serving stack is not, and it is where the actual product differences now live.

For teams considering self-hosting, the floor is concrete. The vLLM recipe states it plainly: "At least one 8x B300 (or GB300 NVL72) node is required; 16x B200 is also supported." That is eight accelerators of 288 GB, roughly 2.3 TB of aggregate high-bandwidth memory. RunPod, TokenSpeed, and AMD converge on the same requirement. The widely repeated claim that a single node of eight H200s suffices is arithmetically impossible, since that is 1.128 TB against 1.420 TiB of weights, and it traces to a page published on 2026-07-17, ten days before the weights existed.

The local path is closed. Kimi Delta Attention is not supported in llama.cpp, Ollama, or LM Studio; the enabling pull request was opened on 2026-07-27 and is still open, and released builds cannot load the model. Two community quantizations exist, and their author states of the smaller one that nobody has managed to load it yet, adding that he does not own sufficient computational resources to test it.

Which produces the most telling absence in this entire launch. The r/LocalLLaMA community, normally the fastest source of real throughput numbers for any open-weights release, has published none. There is no independently measured self-hosted throughput figure for K3 at any batch size. Every throughput number in circulation, including vLLM's 111 tokens per second per user and SGLang's 423, comes from an engine vendor with pre-release access. Baseten shipped a production API and published no throughput number at all. AMD explicitly declined to make claims about throughput, time to first token, or kernel efficiency.

The break-even arithmetic below is a derivation rather than a measurement, and should be treated as such. Eight B300s at a median $8.23 per GPU-hour is $65.84 an hour, roughly $48,000 a month. To beat the $15 per million list price on output, that cluster needs to sustain something like 1,219 output tokens per second. The market blended rate is already $2.31 per million. Self-hosting K3 to save money is a bet that requires unusual volume and unusual utilization, and RunPod, who sell the hardware, decline to do the arithmetic for you: their guidance is to run representative traffic, read the sustained rate, and put it in the formula yourself.

The unglamorous facts that will decide adoption

None of the following appeared in a headline this week. All of them will show up in the first week of an integration.

• Reasoning cannot be disabled. Every call bills thinking tokens at the $15 output rate, and reasoning_content has to be round-tripped on every turn to preserve the chain. Sticker price and effective price diverge.
• There is no batch API and no batch discount, while Anthropic and Google both publish 50% off batch traffic. For workloads that are naturally asynchronous, that erases a meaningful part of the cost advantage.
• The Anthropic-compatible endpoint is partial. Moonshot's own documentation says the endpoint "does not support WebFetch for now," and Tool Search must be disabled. The OpenAI-compatible path is a clean base-URL swap; the Anthropic one is not.
• No hyperscaler availability. Vertex lists K2 Thinking, Foundry carries K2.7 Code, and there is no evidence of a Bedrock listing. Teams with procurement locked to a cloud marketplace cannot buy this yet.
• Procurement risk is real but misdiagnosed. There is no US ban in force. The live exposure for Western vendors is federal-contractor procurement rules under consideration, and self-hosting does not solve that, because the question is provenance rather than data residency.

What would have to be true

The case for moving work to K3 is narrow and testable. High-volume coding or agentic tasks where cost per completed task dominates the bill. Tolerance for roughly 2.3x slower decode. A willingness to benchmark on your own harness rather than trusting anyone's table, which the harness variance data makes non-optional.

The case against is equally concrete. Latency-sensitive interactive surfaces, given the decode gap. Workloads that depend on batch pricing. Procurement that runs through a cloud marketplace. And any plan whose justification is that self-hosting will be cheaper, which the arithmetic does not currently support.

Three things are worth watching, and all three could change the answer inside a month: independent same-harness reproductions appearing, Alibaba shipping Qwen3.8-Max weights at 2.4T, and whether Telnyx's $2.70 and $13.50 pricing, a deliberate undercut posted within 48 hours of the weight drop, spreads to other hosts.

The number that scaled was storage

2.8 trillion is a real number and it sits on a curve. DeepSeek's 671B, then a trillion, then V4-Pro at 1.6T in April, now 2.8T: roughly a doubling every eight months. Sparsity did not improve to match. K3 activates about 3.7% of itself, against 3.2% for K2, which makes it proportionally less sparse than the model it replaces.

What scaled is what you have to store, not what you have to compute. That is why the download is a terabyte and a half, why the floor is eight of the largest accelerators made, and why the local ecosystem could not follow. The question was never whether you could have the weights. Moonshot gave away a model that five companies now serve at five different speeds from identical files, and the gap between the fastest and the slowest of them is larger than the gap between K3 and the frontier.

References

Primary sources

• Moonshot AI. Kimi K3 technical report. 2026-07-27.
• Moonshot AI. Kimi-K3 model card on Hugging Face.
• Moonshot AI. Kimi K3 License.
• Moonshot AI. Kimi K3 quickstart and API documentation.
• Moonshot AI. Kimi K3 launch post.

Independent evaluation

• Datacurve. DeepSWE v1.1 leaderboard. Same-harness comparison with cost per task.
• Artificial Analysis. Kimi K3 against Claude Fable 5.
• Artificial Analysis. Terminal-Bench v2.1 evaluation.
• Terminal-Bench. Official 2.1 leaderboard.
• Arena Intelligence. Code Arena and Text Arena leaderboards.

Evaluation methodology

• Agent harness variance in coding benchmarks. Tulane University and Virginia Tech, 2026-05-07.
• Moonshot AI et al. Kimi Linear, the origin of Kimi Delta Attention and of the six-times figure often misattributed to K3.

Serving and deployment

• vLLM. Kimi K3 recipe and launch notes.
• Baseten. Building a day-zero API for Kimi K3.
• llama.cpp. Kimi Delta Attention support, pull request 26185.
• RunPod. Kimi K3 technical FAQ.
• Northflank. Kimi K3 self-hosting analysis.
• Telnyx. Kimi K3 inference release notes.

Context and coverage

• Nathan Lambert. Kimi K3: the open-weights escalation. Interconnects.
• The New Stack. Moonshot opens Kimi K3 weights, but few can run it.
• VentureBeat. Kimi K3's full weights are here, but they're open with a caveat.
• MarkTechPost. Kimi K3 against DeepSeek V4-Pro and GLM-5.2.
• TechNode. Moonshot AI to make Kimi K3 available for public download.