Kimi K3.1 Pro Weights Out: API vs Self-Host Guide

What you’ll have working by the end

Two paths. Path A: call Kimi K3.1 Pro on Moonshot’s OpenAI-compatible API with reasoning_effort set on purpose, multi-turn fields intact, and a bill you can explain. Path B: only pull the open checkpoint if you already have B300/GB300-class iron – not because a blog said “weights are free.”

The Hugging Face drop landed 4 November 2026 (repo moonshotai/Kimi-K3.1-Pro), after the API launch on 23 October 2026. If you need coding/agent work this week, you do not wait on a multi-terabyte sync.

The problem the hype papers over

“Open weights” still reads like clone-repo-and-chat. Here it doesn’t. The model card describes a 2.8T-total / 104B-active MoE, 1,048,576-token context, MXFP4 expert weights, MoonViT-V2 vision, ~96 safetensors on disk totaling about 1.56 TB.

That’s hangar hardware, not a desk GPU. Leaderboard screenshots (the card’s Terminal-Bench / SWE-Marathon rows sit in the same band as other flagship agents) don’t change the fork: ship on API, or budget a supernode.

Think of the weights drop like publishing jet-engine blueprints – thrilling if you own the hangar, useless if you needed a seat on tomorrow’s flight.

API first: IDs, price, effort trap

platform.kimi.ai lists kimi-k3.1-pro and kimi-k3.1-pro-highspeed. As of early November 2026: standard $2 input / $10 output per 1M tokens; Highspeed $4 / $20 for roughly 2-3× speed; cached input $0.20.

Turns out thinking never turns off. Official quickstart: always-on reasoning; reasoning_effort is low | high | max, and omitting the field means max. Max wins public tables. Max also prints tokens like a broken meter.

Minimal working call

import os
from openai import OpenAI

client = OpenAI(
 api_key=os.environ["MOONSHOT_API_KEY"],
 base_url="https://api.moonshot.ai/v1",
)

completion = client.chat.completions.create(
 model="kimi-k3.1-pro",
 reasoning_effort="high", # don't silently default to max
 messages=[{
 "role": "user",
 "content": "Outline a 5-step plan to refactor a flaky pytest suite."
 }],
)
print(completion.choices[0].message.content)

Pick effort once per long agent run. Community migration notes (cache pricing + effort behavior) warn that flipping mid-thread can miss prefix-cache hits – you pay again for thinking you already bought. Highspeed when latency owns the UX; standard when output volume owns the invoice.

Real-world multi-turn gotcha

Agent loops die here more often than on raw quality. Card + quickstart are blunt: send the full assistant message back – reasoning_content and tool_calls, not only final content.

# After the first completion:
msgs = [
 {"role": "user", "content": "Find the failing test and propose a patch."},
 completion.choices[0].message, # full object, not .content alone
 {"role": "user", "content": "Apply the patch and re-run."},
]
completion2 = client.chat.completions.create(
 model="kimi-k3.1-pro",
 reasoning_effort="high",
 messages=msgs,
)

Strip the chain and the model forgets work you already funded. Same rule if you self-host behind an OpenAI-compatible server – your use keeps those fields or you debug “amnesia” for a day.

Pro tip: Log reasoning_effort, cache hit rate, and output tokens per step for a week before freezing a production default. Default-max is how quiet bills go loud.

Self-host only if the iron is real

The catch is simple: consumer boxes and H100-only hobby nodes don’t load this checkpoint.

Follow engine cookbooks. No single-GPU GGUF fantasy shipped with this release.

License gate people skim past

Broad MIT-style grant for most product embeds and internal use (keep the copyright notice). Two scale triggers from the license text mirrored on the HF repo:

• MaaS: if you offer third-party inference/fine-tune access and affiliate revenue clears $20M in any 12 months, you need a separate Moonshot agreement.
• Name display: above 100M MAU or $20M monthly revenue, show the model name prominently.

Internal use and Moonshot/certified-partner paths sit outside those conditions. Not legal advice – read LICENSE before you productize a public endpoint.

Moonshot also cut cyber-related mid-training and RL data for the open build; their tech blog cites internal xdev-bench-hard pass@3 at 81.0% on the public pipeline vs 90.5% unfiltered. Risk control with a measured quality hit, not a mystery nerf.

Is a frontier MoE still “open” when the practical floor is eight datacenter GPUs and a custom commercial gate for big resellers? That’s the tension worth arguing – more than another screenshot of a bench row.

Next action

Create a Moonshot key. Run the snippet with reasoning_effort="high" on a real repo task. Measure tokens for a week. Start the HF pull only if you already operate B300/GB300-class or MI355X nodes and have a privacy/control reason API can’t cover. Anything else is cosplay.

FAQ

Can I run Kimi K3.1 Pro on a single consumer GPU?

No. Use the API or a host that already bought the rack.

What’s the difference between kimi-k3.1-pro and highspeed?

Same family, same 1M context. You’re buying latency headroom: Highspeed is priced at double the list rate ($4/$20 vs $2/$10 as of early November 2026) for about 2-3× speed. Example: interactive pair-programming in a shared IDE → highspeed; overnight batch refactors that spit thousands of tool steps → standard, because output tokens dominate.

Are the weights truly free for commercial products?

For most internal tools and ordinary product features, yes under the Kimi K3.1 Pro License’s broad grant – keep notices, don’t assume “weights on HF” means “unlimited public resale.” The gotcha is MaaS at scale: cross ~$20M affiliate revenue in a rolling year while selling third-party access, and Moonshot wants a separate deal. Hit 100M MAU or $20M monthly revenue and you must display the name. Builders embedding the model inside their own app without running a general inference business rarely trip that wire; people standing up a drop-in API competitor do. Read the LICENSE on the repo before you invoice strangers for tokens from this checkpoint.