Kimi K3.1 Pro: API, pricing, benchmarks, and what the open weights will need

Moonshot AI released Kimi K3.1 Pro on 23 October 2026: a post-trained Kimi K3 with a 1M-token context, available now through the Kimi API as kimi-k3.1-pro and a faster kimi-k3.1-pro-highspeed, with full weights promised by 4 November. Artificial Analysis puts it fourth on its Intelligence Index, three points behind the top proprietary model, at 2 per million input tokens and 10 per million output tokens.

This article is for engineers deciding whether to point an agent or a coding tool at it. It covers what the model is, what it costs, what the benchmarks do and do not show, how to call it — including the one multi-turn rule that breaks tool loops if you miss it — what Moonshot removed from training before the open release, and what running the weights will take.

What is Kimi K3.1 Pro?

Kimi K3.1 Pro is Kimi K3 with "substantially larger post-training compute", not a new base model. Moonshot's technical post describes large-scale joint reinforcement learning across hundreds of downstream domains, and The Decoder reports the dimensions are unchanged from K3. It is the first model in a new K3.1 series.

That means the architecture is K3's, which Moonshot documents in the Kimi-K3 repository: a mixture-of-experts model with 2.8T parameters and 104B active, 93 layers mixing 69 KDA and 24 gated MLA attention layers, 896 experts with 16 routed per token plus 2 shared, a 1,048,576-token context, and the MoonViT-V2 vision encoder. K3's weights are MXFP4 with MXFP8 activations, trained quantisation-aware from SFT onwards.

How much does Kimi K3.1 Pro cost?

Kimi K3.1 Pro costs 2 per million input tokens, 10 per million output tokens and $0.20 per million cache-hit tokens — a third cheaper than K3 on all three, per Artificial Analysis. Highspeed doubles the input and output price for what Moonshot calls 2–3x the speed. Simon Willison notes the standard price is half that of Claude Opus 5.5.

Per-token price is only half the bill. Artificial Analysis measured 55K output tokens per Intelligence Index task, about 14% more than K3's 48K, so its cost per task came out at 1.98 — roughly what K3 cost. The [quickstart](https://platform.kimi.ai/docs/guide/kimi-k3-1-pro-quickstart) also notes that access unlocks after a top-up of at least 1, that rate limits rise with cumulative top-up, and that caching is automatic with a 5-minute default TTL (1h is available through prompt_cache_options.ttl).

Kimi K3.1 Pro benchmarks: how close to the frontier?

On the independent Artificial Analysis Intelligence Index, K3.1 Pro scores 55, up 11 from K3 and behind only Claude Opus 5.5, Claude Sonnet 5.5 and Muse Wonder Full. If the weights ship as planned it becomes the highest-scoring open-weights model, narrowing the open-versus-proprietary gap on that index from 12 points to 3.

Moonshot's own table, reproduced by The Decoder, is closer to a split decision. These are vendor numbers at reasoning effort max, temperature 1.0 and top-p 0.95, not independent runs:

Two things are worth reading out of it. Agentic coding is where K3.1 Pro moved most: Artificial Analysis's own Terminal-Bench 4.0 run gave it 67%, up from K3's 13%. And ExploitBench is the one row where it trails clearly, which is deliberate — see the section on cyber data below. Moonshot also reports its internal claim-level hallucination rate falling from 23.4% to 8.3%, but calls that benchmark a stress test rather than a general error rate.

How to call the Kimi K3.1 Pro API

The Kimi API is OpenAI-compatible: point the OpenAI SDK at https://api.moonshot.ai/v1, use MOONSHOT_API_KEY, and set model to kimi-k3.1-pro. The quickstart lists the rules that differ from other OpenAI-compatible providers:

• Thinking is always on. reasoning_effort takes low, high or max and defaults to max; it cannot be turned off.
• Sampling is fixed. temperature 1.0, top_p 0.95, n 1 and both penalties are set by the server; the docs say to omit them.
• Output budget. max_completion_tokens defaults to 131,072 and can go up to 1,048,576.
• Images must be base64 or an uploaded ms://<file-id>; public image URLs are not supported.
• Web search is "being updated" and not recommended for production.

curl https://api.moonshot.ai/v1/chat/completions \  --header "Authorization: Bearer $MOONSHOT_API_KEY" \  --header "Content-Type: application/json" \  --data '{    "model": "kimi-k3.1-pro",    "reasoning_effort": "low",    "messages": [{"role": "user", "content": "Name one risk of 0-RTT in TLS 1.3."}]  }'

Reasoning comes back in a reasoning_content field beside content. The OpenAI SDK does not declare that field, so read it with getattr, as the thinking-models guide shows. In a stream, reasoning arrives first and content starts when it ends.

The multi-turn rule that breaks tool loops

For kimi-k3.1-pro and kimi-k3, you must send back the complete assistant message — including reasoning_content — on every following turn and in every tool-call loop. The thinking-models guide calls this required. Code written for other providers often rebuilds the assistant turn from content and tool_calls only; that drops the reasoning, and the conversation breaks.

Here is a complete tool loop that does it correctly. It appends the SDK's message object as-is, which keeps every field the API returned:

import jsonimport os from openai import OpenAI  # pip install 'openai>=1.0' client = OpenAI(api_key=os.environ["MOONSHOT_API_KEY"], base_url="https://api.moonshot.ai/v1") tools = [{    "type": "function",    "function": {        "name": "get_weather",        "description": "Get the weather for a city",        "parameters": {            "type": "object",            "properties": {"city": {"type": "string"}},            "required": ["city"],        },    },}] def get_weather(city: str) -> str:    return json.dumps({"city": city, "weather": "sunny", "temperature_c": 24}) messages = [{"role": "user", "content": "Is it warmer in Lisbon or Oslo today?"}] while True:    resp = client.chat.completions.create(        model="kimi-k3.1-pro", reasoning_effort="low", messages=messages, tools=tools,    )    msg = resp.choices[0].message    messages.append(msg)  # the whole message: content, reasoning_content, tool_calls    if not msg.tool_calls:        break    for call in msg.tool_calls:        args = json.loads(call.function.arguments)        messages.append({"role": "tool", "tool_call_id": call.id, "content": get_weather(**args)}) print((getattr(msg, "reasoning_content", None) or "")[:200])print(msg.content)

The cost of keeping reasoning is that it stays in the context window and is billed as input on every request, as the guide notes. On long agent runs, keep reasoning_effort at low for routine steps and reserve max for the hard ones; prompt caching softens the repeated history.

If you use Kimi Code rather than the API, the model is selectable with /model. Migrating from K3 is a model-name change: K3 already uses reasoning_effort and the same multi-turn rule.

Why Moonshot removed cyber training data from K3.1 Pro

Before the open-weight release, Moonshot says it identified and removed cyber-related data from both mid-training and RL, while keeping general coding tasks. Its stated aim, per The Next Web, was to avoid pushing "the limits of what freely available models can do" — open weights cannot be recalled once downloaded.

So the removal cost about 9.5 points on that test, and the released model is still far stronger than K3. Moonshot says its cyber capability "remains behind" frontier proprietary models that have been public for at least three months. All of these numbers are Moonshot's own and unverified. For defenders, the practical reading is simple: an open model at roughly this level is about to be downloadable, so the time between a disclosure and a working exploit keeps shrinking.

Can you self-host Kimi K3.1 Pro?

Not yet — the weights are due by 4 November — and when they arrive, expect K3's hardware bill. The vLLM recipe for K3 asks for at least 8x NVIDIA GB300 (CUDA 13 image, r580+ driver) or 8x AMD MI355X/MI350X, with multi-node recommended for production. This is a data-centre deployment, not a workstation one.

vllm serve <MODEL_PATH> \  --served-model-name moonshotai/Kimi-K3 \  --tensor-parallel-size 8 \  --kv-cache-dtype fp8 \  --enable-prefix-caching \  --trust-remote-code \  --enable-auto-tool-choice --tool-call-parser kimi_k3 --reasoning-parser kimi_k3 \  --host 0.0.0.0 --port 8000

Two notes from the same recipe matter for agents. K3 "sometimes emits a format its parser doesn't expect" for tool calls, so validate arguments against the schema and retry. And Moonshot's repository also recommends SGLang and TokenSpeed; check those if vLLM is not your stack.

For most teams the realistic choices on 4 November are the Kimi API, a third-party host serving the open weights, or a self-hosted cluster you already own. The licence decides which of those is allowed for your use — and it has not been published.

Should you use Kimi K3.1 Pro?

• To do: Run your own agent evals against it before switching; the vendor table is a split decision and your workload is not a benchmark.
• To do: Fix tool loops to append the complete assistant message, reasoning_content included.
• To do: Remove temperature, top_p and penalty parameters from Kimi requests.
• To do: Set reasoning_effort per call; max is the default and the most expensive.
• To do: Validate tool-call arguments against the schema and retry on a parse failure.
• To do: If you need the open weights, wait for the licence and model card before planning hardware.
• To do: Check data-handling terms; Zero Data Retention is offered to API customers, and Kimi Enterprise admins must enable the model first.

Sources and further reading

• Moonshot AI: Introducing Kimi K3.1 Pro and the technical post
• Kimi API: K3.1 Pro quickstart and thinking models guide
• Artificial Analysis: Kimi K3.1 Pro launch benchmarks
• Kimi-K3 repository and model card and the vLLM recipe for Kimi-K3
• Simon Willison: Introducing Kimi K3.1 Pro
• The Decoder and The Next Web launch coverage