Moonshot AI's Kimi K3 is the biggest open-weight release ever announced: 2.8 trillion parameters, a 1 million token context window, and open weights that dropped July 27 as promised. The benchmark numbers are getting most of the coverage. The infrastructure math is not. Before you restructure an agent pipeline around K3, those two things are worth separating.
What Kimi K3 actually is
Kimi K3 is a 2.8T parameter MoE model built on Kimi Delta Attention and Attention Residuals, activating 16 of 896 experts per token (104B active). It ships with a 1M token context window, native multimodal input, and a technical report claiming roughly 2.5x better scaling efficiency than Kimi K2.
Moonshot calls it the first open-weight model in the 3-trillion-parameter class, and it is aimed squarely at frontier coding and agent work rather than at being a cheap alternative. That framing matters because the positioning is different from every Chinese open-weight release before it. DeepSeek won on price. Kimi K3 is not trying to.
On the independent Artificial Analysis Intelligence Index v4.1, Kimi K3 scored 57.1, landing as the #4 tested configuration and effectively the #3 model family, close behind GPT-5.6 Sol Max at 58.9 and Claude Fable 5 (with an Opus 4.8 fallback) at 59.9.
It ranks first of 99 models on WebDev Arena at 1,678 Elo, the first open model ever to top that leaderboard. That is the number that sticks out: no open-weight model has done this before.
Moonshot's unusually honest stance: the company openly admits overall performance still trails Fable 5 and GPT-5.6 Sol, and lists known weaknesses - sensitivity to harness-returned reasoning content, over-eagerness on ambiguous intent. That kind of disclosure is rarer than it should be.
What "open weights" costs to run
This is where coverage gets thin. The word "open" implies accessible. The infrastructure implies otherwise.
Kimi K3 requires roughly 1.5 TB of RAM to run inference - about 1.4 TB for weights alone at native MXFP4 4-bit precision. Running it demands at minimum 8x next-gen GPUs (NVIDIA B300 or AMD MI350X) capable of native FP4 execution, since older Hopper/MI300X hardware dequantizes at runtime and loses the speed benefits.
Kimi K3 uses a Mixture-of-Experts architecture with 896 experts. During inference, only 16 experts are active per token. But all 896 experts must be loaded into memory simultaneously. That is the critical detail MoE coverage usually skips. Sparse activation is a compute saving during inference, not a memory saving during serving.
The cost math shows self-hosting on rented GPUs runs $38/hr ($27,800/month), making serverless inference far cheaper for most teams unless they sustain 40+ heavy concurrent users generating 50M+ tokens/month.
At $25,000/month self-hosting cost, you would need to process roughly 1.5 billion tokens per month just to break even with the API. For most organizations, the API is dramatically cheaper.
The API, priced at $2.55 per million input tokens, $12.75 per million output tokens on OpenRouter , lands well below what self-hosting costs at normal enterprise volumes. Artificial Analysis measured a per-task cost of $0.94: 9.4% below GPT-5.6 Sol and 65.8% below Claude Fable 5. Coding workloads reportedly hit cache rates above 90%, so real bills sit far below sticker price.
The license is not plain MIT
What most of the coverage is getting wrong, or simply not checking, is the license attached to those weights. It is not the "Modified MIT" license that shipped with Kimi K2. It is a new document with a specific commercial threshold, and that difference matters more than another benchmark chart.
Free for commercial use with attribution; extra conditions only apply at very large scale. The exact threshold is in the license document on Hugging Face - read it before you plan a model-as-a-service product around K3.
The full weights went public on July 27, 2026 under the bespoke Kimi K3 License, making it open-weight but not OSI open source. The distinction matters if your organization has a policy that requires an OSI-approved license. GLM-5.2 is MIT. Kimi K3 is not. For many teams, that is a legal review, not a technical one.
There is also the vendor-risk question that runs across all top open-weight models right now. The current open-weight top tier comes almost entirely from Chinese labs - DeepSeek, Zhipu (GLM), Moonshot (Kimi), Alibaba (Qwen), and MiniMax - with Meta and Mistral behind on the live ranking. That concentration is a real risk factor for teams with data residency requirements or federal compliance obligations, regardless of how good the benchmarks are.
Where Kimi K3 fits in an agent stack
The 1 million token context window is the most practically useful number here. Most agent frameworks are bumping into context limits on large codebase tasks, long document pipelines, or multi-turn sessions that accumulate history. K3 is particularly strong at navigating large repositories, using tools, debugging, and iterating against images, logs, tests, and runtime feedback.
That is a specific fit: agents that need to hold an entire repo in context, or process a long incident log alongside code, or reason over many turns without pruning history. For single-turn, short-context tasks, the context window is irrelevant and a smaller model is cheaper.
A comparison against the other serious open-weight coding options right now:
| Model | Terminal-Bench 2.1 | SWE-bench | License | Context |
|---|---|---|---|---|
| Kimi K3 | 88.3 | - | Kimi K3 License | 1M |
| DeepSeek V4 Pro | 82.7 | 80.6% Verified | MIT | 1M |
| GLM-5.2 | 81.0 | 62.1% Pro | MIT | 1M |
| DeepSeek V4 Flash | ~78 | - | MIT | 1M |
Moonshot reported 88.3 on Terminal-Bench 2.1, putting K3 very close to top closed models in the same category. Public benchmark comparisons placed GPT-5.6 Sol at 88.8 and Claude Fable 5 around 84.6.
DeepSeek V4 Flash is the first open-weight model that teams immediately dropped into real agentic pipelines as a plausible substitute for an Anthropic- or OpenAI-class frontier model. The larger V4 Pro variant set the ceiling with a score of 80.6% on SWE-bench Verified, the top open-weights score.
K3 leads on the overall intelligence index. DeepSeek V4 Pro leads on SWE-bench, which is a more specific coding-task signal. GLM-5.2 wins on license permissiveness. The right pick depends on which of those axes matters most to your stack.
Kimi K3 open weights: common questions
Is Kimi K3 actually open source?
No. Kimi K3 is open-weight: the full weights went public on July 27, 2026 under the bespoke Kimi K3 License, making it open-weight but not OSI open source. Training code and data are not released. The license permits commercial use with attribution but adds conditions at large scale - read the full document before building a model-as-a-service product.
How good are the Kimi K3 benchmarks, really?
Better verified than most. Unlike most frontier launches, this one already has real third-party benchmark data behind it.
On the independent Artificial Analysis Intelligence Index v4.1, Kimi K3 scored 57.1, landing as the #4 tested configuration and effectively the #3 model family. The caveat: each model used its own inference harness; independent third-party reproduction is ongoing.
Can you run Kimi K3 on a single GPU node?
No. The public weight repository is about 1.56 TB and the official vLLM recipe starts at 8 NVIDIA GB300 GPUs or 8 AMD MI355X/MI350X GPUs. Moonshot recommends 64 or more accelerators in a supernode configuration for efficient production inference. Consumer hardware and most cloud workstations are ruled out by memory alone.
What does Kimi K3 API access actually cost?
Artificial Analysis measured a per-task cost of $0.94: 9.4% below GPT-5.6 Sol and 65.8% below Claude Fable 5.
K3 pricing deliberately aligns with Western frontier tiers - a quality play, not a race to the bottom. It is the highest API pricing among Chinese LLM vendors, yet still well below Claude Opus 4.8 per-task cost.
When does self-hosting Kimi K3 make economic sense?
Rarely, for most teams.
The cost math shows self-hosting on rented GPUs runs $38/hr ($27,800/month), making serverless inference far cheaper for most teams unless they sustain 40+ heavy concurrent users generating 50M+ tokens/month.
The cases where self-hosting wins: hard data residency requirements, sustained volume above the API break-even, and an existing distributed inference team.