Kimi K3.1 Pro: open weights by Nov 4, but the $2/$10 API wins
On October 23, 2026, Moonshot AI released Kimi K3.1 Pro, a post-trained version of Kimi K3 and the first model in the K3.1 series. It is live in the Kimi apps, Kimi Code and the API as kimi-k3.1-pro, plus a -highspeed variant that Moonshot says runs 2 to 3× faster. Moonshot's blog promises that "the full model weights will be released by Nov 4."
The release combines two pieces of news. The API price drops from $3/$15 to $2/$10 per million tokens. The weights will be "open", but they are the same 2.8T-parameter backbone as K3, which I already called open but unrunnable. This post works through the numbers on when downloading those weights is worth it.
What actually shipped
The model is a post-train of K3. The K3 model card lists 2.8T total / 104B active parameters, 896 experts with 16 selected per token plus 2 shared, 93 layers (69 Kimi Delta Attention + 24 Gated MLA), and a 1,048,576-token context. Moonshot's K3.1 blog only says "3T-class". The 104B active figure for K3.1 comes from K3's card and launch coverage.
On quantization, K3 was trained quantization-aware with MXFP4 weights / MXFP8 activations. The K3 repo on Hugging Face is about 1.56 TB of safetensors. For serving K3, Moonshot recommends "supernode configurations with 64 or more accelerators".
The API is OpenAI-compatible. Thinking is always on, with reasoning_effort set to low, high or max (default max). Temperature 1.0 and top_p 0.95 are fixed. Default output is 131,072 tokens, with a maximum of 1,048,576. Caching is automatic, with 5-minute or 1-hour TTL. Zero Data Retention is available but off by default for enterprises.
There is an open-weight caveat. Moonshot writes that "for the open-weight release of K3.1 Pro, we identified and removed cyber-related data from both training stages." The weights you download may therefore not be exactly the model behind the API.
Numbers that matter
All benchmarks below are self-reported by Moonshot at max effort, mostly run in the Claude Code harness. Competitor scores come from Moonshot's charts.
| Benchmark | K3.1 Pro | Comparison |
|---|---|---|
| Terminal-Bench 4.0 | 65.7% | Opus 5.5 66.4%, GPT-6 Astra 58.2% |
| SWE-Marathon v1.1 | 51.7* | Opus 5.5 46.3* |
| Terminal-Bench Science 0.1 | 38.1* | GPT-6 Astra 68.1, Opus 5.5 63.3 |
| BenchCAD (with tools) | 92.7 | Opus 5.5 96.2, GPT-6 Astra 95.9 |
| Kimi Hallu Bench Hard (with tools, internal) | 8.3% | K3 23.4%, GPT-6 Astra 5.5% |
Values marked with an asterisk are reported by MarkTechPost from Moonshot's charts. These numbers are not in Moonshot's blog text.
| API price, $ per M tokens | Input | Cache hit | Output |
|---|---|---|---|
| K3.1 Pro | 2.00 | 0.20 | 10.00 |
| K3.1 Pro Highspeed | 4.00 | 0.20 | 20.00 |
| K3 (previous) | 3.00 | 0.30 | 15.00 |
The prices come from MarkTechPost and OrcaRouter. Moonshot's quickstart page links to a pricing page but doesn't quote prices itself.
For an illustrative API bill, take my workload: 2B input tokens a month at an 80% cache-hit rate, plus 200M output tokens.
| Model | Cached input | Uncached input | Output | Monthly total |
|---|---|---|---|---|
| K3.1 Pro | 1.6B × $0.20 = $320 | 0.4B × $2 = $800 | 0.2B × $10 = $2,000 | $3,120 |
| K3 | $480 | $1,200 | $3,000 | $4,680 |
| Highspeed | $320 | $1,600 | $4,000 | $5,920 |
Then the self-hosting memory arithmetic, weights only. At MXFP4 (about 4.25 bits/param), 2.8T × 4.25 / 8 ≈ 1.49 TB, which matches the roughly 1.56 TB K3 repo. FP8 is 2.8 TB and BF16 is 5.6 TB. 8× B200 (1,440 GB HBM on the spec sheet) does not fit even MXFP4. 8× B300 (2,304 GB) fits it with about 700 GB left for KV cache and activations. FP8 needs at least two B300 nodes or three 8× H200 nodes. On decode traffic, each token reads about 104B × 4.25/8 ≈ 55 GB of active weights at MXFP4, or 104 GB at FP8. That is double what a 52B-active model like Mistral Large 4 reads.
Break-even, with a labelled assumption: I assume $4 per GPU-hour, which is my placeholder, not a quote. Moonshot's 64-accelerator supernode then costs 64 × 730 h × $4 ≈ $187k/month before engineering time. At $10 per M output tokens, that buys about 18.7B output tokens a month from the API, or roughly 7,100 tokens/s sustained around the clock. The example workload above is about 1/60 of that.
Moonshot's 64-accelerator supernode costs about $187k a month at my assumed GPU price, which buys roughly 18.7B output tokens a month from the API.
Technical meaning and trade-offs
The hybrid attention helps with long context, not with weights. 69 of the 93 layers use KDA, a linear-attention variant with constant-size state. Only the 24 MLA layers grow a KV cache. That makes 1M-token context far cheaper in memory than a pure-MLA design. It does nothing about the 1.5 TB of experts. KDA also complicates prefix caching. Moonshot contributed a KDA prefix-cache implementation to vLLM, and it reports cache hit rates "above 90%" on coding workloads on its own API. Expect to work hard to match that on your own cluster.
The license is probably not the blocker. The K3 License is MIT-style. It requires a separate agreement only for Model-as-a-Service operators with more than $20M in revenue over 12 months, and "Kimi K3" attribution above 100M MAU or $20M in monthly revenue. Internal use is exempt. Moonshot hasn't named the K3.1 license. If it reuses the K3 terms, most enterprises self-hosting internally are covered. See also distillation due diligence.
The API has its own costs. Changing reasoning effort mid-conversation invalidates cache hits (per OrcaRouter). Fixed sampling parameters and always-on thinking mean you can't trade quality for latency the usual way. Highspeed doubles the price to buy speed.
My read: under my GPU-hour assumption, the API is cheaper until you sustain several thousand output tokens/s, and at typical team volumes it is cheaper by more than an order of magnitude. Past that point, you're competing on utilization with Moonshot's own Mooncake serving stack.
What I'd do
I'd use the API, and design prompts so cache hits stay above 80%. Never change effort mid-session. My Bedrock caching notes for K3 apply here too. I'd re-run evals on K3.1 Pro, not K3. The hallucination drop (23.4% to 8.3% on Moonshot's internal stress test) is the change most likely to matter in production. It is self-reported, so verify it yourself.
I'd download the weights only for residency, air-gapping or fine-tuning, and budget 8× B300 as the minimum serious node at MXFP4. I'd evaluate the open checkpoint separately: it has cyber data removed, so API results don't transfer to it automatically. And I'd read the K3.1 LICENSE file on release day before assuming the K3 terms carry over.
What I couldn't verify
SWE-Marathon (51.7 vs 46.3) and Terminal-Bench Science (38.1) appear only in MarkTechPost's reading of Moonshot's charts; Moonshot's blog text gives no K3.1 score for either. For parameter counts for K3.1 specifically, Moonshot says "3T-class", and the 2.8T/104B figures come from K3's model card. I took the API prices from MarkTechPost and OrcaRouter, because Moonshot's own pricing page didn't return the figures when I fetched it. The K3.1 license is not stated; OrcaRouter says "permissive". All benchmarks are self-reported, and Artificial Analysis had no K3.1 Pro score on release day. The GPU-hour price and HBM sizes are my assumptions and spec-sheet figures, not measurements.
I'll revisit after November 4, once the weights and license are out.
Sources
Primary: Kimi: Kimi K3.1 Pro tech blog; Kimi: Kimi K3 tech blog; Hugging Face: moonshotai/Kimi-K3 model card; Hugging Face: Kimi K3 LICENSE; Kimi API: K3.1 Pro quickstart. Coverage: MarkTechPost: Moonshot AI Kimi K3.1 Pro; OrcaRouter: Kimi K3.1 Pro release.