Moonshot AI has released the full open weights of Kimi K3.1 Pro on Hugging Face, two weeks after launching it in the Kimi app and API on 23 October 2026. It is a 2.8-trillion-parameter mixture-of-experts model with 104 billion parameters active per token, a context window of just over one million tokens, text and image input, and API pricing of $2 per million input tokens and $10 per million output. Moonshot's own benchmarks put it within a point of Claude Opus 5.5 on agentic coding. For a startup, the practical answer is short: you can try it through an API this week, you almost certainly cannot self-host it, and you should not switch production traffic until it passes your own eval set.
I'm Kunal Vohra. I run ColadAI, a multi-LLM platform, and I've been the technical co-founder six times, so "should we move to the new model?" is a question I answer every few weeks. This post is the version I'd want before a team meeting: what shipped, what it costs, what the licence says, and what to do about it.
Who should care about Kimi K3.1 Pro
AI startups paying frontier-model bills. If a large share of your spend goes to a top-tier closed model for coding agents, long-document work or reasoning, a model priced at half of Claude Opus 5.5's list rate with comparable claimed scores is worth a test.
Teams that need long context. One million tokens of context is enough to put a mid-sized codebase or a stack of contracts in a single request. Few open models offer that.
Founders who were told "it's open source, so we can run it ourselves." The weights are open. The hardware bill is not small. More on that below.
Anyone with data-residency or vendor-risk rules. Open weights mean the model can run with a host of your choice, not only Moonshot.
If you are still choosing your first model, this changes little: pick a sensible default behind a thin provider layer. My comparison of the major AI APIs covers that setup.
What actually shipped, with dates
23 October 2026: Moonshot announced Kimi K3.1 Pro and made it live in kimi.ai, the Kimi app, Kimi Code and the Kimi API. Its launch blog promised the full weights "by Nov 4".
4 to 5 November 2026: the weights appeared on Hugging Face under moonshotai/Kimi-K3.1-Pro. Reports differ on the exact day (one says 4 November, another 5 November with a timestamp that is 4 November in UTC if it was Beijing time), so treat it as "this week".
The model, per Moonshot's model card:
- Architecture: mixture-of-experts, 2.8T total parameters, 104B activated, 93 layers, 896 experts with 16 selected per token plus 2 shared.
- Attention: a hybrid of KDA and Gated DSA layers, which is Moonshot's route to the long context without the memory cost of full attention everywhere.
- Context: 1,048,576 tokens.
- Input: text and images, through a 401M-parameter vision encoder (MoonViT-V2).
- Precision: Moonshot says MXFP4 weights and MXFP8 activations with quantization-aware training. The Hugging Face metadata tags the files as 8-bit compressed tensors, so check the exact format your inference engine expects.
- Download size: 1.56 TB across 96 safetensors shards.
- Inference engines named on the card: vLLM, SGLang and TokenSpeed.
Pricing on Moonshot's API (USD per million tokens):
- K3.1 Pro: $2.00 input, $0.20 cached input, $10.00 output.
- K3.1 Pro Highspeed: $4.00 input, $0.20 cached input, $20.00 output, which Moonshot says runs two to three times faster.
- K3 (the previous model): $3.00 input, $15.00 output. The new model is cheaper than the old one.
Benchmarks, all as reported by Moonshot. On Terminal-Bench 4.0 it scores 65.7 against 66.4 for Claude Opus 5.5. On DeepSWE v1.1 it scores 75.5 against 74.2 for Opus 5.5, though Moonshot's own table shows DeepSeek-V4.1-Flash higher at 77.0. On SWE-Marathon it reports 51.7 against 46.3. It trails on some reasoning sets, for example 39.4 on HLE-Diamond against 60.9 for Opus 5.5. These are the vendor's numbers, run with its own settings (maximum reasoning effort, mostly inside Claude Code as the agent harness).
Independent numbers disagree. Artificial Analysis lists an Intelligence Index of 46 on its v5.0.1 scale. Other write-ups quote 55, which may be an older version of the index. I'd use the Artificial Analysis page itself and treat any single index as a rough guide, not a verdict.
The safety claim. Moonshot says it removed cyber-offence data from both the mid-training and reinforcement-learning stages, and that the open model's hacking ability remains behind frontier closed models that have been public for at least three months. Its own internal exploit benchmark shows a drop (81.0 with the removal against 90.5 without). That is a meaningful, documented step. It is also a vendor claim that independent red teams have not yet tested in public, and it arrives the same week Acronis described a single attacker running a mesh of AI agents on jailbroken open-weight models against organisations in 11 countries.
Open weights are a licence to choose where a model runs. They are not a discount on the hardware it needs.
What the licence allows
Kimi K3.1 Pro ships under its own "Kimi K3.1 Pro License", not Apache 2.0 or MIT. It grants broad rights (use, modify, fine-tune, deploy, distribute, sell) with conditions. The three that matter:
- Keep the notice. Include the copyright and licence text with any copy.
- Model-as-a-service above $20 million. If you or an affiliate run a business selling access to the model itself, and that business makes more than $20 million in revenue over any 12 consecutive months, you need a separate agreement with Moonshot before commercial use. Building features on top of the model inside your own product is not model-as-a-service under the licence.
- Attribution at very large scale. A commercial product with more than 100 million monthly active users, or more than $20 million in monthly revenue, must display "Kimi K3.1-Pro" prominently in its interface.
Internal use that does not expose the model or its outputs to third parties is exempt, as is use through Moonshot's own products or certified inference partners.
For nearly every startup reading this, none of the thresholds bite. The one to watch is if you are building an inference platform, a model router or a "bring your own model" product: that is close to the model-as-a-service definition, and you should get a lawyer to read section 2 before you scale. I'm not a lawyer, and licences change between versions, so read the file attached to the exact checkpoint you deploy.
Can you self-host Kimi K3.1 Pro? Almost certainly not
The weights alone are 1.56 TB. Moonshot publishes no official hardware configuration, and the estimates I've seen from hosting providers start at more than 1.56 TB of combined GPU memory and go to 2 TB or more once you leave room for the memory each conversation needs.
Some rough arithmetic to make that concrete. An H100 has 80 GB of memory. Holding 1.56 TB of weights takes about 20 of them before a single user's request is served, and a realistic deployment would need more, spread across several eight-GPU nodes with fast interconnect. In my self-hosting break-even post I used a median H100 rental of $3.81 an hour from October 2026. Twenty GPUs at that rate, running all month, is roughly $55,600 a month, and that figure is the floor, not the plan. It leaves out the extra GPUs for context, the second copy for failover, and the engineers to keep it alive.
At $2 / $10 per million tokens, $55,600 buys roughly 2.1 million requests a month at 8,000 tokens in and 1,000 out. Very few startups send that much traffic to one frontier-class model. So the self-hosting question for this model is closed for almost everyone, the same way it was for the 500B-class models in my earlier post.
What open weights do give you is choice of host. Moonshot's partner list for the previous model, K3, named Together AI, Fireworks, AWS Bedrock and DeepInfra, and the Hugging Face page shows Together AI as an inference provider for K3.1 Pro. I could not confirm a full K3.1 Pro price list on any third-party host at the time of writing. Check before you plan around one.
What it costs per request, compared with Claude Opus 5.5
Using the same request shape as my other cost posts (a retrieval-heavy turn with 8,000 tokens in and 1,000 out):
- Kimi K3.1 Pro: 8,000 × $2 + 1,000 × $10, per million, is about $0.026 per request.
- Kimi K3.1 Pro with 6,000 of those input tokens cached: about $0.015.
- Kimi K3.1 Pro Highspeed: about $0.052.
- Claude Opus 5.5 at its October list price of $4 / $20: about $0.052.
So the standard tier costs half of Opus 5.5 per request, at the same price as the mid-tier closed models (Claude Sonnet 5.5 and GPT-6.1 Sol were both $2 / $10 in October). The Highspeed tier costs the same as Opus 5.5. The honest framing is not "frontier quality at half price". It is "a new option at mid-tier prices that claims near-frontier scores on coding agents". Whether that holds on your workload is the only question that matters.
Two costs hide outside the token price: reasoning at maximum effort produces many output tokens (Artificial Analysis measured about $3.68 and 36 minutes per task on its suite), and prompts, tool schemas and parsers tuned for one model often need rework for another.
A one-week evaluation plan before you switch
This is the sequence I'd run with a team: about a week of part-time effort, ending in a decision with numbers behind it.
Day 1: decide what you are testing for. Pick one workload where cost or quality hurts today: your coding agent, long-document extraction, or support answers. Write down the current model, its cost per task and its pass rate. If you don't log cost per request yet, start there; my AI MVP cost guide shows the per-user arithmetic.
Day 1: check the data path. Read Moonshot's API data-retention and training terms, or those of whichever host you use, against your customer contracts. If your contracts name approved sub-processors, a new provider may need a customer notice before any production data touches it. Test with synthetic or scrubbed data until that is settled.
Days 2 to 3: build or reuse an eval set. Fifty to two hundred real tasks with known good answers or a clear grading rubric. Reuse an existing one unchanged so the comparison is fair.
Days 3 to 4: run both models through the same harness. Keep the provider behind one interface so only the configuration changes. A minimal shape, assuming an OpenAI-compatible endpoint (take the base URL and model id from your provider's docs, not from this post):
import os, time, json
from openai import OpenAI
MODELS = {
"current": {"base_url": os.environ["CURRENT_BASE_URL"],
"api_key": os.environ["CURRENT_API_KEY"],
"model": os.environ["CURRENT_MODEL"]},
"candidate": {"base_url": os.environ["CANDIDATE_BASE_URL"],
"api_key": os.environ["CANDIDATE_API_KEY"],
"model": os.environ["CANDIDATE_MODEL"]},
}
def run(name, task):
cfg = MODELS[name]
client = OpenAI(base_url=cfg["base_url"], api_key=cfg["api_key"])
start = time.time()
resp = client.chat.completions.create(
model=cfg["model"],
messages=[{"role": "user", "content": task["prompt"]}],
)
return {
"model": name,
"task_id": task["id"],
"output": resp.choices[0].message.content,
"input_tokens": resp.usage.prompt_tokens,
"output_tokens": resp.usage.completion_tokens,
"seconds": round(time.time() - start, 2),
}
with open("eval_tasks.jsonl") as f:
tasks = [json.loads(line) for line in f]
with open("results.jsonl", "w") as out:
for task in tasks:
for name in MODELS:
out.write(json.dumps(run(name, task)) + "\n")
Grade the outputs the same way for both models, then compute three numbers per model: pass rate, cost per passing task (not per request), and the 95th-percentile latency.
Day 5: test the failure modes, not just the averages. Run your prompt-injection and tool-misuse cases against the candidate. A model that is better at agentic coding is also better at following instructions hidden in a web page or a ticket. My AI agent security guide has the checklist; the tool permissions belong in your code, not in the model.
Days 6 to 7: decide. Switch only if cost per passing task drops meaningfully and the pass rate holds within your tolerance. If it is close, keep the candidate wired in as a fallback or for one workload.
What I'd do as a CTO this week
I would not migrate anything because of a benchmark table. I would run the eval above on the one workload where frontier-model spend hurts most, through Moonshot's API or a host we already trust, with scrubbed data. If K3.1 Pro passes at half the cost per passing task, I'd move that one workload and keep the current model as fallback.
I would close the self-hosting conversation in the same meeting. A 1.56 TB model is not a startup infrastructure project. If data must stay inside your own boundary, a smaller open model that fits on one or two GPUs, or a dedicated endpoint from a host with the right contracts, is the realistic path.
And I would treat the "removed hacking skills" claim as a welcome step, not a security control. Your agent's blast radius is set by the tools and credentials you give it, whichever model sits in the middle.
If you don't have someone senior to own model choices like this, it rarely needs a full-time hire. A technical advisor retainer can review the eval and the vendor terms; a fractional CTO can own the AI roadmap, the provider layer and the cost tracking end to end.
Frequently asked questions
Is Kimi K3.1 Pro open source? It is open-weight: the full weights are downloadable from Hugging Face under the Kimi K3.1 Pro License. That licence allows commercial use and fine-tuning, with conditions for model-as-a-service businesses above $20 million in yearly revenue and attribution for products above 100 million monthly users or $20 million in monthly revenue. It is not an OSI-approved licence such as Apache 2.0 or MIT.
Is Kimi K3.1 Pro better than Claude Opus 5.5? On Moonshot's own benchmarks it is close on agentic coding (65.7 against 66.4 on Terminal-Bench 4.0, ahead on DeepSWE and SWE-Marathon) and behind on some hard reasoning sets. Independent indexes rank it below the top closed models. Test it on your own tasks before deciding.
How much does the Kimi K3.1 Pro API cost? On Moonshot's platform, $2 per million input tokens, $0.20 per million cached input tokens and $10 per million output tokens. The Highspeed tier is $4 input and $20 output.
Can I run Kimi K3.1 Pro locally? Not on a laptop or a single server. The weights are 1.56 TB, and estimates for serving it start above 1.56 TB of combined GPU memory, which means multiple eight-GPU nodes. For local experiments, smaller open models are the realistic choice; my AirLLM on Mac guide shows what a Mac can and cannot do.
What hardware do I need to self-host Kimi K3.1 Pro? Moonshot has not published an official configuration. Hosting providers estimate more than 1.56 TB to 2 TB or more of combined GPU memory, so roughly 20 or more 80 GB GPUs before headroom. The card names vLLM, SGLang and TokenSpeed as supported engines.
Is it safe to send customer data to Kimi K3.1 Pro? That depends on the provider's data terms and your contracts, not on the model. Read the retention and training terms of Moonshot's API or of the host you choose, check your sub-processor commitments, and test with scrubbed data first.
If you're deciding whether to move part of your AI spend to a new model, book a 30-minute call. Bring your current cost per task and the workload that hurts most, and I'll help you design the eval and read the results.
Sources
- Kimi K3.1 Pro technical blog (Moonshot AI)
- Kimi K3.1 Pro model card (Hugging Face, Moonshot AI)
- Kimi K3.1 Pro License (Moonshot AI)
- Kimi API pricing (Moonshot AI)
- Kimi K3.1 Pro intelligence, performance and price analysis (Artificial Analysis)
- Moonshot releases Kimi K3.1 Pro and says it cut its hacking skills (The Next Web)
- Kimi K3.1 Pro open weights: licence conditions and self-deployment threshold (APIYI)
- Kimi K3.1 Pro specs, price, open weights date and benchmarks (Yotta Labs)
- Kimi K3.1 Pro opens on Hugging Face (ChainCatcher via KuCoin)
- BOSSAI: inside the AI attack mesh that targeted Taiwan's emergency services (Acronis)
Written By
Kunal Vohra
Technical Co-Founder & Fractional CTO
I've co-founded 6+ startups across India, the UAE, and the US, spanning AI, Web3, fintech, and cybersecurity. I write about the technical and strategic decisions that determine whether a startup thrives or stalls.
Comments
Loading comments…