Kimi K3.1 Pro: Moonshot's Open Weight Model and What a 1M Token Context Actually Changes

Moonshot AI put Kimi K3.1 Pro live in its API on October 23, 2026, through an OpenAI compatible endpoint, and described it in its own quick start documentation as a post trained variant of Kimi K3. The company's stated focus areas are coding, agentic tasks, three dimensional workflows, and financial research, though Moonshot frames its reported gains on internal financial and business operation tests as company figures rather than independent findings. Independent researcher Simon Willison reported the model placing near the top of the Artificial Analysis index, one limited but notable third party data point. Pricing sits at 2 dollars per million input tokens and 10 dollars per million output tokens on the standard tier. Moonshot said open weights would follow by November 4, 2026, so self hosting was not an option at launch.

The headline spec most coverage leads with is the 1 million token context window, and it deserves a more specific read than "bigger context is better." A context window that size changes what categories of task are even attemptable in a single pass rather than just making existing tasks marginally cheaper. A full enterprise codebase under a few hundred thousand lines, a quarter's worth of support transcripts, or a lengthy contract set can fit in context without chunking or retrieval, which removes an entire layer of engineering, the retrieval pipeline, the chunk boundary decisions, the reranking logic, that teams normally build around smaller context models. That is a genuine capability shift for agentic coding and document heavy research tasks specifically, not a generic improvement that applies evenly across every use case.

The architecture means this is not a model most teams will actually self host

Kimi K3.1 Pro inherits Kimi K3's mixture of experts design: 2.8 trillion total parameters with only 104 billion active for any given token, routed across 896 experts with 16 selected per token plus 2 shared experts. That ratio, roughly 4 percent of parameters active at a time, is exactly what makes a model this large runnable at all for inference, since you only need to hold and compute with the active subset per token rather than the full parameter count. It is also exactly why "open weights" does not mean "runnable on a workstation."

At native MXFP4 precision, the weights occupy roughly 1.56 terabytes on disk, a figure the model inherits from K3's published footprint and that should be verified against the actual K3.1 Pro repository once it lands. Community quantization will bring that down, but not into consumer reach: a 2 bit quantized build of a comparably sized model still runs over 700 gigabytes. A single RTX 5090 with 32 gigabytes of VRAM holds roughly 2 percent of the weights at native precision. No consumer GPU, and no realistic multi GPU home workstation, clears that bar.

The actual self hosting floor looks more like this. vLLM's stated minimum for K3 class models is one node of 8 GB300 class GPUs, pooling roughly 2.3 terabytes of HBM3e, enough to hold the weights with room for KV cache. An 8 times H200 node, with about 1.13 terabytes of pooled memory, does not clear that bar at all; H200 class serving needs 16 GPUs spread across two nodes to work. Reference throughput on 16 GB300 class GPUs lands around 118 tokens per second per request, rising to roughly 370 tokens per second with speculative decoding enabled. Renting that capacity, a 16 times H200 pod, runs in the neighborhood of 70 dollars an hour, which puts a meaningful self hosted deployment solidly in enterprise infrastructure budget territory rather than a side project. Four Mac Studios clustered over Thunderbolt 5 has been floated as one of the few non data center paths to running trillion class weights at all, though that remains a specialist setup rather than something most engineering teams will stand up casually.

What to actually check before you download the open weights

Assuming Moonshot's November 4 timeline held, the first thing worth checking before pulling anything down is the license, not the benchmark scores. Kimi K3 shipped under a custom license rather than the permissive Modified MIT or Apache 2.0 terms some early coverage predicted, and license terms determine whether you can actually deploy a self hosted instance commercially, redistribute fine tuned derivatives, or just run it for internal research. Teams evaluating this model for a commercial product should read the actual license file against their use case before investing engineering time in a deployment, since benchmark performance is irrelevant if the license does not permit the deployment you have in mind.

The second thing worth checking is how K3.1 Pro's claimed gains over K3 hold up against your own workload rather than Moonshot's internal test set. Moonshot's own reported improvements are on financial and business operation benchmarks it selected, and the company explicitly frames its reduced hallucination claim as coming from "a stress test rather than a general error rate." Benchmark comparisons across frontier coding models have repeatedly shown that cost per completed task, not raw benchmark score, is the number that determines whether a model is actually worth deploying for a given workflow, and that framing applies just as directly here. A 2 dollar input and 10 dollar output price point is competitive on paper, but it only matters relative to how many tokens your actual agentic workload burns per completed task, including retries and tool calls, not the sticker price alone.

When this applies to your stack

If your team is evaluating Kimi K3.1 Pro for an agentic coding or document heavy research workload, the API is the only realistic entry point for the vast majority of teams, regardless of when the open weights land, because the self hosting floor sits at multiple GB300 class GPUs and enterprise grade infrastructure spend. The 1 million token context window is the genuinely differentiated capability here, worth testing specifically against workloads that currently require a retrieval pipeline you would rather not maintain. Teams weighing a self hosted deployment against the API, or benchmarking K3.1 Pro against Claude or GPT class models for a specific agentic workflow, should model cost per completed task against their own traces before committing, not against Moonshot's published benchmark set.

FAQ

When did Kimi K3.1 Pro become available, and when do the open weights land? The API went live October 23, 2026, through an OpenAI compatible endpoint. Moonshot said open weights would follow by November 4, 2026.

How much does Kimi K3.1 Pro cost through the API? 2 dollars per million input tokens and 10 dollars per million output tokens on the standard tier, per pricing reported by independent researcher Simon Willison.

Can Kimi K3.1 Pro run on a single workstation or consumer GPU? No. At native precision the weights occupy roughly 1.56 terabytes, and even aggressive community quantization stays well above consumer VRAM capacity. A realistic self hosted deployment needs at minimum one node of 8 GB300 class GPUs or a two node, 16 GPU H200 class cluster.

What makes the 1 million token context window actually useful rather than just a bigger number? It allows entire codebases, long transcript sets, or large document collections to fit in a single context without a retrieval pipeline, removing an engineering layer rather than just reducing cost per call.

Sources:

• Moonshot Releases Kimi K3.1 Pro API, Open Weights Due Nov 4
• Kimi K3.1 Pro for Local AI: Open Weights Land November 4, the Hardware Math Before You Clear 1.6TB of Disk