Kimi K3.1 Pro Open Weights: Hardware, License and Real Costs

Moonshot AI has published the full weights of Kimi K3.1 Pro on Hugging Face. It is a 2.8-trillion-parameter Mixture-of-Experts model with 104B active parameters, a 1M-token context window and a mostly permissive MIT-style license. You can legally build commercial products on it. Running it yourself, though, takes a multi-node cluster of Blackwell-class GPUs, so for most teams the open weights matter more for leverage and data control than for cost savings. At typical startup volumes, the $2/$10-per-million-token API stays far cheaper than self-hosting.

This guide covers what was released, what the license actually requires, the published hardware recipes, and how to work out whether self-hosting makes sense for you.

What Moonshot released, and when

Moonshot launched Kimi K3.1 Pro in its apps and API on October 23, 2026, according to The Next Web. A "Highspeed" variant that Moonshot says runs 2–3× faster launched alongside it. Moonshot's launch post promised that "the full model weights will be released by Nov 4". The repository is now live at moonshotai/Kimi-K3.1-Pro and reached the Hacker News front page on November 4–5, 2026. Some aggregators date the release to November 5, so expect minor discrepancies.

Key specs from the model card:

The MXFP4 detail matters. These are the precision Moonshot trained for, not a lossy compression of a BF16 original, so "dequantizing" to BF16 would multiply memory needs without improving quality. The model card also flags an integration gotcha for agent builders. In multi-turn and tool-calling conversations, you must send back the full assistant message, reasoning content included. If you strip reasoning blocks to save tokens, as many OpenAI-compatible wrappers do, quality may degrade.

Benchmarks: strong on agents, weaker on pure reasoning

All headline numbers are Moonshot's own and have not been independently verified. Moonshot reports 65.7% on Terminal-Bench 4.0, against 66.4% for Claude Opus 5.5 and 58.2% for GPT-6 Astra. It also claims to lead GDPval-AA. DataCamp's comparison table, built from the same vendor figures, shows clear gaps elsewhere. K3.1 Pro scores 39.4% on HLE-Diamond, against 60.9% for Opus 5.5 and 65.8% for Astra. On ProgramBench it scores 31.5%, against 65.0% for Opus 5.5. In short, it is competitive at agentic coding and tool use and behind at hard reasoning. Run your own evals on your own tasks before you switch.

The cyber capability cut

Moonshot says it deliberately weakened one capability before releasing the weights. Its blog post says cyber-related data was removed from mid-training and from the RL environment mix. On its internal exploit benchmark, a checkpoint trained without those measures solved 90.5% of tasks and the released model solved 81.0%. Moonshot's stated principle is not to release open weights that "extend the absolute cyber frontier." For most builders this changes little, but security-tooling teams should test the open weights directly rather than assume API-level performance.

What the license actually lets you do

The Kimi K3.1-Pro License is not an OSI open-source license, but it is close to MIT. It grants rights to use, copy, modify, fine-tune, distribute, sublicense and sell, provided you keep the copyright notice. It adds two conditions:

1. Model-as-a-Service threshold. If you or your affiliates sell model access to third parties (inference or fine-tuning via an API, with meaningful control over inputs or parameters) and your combined revenue tops $20 million over any 12 consecutive months, you need a separate agreement with Moonshot before commercial use. The license explicitly excludes end-user products that embed the model in specific features, and simple relaying of requests to models hosted elsewhere.
2. Attribution at scale. Commercial products with more than 100 million monthly active users or more than $20 million in monthly revenue must prominently display "Kimi K3.1-Pro" in the UI.

Both conditions are waived for internal use, meaning use that doesn't expose the software, its outputs or its capabilities to third parties. They are also waived for use through Moonshot's own products or certified inference partners.

What this means in practice:

• A SaaS startup embedding K3.1 Pro in a feature (an AI writing assistant, a coding agent inside your product) falls outside the MaaS definition and well below the attribution thresholds. You are effectively unrestricted.
• An inference provider or GPU cloud reselling raw API access is the main audience for clause 2. Once you pass $20M in trailing revenue, you need to negotiate, and those terms are not public.
• Some terms are undefined. "Prominently displayed" and the edges of "internal use" aren't spelled out, and the two revenue tests use different measures ($20M over 12 months versus $20M monthly). If you are anywhere near those numbers, get counsel. Moonshot lists license@moonshot.ai for questions.

Hardware: what it really takes to self-host

Moonshot's model card gives no minimum hardware. The best guidance comes from published inference recipes. NVIDIA's Dynamo recipe page lists these configurations:

There are some caveats. A SemiAnalysis InferenceX pull request opened on November 4, 2026 states that vLLM's own K3.1 recipe has a vram_minimum_gb of 1,874, more than one 8×B200 node holds. It also says vLLM currently marks only GB300 as verified for K3.1, and that the B200 pipeline-parallel configuration had not yet been run at the time. Treat B200 deployments as early-stage.

What doesn't work:

• 8×H100 (640 GB) is nowhere close.
• 8×H200 (~1.13 TB) can't hold the 1.56 TB of weights. A cost analysis by API reseller APIYI puts it roughly 400 GB short, so you would need at least two nodes.
• Consumer GPUs and even 512 GB Macs cannot hold the native weights. The model card links community quantizations for llama.cpp, Ollama and LM Studio, but heavily quantized versions of a 2.8T model are effectively different models. Don't expect them to match the published benchmarks.

Weights alone are about 1.56 TB across 96 safetensors shards. KV cache for long contexts comes on top of that, so plan storage and network accordingly. The Dynamo recipes use a shared persistent volume rather than copying weights to each node.

API vs self-hosting: a break-even check

According to DataCamp's summary of Moonshot's pricing, the API costs:

Pricing is flat across the full 1M context. Moonshot's pricing docs add that batch inference on kimi-k3.1-pro is billed at 60% of the standard rate. The live price table didn't render when we checked it, so confirm the exact figures on the pricing page before you commit a budget.

Now the self-hosting side. APIYI cites a reported Modal bill of $56.79/hour for one 8×B300 node, which comes to about $41,457/month running 24/7. These are third-party, single-source figures from a company that sells API access, so treat them as a rough order of magnitude. The arithmetic itself is simple:

• With a 5:1 input-to-output ratio and no caching, each 1M output tokens costs $10 + (5 × $2) = $20 on the API.
• $41,457 ÷ $20 ≈ 2.07 billion output tokens per month before one rented node breaks even. That is about 800 output tokens per second, sustained, around the clock.
• Prompt caching widens the gap further. Cached input costs a tenth of fresh input, so agent workloads with long shared prefixes become even cheaper on the API.

Utilization decides the outcome. APIYI's own table shows effective cost per million output tokens ranging from about $171 at a single stream of 92 tok/s to about $3.40 at a 4,634 tok/s aggregate peak. A busy, well-batched cluster can beat the API. A lightly used one costs many times more. You can plug your own traffic into the LLM API Cost Calculator, and use the Token Counter to estimate your real input-to-output ratio.

When self-hosting is worth it anyway

Cost is rarely the best reason to self-host this model. These are the stronger reasons:

• Data residency and control. Moonshot offers Zero Data Retention on its API, but regulated customers may require that inference never leave their own cloud account.
• Supply-chain and policy risk. In July 2026, the White House accused Moonshot of using banned Nvidia chips and copying an Anthropic model to build K3, The Next Web reported. No evidence was published. If enterprise buyers or regulators are uneasy about sending data to a China-based API, the open weights let you run the model on US or EU infrastructure, or buy from a third-party host.
• Fine-tuning and customization. The license allows derivatives. Full fine-tuning at 2.8T parameters is a serious undertaking, but it is legally possible.
• Pricing leverage. Even if you never deploy it, a credible open-weight model near the frontier on agentic coding gives you a fallback and a bargaining chip with closed-model vendors.

What to do now

1. Evaluate through the API first. Point an OpenAI-compatible client at kimi-k3.1-pro, or use the OpenRouter ID moonshotai/kimi-k3.1-pro that DataCamp lists. Test it on your real agent tasks at reasoning_effort low and max, and check that your framework passes reasoning content back between turns.
2. Check your license position once. If you embed the model in a product, you are almost certainly fine. If you resell inference, track trailing 12-month revenue against the $20M line.
3. Run the break-even math before buying GPUs. Below roughly 2 billion output tokens a month, the API (or batch at 60%) wins on cost.
4. If you self-host, start on GB300 with vLLM. It is currently the only verified K3.1 target. Treat B200 and SGLang recipes as experimental until benchmarks and bug reports settle.
5. Watch third-party hosts. Expect inference providers to list the open weights over the coming weeks, often below first-party prices. Also watch for independent benchmark results that confirm or contradict Moonshot's numbers.

If you are building an agent product on top of K3.1 Pro or another open-weight model, you can submit it to the LaunchBoosts directory for free, or compare alternatives in AI Coding Assistants.