Kimi K3.1 Pro Open Weights: Download, License, or API?
Kimi K3.1 Pro's official weights are available on Hugging Face. Check the 2.8T-total/104B-active architecture, roughly 1.56 TB download, custom license thresholds and exemptions, and hardware-specific serving recipes. Pin and verify a download, make a small API request, and compare operating costs without treating active parameters as the model's memory footprint.
Contents
Kimi K3.1 Pro weights are available from Moonshot AI’s official Hugging Face repository. Start with a hosted API for coding trials; choose self-hosting when control requirements justify the hardware and license review. The 104B active-parameter count is not the size of the complete model you must store.
As of 2026-11-11, the repository contains the checkpoint, configuration, and a custom license. The practical choice is between operating that checkpoint and buying inference through an API.
What do the open weights include?
The release provides the Kimi K3.1 Pro checkpoint, rather than only an API model name. Moonshot’s technical announcement describes it as a multimodal model post-trained from Kimi K3 through joint reinforcement learning.
The official model card gives these specifications. The precise context limit is also listed in Kimi’s API pricing documentation.
| Property | Published value |
|---|---|
| Hugging Face repository | moonshotai/Kimi-K3.1-Pro |
| Architecture | Mixture-of-Experts, or MoE |
| Total parameters | 2.8T |
| Activated parameters | 104B |
| Context window | 1,048,576 tokens |
| License | Custom Kimi K3.1-Pro License |
An MoE model activates a subset of its parameters for each token. That does not remove the remaining experts from the checkpoint. Plan storage from the actual files, not from 104B alone.
The repository file listing shows approximately 1.56 TB and weight names ending in of-000096.safetensors. Its configuration specifies mxfp4-pack-quantized. The vLLM recipe clarifies that routed experts use MXFP4 while the other weights use BF16.
For coding teams, this creates a deployment choice, not a ready-made coding agent. Choose a serving engine and an agent client separately. Test repository reading, tool execution, and a real acceptance test before moving an existing workflow.
Moonshot’s API quickstart also documents kimi-k3.1-pro-highspeed as a hosted option. Treat its advertised speed as a service claim, not a performance target guaranteed by downloading these weights.
What does the Kimi K3.1 Pro license require?
Commercial use is allowed subject to the Kimi K3.1-Pro License. Review its separate MaaS and branding conditions before deployment. This is a practical reading, not a legal opinion about your business.
MaaS uses a rolling revenue test
Section 2 applies when the licensee or an affiliate operates a Model as a Service business. A separate agreement is required when their aggregate revenue exceeds $20 million over any consecutive 12 months.
The wording covers aggregate licensee-and-affiliate revenue, not only revenue earned from this model. The agreement must precede commercial use of the software or its derivatives.
MaaS means third-party inference or fine-tuning access with meaningful control over inputs, parameters, or training data. It excludes end-user products whose model capabilities are solely embedded in specific features or harnesses. It also excludes mere relays to models hosted elsewhere. Have counsel check whether your actual service fits an exclusion.
Branding uses monthly product thresholds
Section 3 applies to commercial products or services that use the software or its derivatives. It requires prominent display of Kimi K3.1-Pro in the relevant product or service’s user interface when either threshold is exceeded. Those thresholds are 100 million monthly active users or $20 million in monthly revenue.
The user threshold is monthly active users, not daily active users. The revenue window here is one month, not the rolling 12-month MaaS test.
Exemptions have their own scope
Section 4 exempts internal use and access through Moonshot’s official products or certified inference partners from Sections 2 and 3. Its internal-use definition excludes making the software, its outputs, or underlying capabilities available to third parties.
Do not infer certified-partner status from API compatibility. A gateway integration and a license exemption are different questions. Preserve required copyright and permission notices, and review the applicable provider terms separately.
How do you download and verify the weights?
Inspect the license and download size before transferring the checkpoint. Use a current hf CLI, installed through the Hugging Face CLI instructions, and a filesystem with sufficient free space.
The commands below use Bash. They pin the repository revision inspected on 2026-11-11.
KIMI_REPO="moonshotai/Kimi-K3.1-Pro"
KIMI_REV="d9e99b0792a5e93b78ea9bea62a68167e36ddd9e"
KIMI_DIR="$PWD/kimi-k3.1-pro"
hf download "$KIMI_REPO" README.md LICENSE config.json \
--revision "$KIMI_REV" --local-dir "$KIMI_DIR"
hf download "$KIMI_REPO" --revision "$KIMI_REV" \
--local-dir "$KIMI_DIR" --dry-runRead the downloaded LICENSE and README.md. The download dry run reports pending files and bytes without transferring the weights. Leave additional room for download caches and the runtime’s working files; the repository size is not an all-inclusive capacity budget.
After approving the license and capacity, run this in the same Bash session:
hf download "$KIMI_REPO" --revision "$KIMI_REV" \
--local-dir "$KIMI_DIR" &&
hf cache verify "$KIMI_REPO" --revision "$KIMI_REV" \
--local-dir "$KIMI_DIR" --fail-on-missing-filesHugging Face’s verification command checks local files against Hub checksums. --fail-on-missing-files also catches an incomplete snapshot.
Proceed only when verification succeeds without missing files or checksum mismatches. A successful download proves artifact completeness, not that your inference engine can load the model. For a checksum mismatch, use hf download with --force-download for the reported filename at the same revision. Repeat verification before serving.
What hardware should you plan for?
Use a hardware-specific deployment recipe, rather than treating this as a 104B workstation model. As of 2026-11-11, the vLLM recipe documents an eight-GPU NVIDIA baseline: two GB300 trays or one B300 node.
That is a documented configuration, not a universal minimum or a promise about throughput. The recipe says its baseline throughput was not tuned. Use the model-specific recipe rather than a generic launch command.
The SGLang cookbook provides another route. It names the kimi-k3.1-day-0 branch and distinguishes verified configurations from recipes still undergoing verification.
For a procurement trial, select one documented hardware configuration and record the engine version, image digest, and checkpoint revision. Start with a short request. Then increase context and concurrency separately while measuring memory, time to first token, and completed-task cost.
The advertised context window does not guarantee enough runtime memory for every concurrency setting. Keep the agent client, tools, reasoning setting, and acceptance tests fixed when comparing local inference with an API.
Self-hosting becomes a stronger candidate when you need checkpoint control, customization, or a controlled inference environment. It becomes weaker when your team lacks cluster operations capacity or cannot keep the hardware usefully occupied. Review the self-hosted model cost checklist before converting an API invoice into a hardware budget.
How can you try the API instead?
Use kimi-k3.1-pro for a small coding request before committing to infrastructure. Keep the API model ID distinct from the Hugging Face repository ID.
These API routes were checked on 2026-11-11:
| Route | Model ID | OpenAI-compatible Base URL | Credential |
|---|---|---|---|
| Moonshot API | kimi-k3.1-pro | https://api.moonshot.ai/v1 | Your Moonshot API key |
| BetterToken API | kimi-k3.1-pro | https://www.bettertoken.ai/v1 | Your BetterToken API key |
BetterToken lists this exact model ID as of the verification date. Check current gateway prices separately; the Moonshot rates below are not a BetterToken quote.
For the direct Moonshot test, create an API key through the platform linked from its quickstart. Use Bash and enter the key at the hidden prompt:
read -rs MOONSHOT_API_KEY && export MOONSHOT_API_KEY
curl --fail-with-body --silent --show-error \
"https://api.moonshot.ai/v1/chat/completions" \
-H "Authorization: Bearer ${MOONSHOT_API_KEY}" \
-H "Content-Type: application/json" \
--data '{
"model": "kimi-k3.1-pro",
"reasoning_effort": "low",
"max_completion_tokens": 4096,
"messages": [
{
"role": "user",
"content": "Return a Python function add(a, b) and one assert checking add(2, 3) == 5."
}
]
}'Inspect choices[0].message.content for the function and assertion. Check the response’s usage information before scaling the test. This request checks authentication and text generation; it does not prove that a coding agent can read or modify files.
Kimi’s reasoning documentation supports low, high, and max, with max as the default. Thinking remains enabled. The example selects low for a small connectivity check.
If the response contains an API error, check the endpoint, credential provider, and exact model ID first. If the answer is truncated, inspect the output limit before treating the response as a model-quality failure.
For multi-turn API conversations and tool calls, return the complete assistant message unchanged in messages, including reasoning_content and tool_calls. Then follow the Claude Code and Codex setup guide and verify an actual file-read task.
API token billing is separate from Kimi membership and Kimi Code allowances. Use the quota and API-billing guide when a subscription limit is the actual blocker.
How should you compare self-hosting and API costs?
Compare completed tasks at the same quality target, not weight availability against an API token rate. Downloadable weights do not remove hardware, storage, networking, operations, or potential license-agreement costs.
As checked on 2026-11-11, Moonshot’s API platform lists the following USD rates per 1,000,000 tokens. Kimi’s pricing terms exclude applicable taxes.
| API model | Regular input | Output | Cache hit | Default 5-minute cache write |
|---|---|---|---|---|
kimi-k3.1-pro | $2.00 | $10.00 | $0.20 | $2.00 |
kimi-k3.1-pro-highspeed | $4.00 | $20.00 | $0.20 | $4.00 |
The cache documentation separates cache hits, cache writes, and uncached input. For Chat Completions and Responses, omitting prompt_cache_options selects the 5m cache-write lifetime. The request above omits that field and therefore uses this default.
Do not count a cache-write token again as ordinary input. Different cache lifetimes need their corresponding write rates.
For an estimate, assume one standard-model task consumes 100,000 input tokens and 10,000 billed output tokens. Assume no cache hits, with all input either uncached or written using the default five-minute lifetime.
Both input categories cost $2.00 per million tokens in this scenario:
Estimated token charge
= (100,000 × $2.00 + 10,000 × $10.00) / 1,000,000
= $0.30 before taxesThis is a calculation, not a measured task result. Use reported output usage rather than visible answer length. Exclude optional tools and other services from this estimate only when your workload does not use them.
For self-hosting, divide the full operating cost by successfully completed equivalent tasks. Include idle capacity, host memory, storage, power or rental charges, networking, maintenance, and any required commercial agreement. Keep retry costs and acceptance-test failures visible on both routes.
Choose the API first for an application trial or uncertain demand. Reconsider self-hosting when control requirements justify it and a measured workload supports the operating cost. For a MaaS business, settle the license classification before making either a deployment promise or a procurement commitment.
