Moonshot put 2.8 trillion parameters on the internet as a free download and, in the same fortnight, priced its own hosted API at roughly three times what the previous generation cost. Both facts are true, neither is a contradiction, and holding them together is the only way to work out whether an open-weight frontier model belongs anywhere in your agent stack.
At a glance
Kimi K3 reached the API on 16 July 2026; the weights went up at midnight UTC on 27 July. The specification is unusual in ways that matter more for agents than for chat.
| Property | Kimi K3 | What it implies for an agent |
|---|---|---|
| Parameters | 2.8T total, sparse MoE | Largest open-weight release to date. All of it has to be resident in memory. |
| Routing | 16 of 896 experts per token | Under 2% fires per token, so compute per token stays modest — but see the memory line above. |
| Context | 1,000,000 tokens | Long agent transcripts stop needing aggressive truncation. The KV cache bill arrives instead. |
| Attention | Kimi Delta Attention, hybrid linear | Moonshot claims ~6.3× decode speedup at million-token contexts — the constraint that usually kills long-horizon loops. |
| Weights | MXFP4, ≈1.4 TB download | Quantisation-aware from fine-tuning onward, so this is the intended precision, not a lossy afterthought. |
| Hosted price | $3 / $0.30 / $15 per M tokens | Cache-miss input, cache-hit input, output. Output dominates agent bills. |
On capability the picture is consistent across independent scorers. Artificial Analysis placed K3 fourth of 189 on its Intelligence Index v4.1 with a score of 57, against 44 for K2.6. Arena ranked it first on frontend code at 1,679 in blind developer testing. The Vals Index put it second at 74.70%. On AA-Briefcase, a private long-horizon agentic benchmark, it scored 1,527 — ahead of GPT-5.6 Sol Max at 1,495 and behind Fable 5 Max at 1,587. Moonshot's own framing is unusually candid: K3 still trails Claude Fable 5 and GPT-5.6 Sol overall, while beating everything else the company tested it against.
That is the headline, and it is genuinely a first — near-frontier agentic performance you can download. The rest of this post is about the three separate things people hear in the phrase "open weights", only one of which K3 actually delivers.
What actually shipped
The architectural bet is sparsity taken further than anyone has shipped openly before. A pool of 896 experts with 16 firing per token means the model reasons with a fraction of its parameters at any moment, which is how a 2.8-trillion-parameter system stays economical to serve at all. Reported figures for the effective active parameter count differ between write-ups; the routing ratio is the number consistently disclosed, and it is the one that matters for the argument below.
Kimi Delta Attention is the part agent builders should look at hardest. Replacing quadratic attention with a hybrid linear form in selected layers targets exactly the failure that makes long-horizon agents expensive: an agent re-sends its whole transcript every step, so decode cost at step 400 is nothing like decode cost at step 4. A claimed 6.3× decode speedup at million-token contexts is a vendor number and should be treated as one, but it is aimed at the right bottleneck — see agent cost control for why that curve, not the per-token price, usually decides what an agent costs.
Moonshot also ships an orchestration layer it calls Agent Swarm, claiming coordination of up to 300 sub-agents and over 4,000 tool calls per task at around 4.5× the throughput of running them in sequence. Treat the multiplier as marketing and the shape as informative: this model was trained and packaged for multi-agent work, not for chat with an agent mode bolted on.
"Open weights" is three claims, and only one holds
When a frontier model is released as open weights, three different promises get heard at once, and they come apart immediately on inspection.
It does not mean cheap
The clearest evidence is Moonshot's own pricing. K3 lists at $3 per million cache-miss input tokens and $15 per million output tokens; K2.6 sat near $0.95 and $4. The open-weight model is roughly three to four times dearer than the closed-ish predecessor it succeeds. Frontier capability costs what it costs to serve, and publishing the weights does not change the arithmetic of serving them. The one genuine discount is structural rather than competitive: cache-hit input at $0.30 is a 90% reduction, which for an agent re-sending a mostly-stable transcript is the line item worth engineering around. Prompt caching is doing more for your bill here than the license is.
It does not mean local
At MXFP4 the weights are roughly 1.4 TB — against about 5.6 TB at FP16, so the quantisation is doing real work, and because it is quantisation-aware from the fine-tuning stage onward it is the intended precision rather than a lossy compression of some truer model. It is still 1.4 TB. No single H100, H200 or B200 holds it. Distributed inference is not an optimisation here, it is the only mode. Moonshot points production users at supernode configurations of 64 or more accelerators; community self-hosting guides land around eight H100s as a floor and sixteen across two NVLink-connected nodes to run at full speed with the full context window.
"Free to download" and "runs on your hardware" are different sentences. If what you wanted was a model on a machine you own, small and local models remain the answer, and K3 is not in that category — it is a datacentre model whose weights happen to be public.
It does mean nobody else's policy applies
This is the claim that survives, and it is worth more than it sounds. Run K3 on your own cluster and there is no rate limit imposed from outside, no deprecation notice retiring the model under your production traffic, no prompts leaving your boundary, and no refusal behaviour you did not choose. For regulated deployments that is the difference between a workable architecture and an unworkable one — see data residency and sovereignty.
The case for policy independence just got concrete
Until recently the argument for self-hosting a frontier open-weight model was mostly hypothetical for teams outside regulated industries. This month supplied a specific, load-bearing example.
When Hugging Face reconstructed the intrusion described in our write-up of the ExploitGym incident, its responders wanted to point language models at more than 17,000 recorded attacker actions. Commercial frontier models refused: to a safety classifier, close analysis of offensive tradecraft looks much like producing it. The forensics were completed on a self-hosted open-weight model instead, turning what is normally days of work into hours.
Generalise past security. Any workload sitting near a refusal boundary — abuse investigation, content moderation policy work, medical or legal drafting, adversarial red-teaming of your own agent — is a workload where a vendor's judgment about your request can stop your production system on a Tuesday, with no bug to fix and no appeal. That risk does not show up in a benchmark or a price comparison. It shows up once, at the worst moment. A self-hosted frontier model is insurance against it, and until this release, insurance at that capability level was not purchasable.
One caveat worth stating plainly: the same property that makes an unrestricted self-hosted model useful to defenders makes it useful to attackers, and that symmetry is real. It is an argument for knowing which of your workloads genuinely need it, not for pretending the trade-off is free.
When to pick which
| Situation | Rent K3 hosted | Self-host K3 | Stay on a closed API |
|---|---|---|---|
| Evaluating whether it fits at all | Yes — start here always | No | Keep as the baseline to beat |
| Bursty or low volume | Yes | No — idle accelerators dominate | Fine |
| Sustained high volume | Compare against amortised cluster cost | Where it starts to pay back | Compare on total, not per-token |
| Data cannot leave your boundary | No | Yes — the reason to do it | No |
| Workload sits near a refusal boundary | No | Yes | No |
| Frontier reasoning is the deciding factor | Near-frontier, not top | Near-frontier, not top | Still ahead per Moonshot's own comparison |
The practical shape for most teams is not a choice but a split. Rent K3 to find out whether its agentic strengths hold on your traffic; keep a closed frontier model for the hardest reasoning steps; run something small and local for the high-volume narrow steps where capability is not the constraint. That is model routing, and an open-weight frontier model makes it a more interesting problem, not a solved one.
Two things to check before committing. First, the licence: pre-release coverage did not settle the exact terms, so read the model card rather than assuming "open weights" means what it meant for the last release you looked at. Second, run your own evaluation. Every number in this post is someone else's benchmark, and reading benchmarks well mostly means remembering that a leaderboard position is evidence about a leaderboard.
FAQ
Can I run Kimi K3 on my own machine?
No, not in any ordinary sense. The MXFP4 weights are around 1.4 TB and no single H100, H200 or B200 can hold them. Community guides put the practical floor near eight H100-class GPUs, with Moonshot pointing production deployments at 64 or more accelerators. It is a datacentre model with public weights.
Is Kimi K3 cheaper than closed frontier models?
Not automatically, and it is not even cheaper than its own predecessor — K3 lists at $3 and $15 per million input and output tokens against roughly $0.95 and $4 for K2.6. Whether it beats a given closed model depends on that model's pricing and on how many tokens each takes to finish your task, which is a per-workload measurement rather than a table lookup.
What does open weights actually buy me, then?
Independence from another company's operational decisions: no external rate limits, no deprecation of the model under your traffic, no data leaving your boundary, and no refusal policy you did not choose. If none of those constrain you today, the honest answer is that hosted access to a closed model is simpler and probably better.
Is it good enough to replace my current agent model?
On agentic benchmarks it is close to the top and ahead of GPT-5.6 Sol Max on at least one long-horizon suite, while Moonshot itself says K3 trails Claude Fable 5 and GPT-5.6 Sol overall. "Close to the frontier and downloadable" is the accurate summary. Whether close is enough is a question about your task's error tolerance, and the only way to answer it is to run your own evals.
Does the million-token context mean I can stop managing context?
No. A larger window changes what you are able to do, not what you should do — attention quality degrades across very long contexts, and every token you keep is re-sent and re-paid on every subsequent step. The window is a ceiling, not a strategy.
Further reading
On this wiki:
- Open vs Closed Models — the trade space this release moves, but does not settle.
- Small and Local Models — what "runs on my hardware" actually looks like.
- Model Routing — how to use more than one of these at once.
- Agent Cost Control — why transcript growth, not list price, decides an agent's bill.
- Distillation and Quantization — what MXFP4 is doing to those 2.8 trillion parameters.
- Data Residency and Sovereignty — the constraint that makes self-hosting non-negotiable for some teams.
- The ExploitGym Incident — where the policy-independence argument stopped being hypothetical.