Kimi K3 Review (2026): The Biggest Open-Weights Model — and What It Really Costs

Moonshot AI published 1.56 terabytes of frontier-class weights that almost nobody can serve. That is not a footnote to the launch; for most readers it is the whole story.

By AI Tool Scout · Published October 15, 2026 · 20 min read

What Is Kimi K3?

Kimi K3 (kimi-k3) is the 2026 flagship of Moonshot AI, the Beijing lab behind the Kimi assistant and the K2 family. Moonshot opened the API, the Kimi app, Kimi Work and the Kimi Code CLI on July 16, 2026, promising the full weights within eleven days. It delivered on July 27, 2026: a single repository, moonshotai/Kimi-K3, holding 96 safetensors shards totalling 1,561,018,243,668 bytes — about 1.56 TB, the largest open-weights checkpoint ever published, and the first open model in the three-trillion-parameter class. Moonshot describes it as an open-weight, native multimodal agentic model built for long-horizon coding, knowledge work and reasoning. The technical report (arXiv 2607.24653) frames the whole release as a scaling-efficiency result rather than a brute-force one: roughly 2.5× better scaling efficiency than Kimi K2, credited to three architectural bets rather than to parameter count alone.

The context that matters is what K3 replaced and who it beat. Kimi K2.6, released in April 2026, was a 1T-class model at 256K context scoring 44 on the then-current index. K3 more than doubled the parameter count, quadrupled the context window, and added native vision. The previous largest open-weights release had been DeepSeek V4 Pro at 1.6T parameters, with Zhipu's GLM-5 series at 744B — K3 added roughly 1.2 trillion parameters to the open field in one drop. Within weeks it had landed in GitHub Copilot (August 6, 2026) and on Amazon Web Services (September 21, 2026), and Reuters reported Moonshot in talks with Microsoft and Google about hosting K3 while seeking up to a 30% revenue share — negotiations reportedly still open on data access and token-usage auditing. For how K3's economics sit against the wider API market, see our LLM API cost guide.

Key Features: Sparsity, a Million Tokens, and a Format You Cannot Ignore

Four things carry the K3 story, and each one has a bill attached.

• 2.8T parameters with 104B active — the largest expert pool ever shipped openly. K3 is a sparse Mixture-of-Experts model with 896 routed experts of which 16 fire per token, plus 2 shared experts. That is about 1.8% of the pool active on any token. Across 93 layers there is exactly one dense layer; the other 92 are split 69 Kimi Delta Attention (KDA) + 24 Gated MLA, running roughly three recurrent layers to every global one and ending on a global layer. Moonshot credits the sparsity to a Stable LatentMoE framework with Quantile Balancing (router-score quantiles instead of an auxiliary loss), a SiTU-GLU activation and a Per-Head Muon optimiser — all engineering for the problem of balancing 896 experts without destabilising training. Sparsity is what makes the model fast to serve. It does nothing to make it small.
• A 1,048,576-token context with sub-linear KV growth. KDA is a hybrid linear-attention mechanism with a fixed-size recurrent state, so the KV cache does not grow the way a dense-attention model's would. The practical consequence is startling: one user at the full 1M window costs roughly 29.5 GB of KV cache on a 2.8T model, and about 0.7 GB at 8K. Moonshot claims 6.3× faster decoding at million-token contexts. A vanilla transformer of this size at 1M context would need hundreds of gigabytes per user, which is why K3's 1M window is a real feature rather than a marketing number — and why the weights, not the cache, dominate the memory bill at every context length.
• Native multimodality, not an adapter. Vision is built in from the ground up via a 401-million-parameter MoonViT-V2 encoder rather than bolted on. On Moonshot's own card K3 scores 91.1 on OmniDocBench (document parsing), 90.0 on Video-MME with subtitles, 81.6 / 83.4 on MMMU-Pro and 94.3 / 97.8 on MathVision (without and with Python, in that order). Artificial Analysis places it first of 54 eligible models for multimodal and grounded tasks on the BenchAlign cut, at 92.6 out of 100 — the single category where K3 is unambiguously world-leading.
• Native MXFP4 — quantisation-aware from the SFT stage, not post-hoc compression. K3 ships in microscaling FP4 weights with MXFP8 activations, and it learned to compensate for quantisation error during training rather than being squeezed afterwards. That is the good news: the 4-bit build is the model, and it is natively supported by NVIDIA Blackwell and AMD MI400-class accelerators. The bad news is the arithmetic that follows from it: 2.8 trillion parameters at half a byte each is about 1.4 TB before anything else is added, and the published repository measures 1.56 TB. In 16-bit precision the same weights would be roughly 5.6 TB. MXFP4 did not make K3 small; it made K3 merely enormous instead of impossible.

Two operational details matter more than they look. K3 always has thinking enabled and returns reasoning_content; reasoning_effort accepts low, high and max with max as the default. And K3 was trained in preserved thinking history mode: for multi-turn conversations and tool calls you must send the complete assistant message back verbatim, including reasoning_content and tool_calls, not just the visible answer. That is an integration footgun and a cost multiplier at the same time — every prior turn of hidden reasoning re-enters your input bill unless cache hits absorb it. Moonshot maintains day-zero recipes for vLLM, SGLang and TokenSpeed and recommends Kimi Code CLI as K3's agent harness.

Benchmarks: Open Versus Closed, and the Number That Moved

There are three K3 stories in circulation and they do not agree: Moonshot's own table, the independent evaluators, and the small number of third parties who have run it in anger. Here is each, with the caveats attached.

What Moonshot's own table says

The model card reports 33 public rows at maximum reasoning effort. Against Claude Fable 5, GPT-5.6 Sol, Claude Opus 4.8, GPT-5.5 and GLM-5.2, K3 is first or tied-first on a substantial minority of them and always competitive on coding and agentic work. The rows that matter most:

Three disclosures change how you read that table, and Moonshot publishes all three. First, the harnesses differ by design: K3 is evaluated on Moonshot's own Kimi Code harness while Claude Opus 4.8 and Fable 5 run Terminus 2, GPT-5.5 and Sol run Codex, and GLM-5.2 runs Claude Code. An agentic score is a score for a model plus its scaffold, so the two-point gaps on Terminal-Bench are inside harness noise. Second, SWE-bench Verified is absent from the card entirely — the most-quoted agentic coding number in the industry does not appear. K3 does show up on the official DeepSWE leaderboard at 67.3 under the mini-SWE-agent harness, close to its self-reported 67.5, but that is a different benchmark from the one Anthropic and OpenAI lead with. Third, several of the model's margins erode on independent re-runs: on Vals AI's own leaderboards K3 records 87.2% on LiveCodeBench against Fable 5.1's 90.5%, 80.9% on Terminal-Bench 2.1 against GPT-6 Astra's 87.3%, and 92.9% on GPQA Diamond against Gemini 3.1 Pro's 95.5%.

The independent index — and why "highest open-weights score" has an expiry date

This is the part most reviews written in July will get wrong today. K3's position on the Artificial Analysis Intelligence Index has moved three times, because Artificial Analysis has re-cut the index and the field kept shipping.

• July 2026, Intelligence Index v4.1: K3 scores 57, third globally. Behind Claude Fable 5 at 60 and GPT-5.6 Sol at 59, ahead of Claude Opus 4.8 at 56. Ten points above its own predecessor. Cost per index task at that snapshot: $0.94, versus $1.80 for Opus 4.8 and $2.75 for Fable 5 — the cheapest way to buy that much intelligence at the time.
• Next revision: K3 reaches 60 — the highest score any open-weights model had recorded. It held that position for weeks, until GLM-5.3 tied it at 60 on August 18, 2026 (and, per GLM's publisher, on the same base model with no retrain). This is the number most secondary coverage still quotes. It was accurate. It is not current.
• The index in force now, v4.3.2: K3 scores 44 and is no longer first among open weights. The current composite weights ten evaluations toward agentic and knowledge work — AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, Humanity's Last Exam, GDP.pdf, CritPt, AA-Omniscience and AA-LCR. On it, Xiaomi's MiMo-V2.6-Pro scores 46 (a 1.02T / 42B-active MoE released under the permissive MIT licence) and GLM-5.3 scores 45. K3 sits third. Claude Opus 5.5 tops the whole board at 58, first of 211 models. Behind K3 in the open field: GLM-5.3 Flash at 42, Qwen3.8 2.4T-A95B at 40, DeepSeek V4 Pro 0813 at 36.

Two consequences fall out. The open-versus-closed gap is 12 points and widening — it was 7 when the proprietary leaders stood at 53. And K3 is now expensive relative to its peers, not cheap: Artificial Analysis explicitly calls it "particularly expensive when comparing to other open weight models of similar size," at $3.00 input and $15.00 output per million against open-weights medians of $0.30 and $1.18. The cost per index task comparison is brutal — about $2.00 per task for K3 against $0.13 for MiMo-V2.6-Pro, and $1.82 for Claude Opus 5.5 at its high effort setting while scoring 54, ten points more than K3's 44. K3's speed is also a real cost: 35 to 41 output tokens per second against a median near 65 to 75 for open-weights models of comparable size, with a time to first token of 3.25 to 4.18 seconds. Where it still wins on cost is the like-for-like against Sol: both score 44, K3 blends at $2.31 per million against Sol's $3.08, and K3 starts answering in 4.08 seconds against Sol's 38.11 — but Sol generates at 68.7 tokens per second against K3's 36.7.

Where K3 is genuinely strong, and where it is not

• Costed honestly, K3's profile is "long-horizon and multimodal," not "smartest." Epoch AI's independent Capabilities Index puts it at ECI 157, 15th of 257 tracked models — it was 8th of 232 at release. Its best independent cuts are sustained coding sessions (SWE-Marathon, Program Bench) and multimodal grounding, where it ranks first of 54.
• As a coding agent in its own harness it is mid-field. Artificial Analysis's Coding Agent Index scores K3 running in Kimi Code CLI at 57, against 68 for Claude Code on Sonnet 5.5, 68 for Muse Wonder Full, 66 for Claude Code on Opus 5.5 and 63 for Muse Wonder, at an average of $3.18 per task. Component scores: 84% on Terminal-Bench v2, 64% on DeepSWE, 23% on SWE-Atlas-QnA.
• Cyber capability is a weak spot, measured by governments. A joint preliminary assessment by NIST CAISI and the UK AI Safety Institute recorded 32% on ExploitBench v8-bench against GPT-6 Astra's 100%, 0% solved on the ACE Cyber Range challenges, and 17% average progress on The Last Ones. Whether you read that as reassuring or disqualifying depends on which side of a red team you sit on, but it is the kind of disclosure most vendors do not volunteer.
• A frontier-adjacent model with a frontier-adjacent bill. Moonshot's own launch coverage in Tom's Hardware framed it fairly: K3 still sits behind Claude Fable 5 and GPT-5.6 Sol on overall performance while outperforming every other model in the company's suite. That is a good honest summary, and it was written in July, when K3 was third on the index and the leader among open weights.

Pricing and the Real Cost of Self-Hosting

This is the section the open-weights headline usually skips. Every figure below is approximate, in US dollars, checked on October 15, 2026 against Moonshot's own API pricing documentation, the Kimi membership help centre, the Hugging Face repository metadata, vLLM's published deployment guidance, Moonshot's production recommendation and third-party hosting and hardware-cost analyses. Confirm current pricing on the vendor's own pages before you build or subscribe — Moonshot has changed consumer plan availability more than once, and GPU rental rates move weekly.

The hardware bill: what 1.56 TB actually buys you

Start with the floor. The published weights are 1,561 GB across 96 shards. Add KV cache, activation buffers and roughly 15% runtime overhead and a real deployment needs about 1.7 TB of usable GPU memory at short context, rising to about 1.84 TB at the full 1M window. Weights are more than 85% of that at every context length, which is why "I'll just use a shorter context" does not rescue an undersized node.

vLLM's day-zero minimum is a single node of eight B300 or eight MI355X accelerators; 16× B200 is also supported; Moonshot's own production recommendation is a supernode of 64 or more. The 8-GPU minimum gets the model running, not running at production throughput. Note the Hopper caveat: 32× H100 will technically load the checkpoint, but Hopper cannot execute MXFP4 natively, so you keep the memory savings and lose the speed advantage the format exists to provide.

Then the money, in three shapes:

• Rent. A single eight-GPU node runs roughly $21,600 to $83,200 a month depending on provider, at published 2026 on-demand rates — $21,600 at a neo-cloud low end for 8× B200, $30,900 at Lambda, $36,900 at CoreWeave for 8× H200, and $83,200 on AWS on-demand. Sixteen H200s at AWS's published $5.97 per GPU-hour is about $69,730 a month; 64 H200s is about $278,918 a month, and 64 B200s at Together's $8.19 is about $382,637. The node bills whether you send one token or a billion, and 40% utilisation is 60% waste.
• Buy. An OEM-configured eight-B300 server is about $575,245 with a 15.575 kW maximum draw. Add 15% for fabric, storage, racking and installation, amortise over 36 months, apply a 1.3 power-usage-effectiveness factor at $0.12/kWh, and budget $20,000 a month of platform labour for a cluster that size, and the modelled all-in monthly cost is $40,149.56 — before a spare node. The 16× B200 two-node equivalent is $790,097 of hardware and $48,479.55 a month; 64× B200 is $3,160,388 and $143,918.20 a month; a 64-GPU NVL72-class rack with colocation, power and 1–2 engineers is $135,000–$175,000 a month.
• Break even. This is the only number that actually decides it. Against Moonshot's rate card at the blended $2.31 per million, the purchased 8× B300 model needs roughly 17.4 billion tokens a month to match what the API would have charged. Rent instead, and a single 8× H200 node needs roughly 1.55 to 2.46 billion output tokens a month — call it 2 billion — before self-hosting is the cheaper option. For scale: a heavy individual user running K3 through the API spends single-digit dollars a day, and self-hosting for one person is 100 to 1,000 times more expensive than the API. Most teams are more than an order of magnitude below the crossover.

And the cost that never makes it into the table: multi-node MoE serving is a genuinely hard operations problem — expert-parallel sharding, all-to-all traffic over InfiniBand or RoCE, KDA-aware prefix caching, and failure domains that cross nodes. Someone has to own the pager. If you want K3 on your own terms without buying a datacenter, the realistic middle path is a hosted endpoint you control the client for — Featherless serves it through an OpenAI-compatible API, and so do Fireworks, DeepInfra, Together and Bedrock — or a dedicated deployment at the 1M context you actually need.

What About Kimi K3.1?

As of October 15, 2026, K3.1 has not shipped. The rumour is specific enough to take seriously and thin enough that you should not plan around it.

• What is credible. A Nomura Securities report covered on October 10, 2026 says Moonshot plans to release Kimi K3.1 before mid-October, focused on an agent's ability to keep completing long-duration tasks, and refined through post-training on computer-operation trajectories and real-world task data. The same report says the lab is training a 5 to 6 trillion parameter model, nearly double K3, that the bottleneck is high-end training compute, and that training progress is undisclosed. Several outlets read the 5–6T project as the rumoured Kimi K4 rather than K3.1.
• What the leak trail shows. Around September 23, identifiers such as k3d1-agent were spotted in captured internal API responses. Around September 28, a kimi-k3-1 entry appeared in Moonshot's backend model registry and passed interface probes, and a preview page went up the same night under the codename K311111 listing a 1M-token context. The leaked configuration implies three reasoning tiers, a native Agent mode, Swarm multi-agent collaboration, and search and batch task modes, with API pricing listed identically to K3 — almost certainly a placeholder.
• What argues against an imminent launch. An independent catalogue audit on October 13 found no K3.1 identifier in Moonshot's public model list (which enumerates kimi-k3, kimi-k2.7-code, kimi-k2.7-code-highspeed and kimi-k2.6), no repository under the lab's Hugging Face organisation, and no rate-card row. It also points out that the "3.1" in Moonshot's own K3 material refers to Kimi Work desktop app version 3.1.0 — an ordinary product version that sits next to a model name in a launch document, which is exactly the kind of adjacency that becomes a search term. And part of the leak describes what K3 already ships: reasoning_effort accepts low, high and max on the model available today.

Our read: treat K3.1 as expected but unconfirmed. The right signal is an artefact — a model-list row, an API identifier, or a repository under Moonshot's own organisation — not a screenshot. Two practical consequences if you are planning now: do not delay a K3 build waiting for a successor, because the API surface and pricing are unlikely to change much if the leaked placeholder holds; and do not assume K3.1 will be open-weighted on the same schedule, because Moonshot has already shown with the 5–6T project that compute, not policy, is its stated constraint.

Pros & Cons

5 Best Kimi K3 Alternatives

Comparison Table

All prices are approximate, in US dollars, checked October 15, 2026, and change often. Confirm on each vendor's own pricing page. DeepSeek rates are off-peak and double during peak hours. Where a cached-input rate is shown as a dash, the vendor does not publish a headline cache discount on that model.

Which One Should You Choose?

• Use the Kimi API if you want K3, and do not plan to self-host. At roughly $3 / $0.30 / $15 per million with a 90% cache discount and a flat 1M context, it is a legitimately priced frontier-adjacent model. Drive cache hit rates up before anything else — that single lever is a 4× difference in effective input cost.
• Model your unit economics before you build on it. K3 generates slowly (35–41 tokens per second) and verbosely, and preserved thinking history means every prior turn's hidden reasoning re-enters the input bill. If your workflow does not produce cache hits, the effective price is much closer to $3 and $15 than the blended $2.31 suggests. Compare against the DeepSeek and Qwen cards before you commit.
• Do not self-host unless you are past roughly 2 billion output tokens a month on a rented node. Below that the API wins on cost, effort and redundancy, and you are also buying yourself an expert-parallel MoE operations problem and someone who owns the pager. Rent a dedicated node first if data residency forces your hand, and buy hardware only after a production-shaped load test.
• Take the $39 Allegretto tier if you are an individual user. It is the first membership that unlocks the full 1M context, and at $39 a month it is cheaper than a single day of the smallest self-hosted node. Only pay for Allegro or Vivace if you genuinely burn 360 or 720 agent credits.
• Choose MiMo-V2.6-Pro or DeepSeek if "open weights" is your actual requirement. Xiaomi's model is the current index leader under a clean MIT licence; DeepSeek's V4.1-Flash is roughly 1/25th the output price and considerably better on office automation. Both are downloadable in a sense that means something.
• Choose Claude Opus 5.5 if you want the frontier and the money is the same. At $4/$20, and at $1.82 per index task at high effort while scoring ten points above K3, it is the more capable purchase for most coding and knowledge work. Read the Claude review and the Gemini 4 Argon review before you assume a closed model costs more.
• Do not wait for K3.1. There is no model card, no repository and no API identifier as of October 15, 2026, and part of what leaked describes features K3 already ships. Build on the model that exists and revisit when an artefact appears.

Frequently Asked Questions