Kimi K3.1: The Search-Box Name for Kimi K3, and What Moonshot Actually Ships

Type kimi k3.1 into a search box and you are not asking for news. There is no Kimi K3.1 model card, no weight repository, no rate-card row and no API identifier carrying that number anywhere on M​oonshot AI's own surfaces — and there is not going to be one until the lab puts it there. What the dot resolves to is the product it names in shorthand: Kimi K3, the 2.8-trillion-parameter open-weight flagship M​oonshot shipped on 16 July 2026, and the line it belongs to. "Kimi K3.1" is the spelling the search box prefers for that line; Kimi K3 is the spelling the vendor uses. The whole page below is about that difference, because it is the difference that decides what you can actually run.

The reason to write this down is demand rather than news. Over the twenty-eight days to 12 October 2026, queries built on the dotted spelling drew 777 impressions and 70 clicks on our own property — twelve queries, essentially no long tail, and a click-through rate of 9.7% on kimi k3.1 itself. That is the highest conversion of any facet measured in this round, and roughly double what the undotted spelling achieves. Readers who type the dot are not browsing. They have already read something about this line and they are coming back for it. Meanwhile kimi k3 carries 4,004 impressions across 189 queries, five times the dotted volume, and that is the number that tells you which of the two names is the product.

What "Kimi K3.1" refers to, in one screen

Three statements, in order, because the order matters:

• Kimi K3.1 is not a separate release. M​oonshot AI publishes one K3 model. Its documentation, its pricing page, its Hugging Face organisation and its blog all use the same name for it, and none of them uses a dotted suffix.

• Kimi K3 is the shipped model, and it is callable today. A 2.8T-parameter mixture-of-experts system with a 1,048,576-token context window, native image input, open weights under M​oonshot's own licence, and a published API rate of $3.00 per million input tokens and $15.00 per million output tokens.

• The dot is a label, not a version. It is the form the term takes in search and in community discussion, and it is also the form the line's rumoured successor has taken since July. Those are two different things sharing one spelling, and the rest of this page keeps them apart.

If you arrived here from a link about a leak, that is the other half of the story and there is a page for it — this one is the reference page for the name and the model behind it.

What Kimi K3 is, from M​oonshot's own card

Every figure in this section is read from M​oonshot's own material: the model card in the moonshotai/Kimi-K3 repository on Hugging Face, the technical blog at kimi.com/blog/kimi-k3, and the model documentation on the lab's API platform. They are vendor-stated numbers, not independently reproduced ones, and the distinction is worth keeping because K3 is a large sparse model where benchmark claims and serving claims are made by the party that trained it.

• Class — a mixture-of-experts language model with vision, described by M​oonshot as the world's first open model in the 3-trillion-parameter class.

• Size — 2.8T total parameters with 104B activated per token, across 896 routed experts of which 16 fire per token, plus 2 shared experts. 93 layers, one of them dense.

• Architecture — Kimi Delta Attention (KDA) and Attention Residuals, with 69 KDA layers and 24 gated MLA layers, an attention hidden dimension of 7,168 and 96 attention heads. M​oonshot reports roughly 2.5× the scaling efficiency of Kimi K2 from the combination.

• Context — 1,048,576 tokens, which is the same figure the API pricing page quotes for the model.

• Modality — text and image in, text out. The vision encoder is MoonViT-V2 at 401M parameters, and the vocabulary is 160K.

• Numerics — quantisation-aware training from the supervised fine-tuning stage onward, with MXFP4 weights and MXFP8 activations, which M​oonshot frames as broad hardware compatibility.

• Reasoning controls — thinking is always on, and depth is set with a top-level reasoning_effort field taking low, high or max, defaulting to max.

• Price, vendor-published — $3.00 per million input tokens, $15.00 per million output tokens, $0.30 per million cached-input reads, with cache writes billed at $3.00 per million at the 5-minute retention tier and $6.00 per million at the one-hour tier.

One line of that list deserves to be pulled out, because it is the part of K3 that most often gets lost in the parameter count: the model does not let you set its sampling parameters. M​oonshot's parameter reference marks temperature fixed at 1.0, top_p fixed at 0.95, n fixed at 1 and both penalties fixed at 0, and states that passing any other value returns an error — so the advice is not to send them at all. Depth is the only dial, through reasoning_effort, and the same page carries a warning worth knowing before you build: changing effort level mid-conversation invalidates prefix-cache hits, so the level is best decided when the session starts.

Does M​oonshot ship anything called 3.1?

This is the question the reader who typed the dot is actually asking, and it has a checkable answer rather than an opinion. Every surface below was read on 13 October 2026, and a reader can repeat all of them in an afternoon.

• The model list on M​oonshot's API platform enumerates four callable models: kimi-k3, kimi-k2.7-code, kimi-k2.7-code-highspeed and kimi-k2.6. There is no K3.1 entry, and the same page marks thirteen earlier identifiers as deprecated instead.

• The pricing page has one K3-series row. It is kimi-k3, at the rates quoted above, with a 1,048,576-token context window. There is no second row to price.

• The documentation index the platform publishes for automated readers lists three K3-specific guides — the quickstart, a tool-calling best-practice page and an agent-setup page — and nothing numbered 3.1.

• The lab's Hugging Face organisation holds exactly one K3 repository, moonshotai/Kimi-K3, and a search of the Hub for a repository numbered 3.1 returns nothing under any spelling.

• The research index at kimi.com lists K3 among the lab's published work with a single entry. There is no second K3 entry above it.

So where does 3.1 come from? Two places, and neither is a model version. The first is that the number 3.1 does appear in M​oonshot's own K3 launch material — as the version of the Kimi Work desktop app you need to run K3 on a Mac or a Windows machine, which the blog states as "version 3.1.0 or later". A product version, published by the lab, in a document about K3, is an entirely ordinary thing to find next to a model name, and it is the kind of adjacency that turns into a search term. The second is the leak lineage: the name Kimi K3.1 has been attached to a rumoured successor since July, has been read into a cryptic vendor post in September, and has been claimed for an autumn window by a leaker whose previous timeline for the same model lapsed. That history is documented on our leak page and is not repeated here.

What no source does is distinguish a Kimi K3.1 from Kimi K3 on any technical axis. There is no changelog, no side-by-side, no "what's new in 3.1", because there are not two things to compare. That is the finding, and it is worth stating plainly rather than dressing up: if a page shows you a specification table comparing K3 with K3.1, at least one column of it was invented.

Weights, licence, and how to run it

K3's weights are open, and the terms are M​oonshot's own rather than an off-the-shelf licence — a distinction that matters more than the headline word "open". The repository declares license: other with license_name: kimi-k3, and the text grants use, copying, modification, merging, publication, distribution, sublicensing and sale, including the right to fine-tune and to build derivative works. Two conditions sit on top of that grant, and both are commercial rather than technical:

• If you run a model-as-a-service business — giving third parties API-style access with meaningful control over inputs, parameters or training data — and your aggregate revenue across any consecutive twelve months exceeds $20 million, you need a separate agreement with M​oonshot before using the weights or derivatives commercially.

• If a commercial product or service built on the weights passes 100 million monthly active users or $20 million in monthly revenue, "Kimi K3" must be displayed prominently in its interface.

• Neither condition applies to internal use, or to anything reached through M​oonshot's own products or its certified inference partners.

The download itself is not small, and it is worth knowing the shape before you start one. The repository carries 97 safetensors shards totalling roughly 1.56 TB, published in the MXFP4/MXFP8 configuration the model was trained to use — which is a real convenience, because it means the lab's own quantisation is the reference rather than something you have to reproduce. M​oonshot names three inference engines it recommends for K3: vLLM, SGLang and TokenSpeed, each with a published recipe or cookbook. The vendor's own deployment note adds a hardware floor worth quoting exactly: K3 is recommended on supernode configurations of 64 or more accelerators, which is the honest answer to "can I run this locally" and is a different answer from the one the parameter count implies.

If 1.56 TB of MXFP4 is more than your machine holds — and for almost every reader it is — the community reductions are the practical route, and they are legitimate ones. The unsloth/Kimi-K3-GGUF repository is the most-downloaded GGUF conversion on the Hub; NVIDIA publishes an NVFP4 build; there are MLX conversions aimed at Apple silicon; and several REAP-style pruned variants trade expert count for a footprint that fits on a single large workstation. Those are third-party modifications of the weights, not M​oonshot releases, and the licence terms follow the derivative as well as the original. Treat a pruned or heavily quantised build as its own artefact: it will be cheaper to run than the reference and it will not score identically, and no benchmark on this page should be read as applying to it.

The "which file do I download" question, sharpened: take a GGUF if you are serving through llama.cpp-style tooling and need to fit a fixed amount of memory; take the MLX build if the machine is an Apple silicon one; take the vendor's own shards if you have the accelerator budget and want the configuration M​oonshot trained. That is the whole rule, and it is decided by your hardware rather than by the model.

Where this page sits next to the leak page

The one live page on this stem is kimi-k3-1-leak, and it covers the rumour: the leaked feature list, the cryptic post and its deletion, and the timeline that has already slipped once. This page is the other half, and it deliberately does not re-tell any of that. Read the leak page if what you want is the state of the speculation; read this one if what you want is the model that exists, the name it has in the vendor's own catalogue, and the terms its weights carry.

What is not settled

Whether M​oonshot ever ships a model it calls K3.1, and what would be in it. There is a leap of reasoning that points toward a successor weighted more heavily toward computer use and multimodality, and it is a plausible reading of the lab's own product direction — but plausible is not shipped, and nothing in the vendor's material commits to a number, a date or a shape. The one thing genuinely settled is the specification question in the negative: there is no K3.1 specification to give, from any source, today.

Availability, stated carefully

The distinction this section has to hold is between a name and an identifier, because it is easy to blur. M​oonshot publishes exactly one identifier for this line — kimi-k3, in moonshotai/Kimi-K3 and on its own API platform — and that is the only id worth quoting. There is no kimi-k3.1, no kimik3.1 and no kimi-k3-1 in any catalogue we can find, including ours, and this page is not going to print one as an illustration.

What is reachable is Kimi K3. On OrcaRouter it is listed as kimi/kimi-k3 at $3.00 per million input tokens and $15.00 per million output tokens — the provider's list price passed through with 0% markup of our own, against a 1,048,576-token context window and an O​penAI-compatible surface, so the client you already use does not change. Our live catalogue holds four M​oonshot identifiers, kimi/kimi-k2.5, kimi/kimi-k2.6, kimi/kimi-k2.7-code and kimi/kimi-k3, and no fifth one on any spelling of 3.1; that was read against the live model list rather than assumed.

Practically, that matters for how you hold an unverified successor. If a K3.1 does appear, the useful posture is to point a slice of traffic at it behind automatic failover with K3 as the fallback leg — same key, same endpoints, no second contract — so the arrival is a routing change rather than a procurement cycle. There is nothing to fail over to yet, and we are not claiming otherwise.

What to do with all this

If you searched for Kimi K3.1 because you want a successor, the honest instruction is to wait for an artefact — a model-list row, an API identifier, or a repository under the lab's own organisation — and to judge the arrival on one of those rather than on a screenshot. If you searched because you want to use the line today, the model is Kimi K3, it is open-weight under a licence you should read before you ship on it, and it is callable on a rate card whose numbers are published rather than inferred. A version label the search box uses and the product does not is not a model, however much demand is standing behind it.