The Moonshot Kimi Family Explained: K2.6 and K3

Moonshot ships models under one name that behave nothing alike. Assuming that "Kimi" describes a consistent set of capabilities is the most common mistake teams make when planning around the family, and it usually surfaces as a context-length surprise in production.

Two models matter in August 2026: Kimi K2.6, released 20 April, and Kimi K3, released 16 July. They differ on almost every axis that affects an architecture decision.

Kimi K2.6: the efficient generalist

K2.6 is a mixture-of-experts model with roughly 1T total parameters and 32B active per token. It uses 384 experts, of which 8 are routed and 1 is shared, and multi-head latent attention. It ships a 256K context window and is vision-language capable.

The 32B active figure is the one to hold onto. It places K2.6 in the same computational neighbourhood as much smaller-sounding models while retaining the knowledge capacity of a trillion-parameter store, which is the entire point of the architecture. Pricing lands around $0.95 per million input tokens and $4.00 output.

The shared expert is a design detail with practical consequences. One expert processes every token regardless of routing, which gives the model a stable base of general capability underneath whatever the router selects — useful for consistency across heterogeneous inputs. How mixture-of-experts routing works covers the mechanism.

Kimi K3: the capability release

K3 is a substantially larger object: roughly 2.8T total parameters with 104B active per token, and a 1M context window. Weights were opened on 27 July, about eleven days after the model itself.

Its published results are the strongest in the open-weight field on agentic measures. It reports 88.3 on Terminal-Bench 2.1, 81.2 on FrontierSWE, an Artificial Analysis Intelligence Index around 57, and first place on Arena Frontend Code with 1,679. Pricing is $3 per million input and $15 output, with cached input at $0.30.

The 104B active count is the highest in the open-weight field and is the most plausible mechanical explanation for the agentic lead. Long tool-driven runs compound per-step reliability, and per-token reasoning depth is what per-step reliability is made of. The Kimi K3 guide goes deeper on where that shows up.

The context gap is the trap

K3 ships 1M context. K2.6 ships 256K. That is close to a four-fold difference inside the same product family, and it is the detail that breaks assumptions.

If you designed a pipeline around a million-token window on K3 and then routed to K2.6 for cost reasons, you do not get a graceful degradation — you get errors on any request that exceeds 256K. Anything that silently swaps between the two needs a length check at the boundary.

The inverse is also worth stating: 256K is a large window by any standard that existed two years ago, and most requests never approach it. The gap only matters if your workload genuinely produces very long inputs. Comparing context windows across the field covers what filling each one costs.

Licensing is where Moonshot differs from the rest

This is the part most comparisons get wrong. GLM-5.2 and both DeepSeek V4 variants ship under MIT, which is about as permissive as licensing gets. Kimi K3 and K2.6 do not.

Moonshot uses its own terms. For K3 specifically, the licence is custom and includes a revenue threshold that applies to offering the model as a service. Below that threshold the terms are broadly permissive; above it there are obligations that do not exist under MIT.

For internal use — running the model on your own infrastructure for your own engineering — this rarely bites. For anyone building a product whose value proposition is serving the model to customers, it is a term to read properly and probably to have someone else read too. "Open weights" and "open source" are not the same claim, and this family is the clearest illustration. The distinction between open weights and open source covers why the difference keeps causing trouble.

Weights, and who can actually run them

K3's weights are roughly 1.6TB. That number rules out single-node hosting for essentially everyone, and it means a multi-node deployment with fast interconnect, because tokens routed to experts on other nodes require communication across the fabric.

Open weights therefore buys you something narrower than it sounds for this model. It buys inspectability, the option to run it on rented cluster capacity, and insurance against a provider withdrawing access. It does not buy the ability to run it on the hardware most teams have.

K2.6 is smaller but still firmly a multi-accelerator model at 1T total. If your requirement is genuinely self-hosting on modest hardware, neither model in this family is the answer — dense models sized to one accelerator are.

Choosing between them

Take K3 when the work is agentic, long-horizon or long-context: multi-step coding agents, tasks where a mid-run mistake is expensive, inputs beyond 256K. You are paying roughly three times the input rate for the highest per-token reasoning depth available in open weights, and for agents that is usually the right trade.

Take K2.6 when the work is bounded and high-volume: classification, summarisation, single-turn generation, anything vision-language where 256K is comfortably enough. The price difference is large and compounds across volume.

If you are running both, cache aggressively on K3 — the $0.30 cached input rate is a tenth of the standard rate, and agent loops resend a stable prefix constantly. The head-to-head comparison works through the crossover in more detail.