Kimi K3.1 Pro: Pricing, Benchmarks, Open Weights and API Quickstart

The short answer

Kimi K3.1 Pro is Moonshot AI’s October 23, 2026 post-training upgrade of Kimi K3: a 2.8T-parameter mixture-of-experts model with 104B active parameters, a 1M-token context window, and API prices of $2.00 per million input tokens, $10.00 per million output tokens and $0.20 per million cached input tokens. A Highspeed variant, advertised as 2–3× faster, costs exactly double on regular input and output and the same on cache hits. Moonshot says the full weights will be released by November 4, 2026. As of October 29, 2026 the Hugging Face repository for the model is not publicly reachable.

On Moonshot’s own 14-panel chart the model leads on six rows, is second on five, third on two and fourth on one against Claude Opus 5.5, Claude Fable 5.1, GPT-6 Astra, DeepSeek V4.1 Flash 1017 and GLM-5.3. Artificial Analysis, an independent evaluator, placed it fourth on its Intelligence Index at launch with a score of 55, and its highest-ever Terminal-Bench 4.0 result at 67%. A few days later Artificial Analysis moved to Index v5, which scores the model 46 and leaves it as the top open-weights model on that scale, with weights not yet released.

This guide is built from first-party sources: the Moonshot tech blog, the Kimi pricing page, the API quickstart, the rate-limit page and the launch post on X, plus two independent sources, Artificial Analysis and the OpenRouter listing. Every figure was checked on October 28–29, 2026. Where a number comes from Moonshot it is labeled Moonshot-reported, and nothing here is a reproduction by this site. For the earlier K3 release and the open-weights story behind it, see our Kimi K3 open frontier intelligence article.

The launch posts

Moonshot’s account posted the announcement at 17:15 UTC on October 23. The lead post names the model as “our most capable 3T-class open-weight model” and lists its specifications in one block: a 1M-token context, 2.8T total and 104B active parameters, multimodal input, full-project coding in Unreal, Unity and Godot, parametric 3D modeling in Blender and CAD, and finance work with hallucination “down by 65%.” It ends with the line that matters for builders: “Open weights by Nov 4, 2026.” The post was captured with roughly 4.06 million views.

The 65% figure in the post is a rounding of the blog’s claim-level hallucination rate on Moonshot’s internal Kimi Hallu Bench Hard, which fell from 23.4% for K3 to 8.3% for K3.1 Pro (a 64.5% relative drop). The blog adds that the benchmark is a stress test built to provoke errors and that the rates “do not represent overall error rates in daily use.” That caveat belongs next to the headline number.

Four seconds later the account posted the API announcement, with a pricing card attached, and the card is reproduced in the pricing section below.

What shipped and where

K3.1 Pro is described in the blog as “a post-trained version of Kimi K3, with substantially larger post-training compute,” and as the first model in a new K3.1 series. Moonshot attributes the gains to joint reinforcement learning across hundreds of downstream domains and to infrastructure work on the RL framework, long-context inference, sandboxes and rollout scheduling. The base architecture is therefore the one from K3; what changed is the training after pre-training. That framing matters for your expectations: it is a capability upgrade at an unchanged size, not a new model class.

The blog lists five access routes. Each one is a different product with different billing, so it helps to separate them before comparing prices.

Two details from the blog are easy to miss. Zero Data Retention is available to API customers, and Kimi Enterprise administrators have to switch the model on for their organization because access is off by default. For a desktop-agent angle on the same family, our Kimi Work desktop agent post covers the earlier product.

Pricing and cost math

API pricing is flat across the context window, with no long-context surcharge tier. The table below is taken from Moonshot’s pricing page, rates checked by Moonshot on October 24 and the page updated October 26. Both models list a 1,048,576-token context window.

Highspeed doubles the regular-input, output and cache-write rates and leaves the cache-hit rate where it is. That asymmetry decides the economics of agent loops. In a long coding session most input tokens are repeated context that hits the cache, so the Highspeed premium falls mostly on output. The worked examples below use only the published rates; the token counts are illustrative assumptions, not measurements. They treat the uncached part as 5-minute cache writes, which cost the same as regular input on both models.

Two lessons fall out. First, the cache is worth more than the model choice: the same long run costs $0.314 with cache hits and $0.80 without, a 2.5× difference, while the Highspeed premium on the cached run is $0.26. Second, Highspeed costs 1.83× standard on the cached long run, not 2×, because the $0.20 cache-hit rate does not double. Moonshot’s own page says to price cached-heavy requests separately rather than doubling the standard bill. Output length is the other lever: output is the most expensive token class, and the quickstart states that K3.1 Pro always has thinking enabled, with reasoning_effort accepting low, high or max, and max as the default. Lower effort on easy tasks is the direct way to cut output tokens, though Moonshot publishes no data on how much quality that costs.

For the consumer side, Moonshot lists personal plans at $15 (Plus), $31 (Pro), $79 (Max) and $159 (Ultra) per month on annual billing, effective monthly. Kimi Code access starts at Plus, and Highspeed is included from Pro. A membership does not replace API billing; the API charges tokens separately. For a wider price comparison of coding models, see our cheapest AI coding models roundup.

Benchmarks, labeled

The chart below is Moonshot’s launch scorecard, posted with the launch thread. Everything on it is Moonshot-reported. The footnotes on the blog explain how: Kimi K3.1 Pro results use reasoning effort max, temperature 1.0 and top-p 0.95, and coding rows use the Claude Code harness. Competitor scores are, in the blog’s wording for several rows, “the maximum value reported in either their blog posts or the official leaderboard,” or are taken from each vendor’s system card or technical report. The chart’s own footnote says all models were maxed out on thinking effort, that Claude models may include fallbacks and that GPT models may include cyberguards.

The table below transcribes each panel into text so the numbers are searchable and comparable. Values were read from the chart image; the Terminal-Bench 4.0, Kimi Code Bench, BenchCAD, OfficeQA and Opus/Astra figures that also appear in the blog text matched. “Rank” is Kimi’s position among the models shown in that panel.

Counting rows gives a straightforward picture: Kimi leads six of fourteen panels, is second on five, third on two and fourth on one. The lead rows cluster around long-horizon software work (SWE Marathon), document and finance tasks (OfficeQA Pro v2, GDP.pdf), agentic exams and multimodal reasoning with tools. The trailing rows cluster around terminal-driven science work, CAD generation and computer use. Moonshot’s own prose is more careful than the chart: the blog says K3.1 Pro “matches or approaches the strongest proprietary models,” which is accurate to the table, and describes Terminal-Bench 4.0 as “narrowly behind Claude Opus 5.5.”

Three cautions apply before you reuse the table. One, several panels mix evaluation sources: Moonshot ran Kimi itself and took some competitors’ numbers from leaderboards or system cards, so a gap of one or two points sits inside the noise of differing harnesses. Two, Kimi Code Bench is Moonshot’s own benchmark, which makes it informative about the Kimi Code product and weak as an independent comparison. Three, one row, GPT-6 Astra on OfficeQA Pro v2, was run in Codex while the others used Claude Code, which the blog states. Compare rows only when you also compare their footnotes.

Independent evidence

Artificial Analysis published a launch article on October 23 and then announced Intelligence Index v5 on October 27. The two use different indices, so their headline numbers are not interchangeable.

Three things stand out. The first is agreement on the headline strength. Moonshot’s chart puts K3.1 Pro at 65.7 on Terminal-Bench 4.0 with the Claude Code harness; Artificial Analysis measured 67% under its own setup and called it the highest score of any model it tracks. Two different harnesses landing within 1.3 points is the most convincing cross-check available. The second is the cost line: a 14% increase in output tokens against a 33% price cut yields a cost per task roughly equal to K3, which is the practical meaning of “cheaper” here. Artificial Analysis states that K3.1 Pro costs about the same per task as its predecessor, not less.

The third is the gap between the two indices. Under the launch-time index the model ranked fourth at 55, three points below Opus 5.5. Under v5, where Artificial Analysis says 60% of the index uses private datasets, the score is 46 and the distance to the leader is 12 points. Artificial Analysis describes v5 as a methodology change, so the drop is a re-scaling, and it does not mean the model got worse. It does show that the “near the frontier” reading depends on which benchmark set is used, and that the largest gaps in v5 are on Terminal-Bench-Science and HLE-Diamond. That matches the Moonshot chart, where Terminal-Bench Science is the one row where Kimi is fourth.

The cyber controls

The blog devotes a long section to cybersecurity, and it is the most unusual part of the release. Moonshot says it found cyber-related content in the general mid-training corpus and in the reinforcement-learning environment mix, removed it from both stages for the open-weight release, and measured the effect on its in-house xdev-bench-hard benchmark. The benchmark uses expert-curated, source-code-based vulnerability discovery and exploitation tasks, mostly reproductions of recently disclosed bugs in software such as the Linux kernel, Node.js, JavaScriptCore, Exim and VirGL, with mitigations enabled. Results are pass@3.

The numbers Moonshot states in prose are clear. A checkpoint without the risk-reduction measures solves 90.5% of problems at pass@3; the final K3.1 Pro solves 81.0%. The final model is far above K3 (33.3% in the image), which Moonshot reads as evidence that stronger general coding and long-horizon debugging generalize to cyber tasks even after data removal. Moonshot also says the model’s cyber capability “remains behind that of frontier proprietary models that have been publicly available for at least three months,” and states its open-weight principle: not to release weights that extend the absolute frontier of cyber capability, while progressively raising what open weights offer.

For builders the practical reading is limited. This is a single internal benchmark with a harness that varies by row, the evaluator is the developer, and the weights are not yet available for anyone to check the claim. It is useful as a statement of intent and as a comparison between Moonshot’s own checkpoints, where the controlled difference of 90.5 versus 81.0 is the cleanest evidence. It is weaker as evidence that the released weights are safe in any particular deployment.

API quickstart

The Kimi quickstart uses the OpenAI Python SDK against Moonshot’s OpenAI-compatible endpoint. You need a key from the Kimi API platform and, per the rate-limit page, a minimum recharge of $1 before the account can call the API. The snippet below follows Moonshot’s example, with reasoning_effort set explicitly.

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",          # or "kimi-k3.1-pro-highspeed"
    reasoning_effort="high",        # low | high | max (default: max)
    messages=[{"role": "user", "content": "Introduce Kimi K3.1 Pro in one sentence."}],
)
print(completion.choices[0].message.content)

The same request with cURL:

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",
    "messages": [{"role": "user", "content": "Introduce Kimi K3.1 Pro in one sentence."}]
  }'

A few behaviors from the quickstart matter in practice. K3.1 Pro always runs with thinking on, and streaming responses deliver separate reasoning_content and final-answer content deltas. For multi-turn conversations and tool calls, the docs say to add the complete assistant message returned by the API to the next request rather than keeping only content; dropping the reasoning part is the likeliest cause of degraded tool-call behavior in a hand-rolled loop. Input accounting follows the pricing page: cache hits, cache writes and uncached tokens are mutually exclusive and add up to total input, so the usage fields let you reconcile a bill line by line.

Using it from coding agents

Moonshot documents two harness integrations for K3.1 Pro. Both are first-party instructions; neither has been run by this site.

The Kimi Code page gives this settings.json block for the 1M-context configuration. Replace the placeholder with your own key and restart Claude Code after editing; Moonshot says to pick one configuration method and not mix a settings file with exported variables.

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.kimi.ai/coding/",
    "ANTHROPIC_API_KEY": "Your API Key",
    "ANTHROPIC_MODEL": "k3.1-pro[1m]",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "k3.1-pro[1m]",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "k3.1-pro[1m]",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "k3.1-pro[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "k3.1-pro[1m]",
    "CLAUDE_CODE_SUBAGENT_MODEL": "k3.1-pro[1m]",
    "CLAUDE_CODE_EFFORT_LEVEL": "high",
    "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1048576",
    "CLAUDE_CODE_MAX_CONTEXT_TOKENS": "1048576"
  }
}

The Kimi Code page ties the available context to the plan: Plus members get k3.1-pro with a 262,144-token limit, while Pro and above get the 1,048,576-token limit and access to k3.1-pro-highspeed. The platform guide for Claude Code is a separate document for pay-as-you-go keys, and the version we read still uses kimi-k3[1m] in its example. If you route through that endpoint, confirm the K3.1 Pro model ID with a test call before you rely on it. For Codex, Moonshot’s guide gives this provider block and explains that model_context_window must match the 1M window or Codex falls back to default model metadata.

model = "kimi-k3.1-pro"
model_provider = "kimi"
model_context_window = 1048576

[model_providers.kimi]
name = "Kimi"
base_url = "https://api.moonshot.ai/v1"
env_key = "KIMI_API_KEY"
wire_api = "responses"

If you already run Claude Code with another model, our Claude Code best-practice guide covers the harness itself, and best AI coding agents 2026 compares the agents you might pair K3.1 Pro with.

OpenRouter

K3.1 Pro is listed on OpenRouter as moonshotai/kimi-k3.1-pro with a release date of October 23, 2026 and a 1.0M context. At capture on October 28 the listing showed one provider route for the standard model, Moonshot AI, at $2.00 input, $10.00 output and $0.20 cache read per million tokens, with a 4.56-second latency, 26 tokens per second and 100% uptime. Moonshot AI Highspeed was listed at $4.00, $20.00 and $0.20, with 4.36 seconds, 66 tokens per second and 99.97% uptime. These are point-in-time operational statistics from a marketplace, not a benchmark, and they move.

Two numbers on the page are worth reading as signals of real use. OpenRouter showed a weighted-average input price of $0.3546 per million tokens against the $2.00 list price, and a cache hit rate of 91.4% for the Moonshot route. That is consistent with the cost math above: agentic traffic is dominated by cached context, so the price people actually pay per input token sits far below the list rate. It also means you should model your own cache behavior before you compare K3.1 Pro with another model on list price alone. The Highspeed route’s 66 tokens per second against 26 for standard is roughly 2.5× on this snapshot, inside the 2–3× range Moonshot advertises.

Open weights: out yet?

The promise is specific and repeated. The blog says full weights “will be released by Nov 4, 2026,” the launch post says “Open weights by Nov 4, 2026,” and the OpenRouter and Artificial Analysis pages both describe the model as open-weight while noting that the weights are not yet published. Artificial Analysis expects it to become the leading open-weights model once they are.

On October 29, 2026 at about 05:06 UTC we requested the Hugging Face page and the Hugging Face API for moonshotai/Kimi-K3.1-Pro and for a possible Kimi-K3.1-Pro-Base. Both returned HTTP 401 for the page and the API. By contrast the earlier moonshotai/Kimi-K3 page returned 200, and a list of the organization’s newest repositories showed K3, K2.7-Code and K2.6 with no K3.1 entry. A 401 can also mean a private or gated repository, so the safe conclusion is only that the weights were not publicly downloadable at that time and the November 4 deadline had not yet arrived. We did not find a license text, a parameter-format description or a hardware guide for the weights, so none is stated here. Check the repository again after November 4 before planning a self-hosted deployment; a 2.8T-parameter model needs multi-node infrastructure regardless of license.

One more caution on the phrase “open-weight.” Moonshot says it removed cyber-related data from both training stages “for the open-weight release.” The hosted API model and the released checkpoint are described as the same K3.1 Pro, but the blog does not say whether hosted serving adds any other controls. Treat behavior differences between the API and a self-hosted copy as a thing to test, not assume.

Rate limits and subscription quota

The API rate limits depend on cumulative recharge. The table is from the platform’s limits page; the page applies the limits per account, and notes that limits may be temporarily adjusted when cluster load reaches capacity.

Vouchers do not count toward cumulative recharge, a $5 recharge earns a $5 voucher, and the page warns that abnormal activity triggers a risk-control limit that cannot be lifted. Exceeding a limit returns HTTP 429 with X-RateLimit-* headers on the search endpoints. The limits page does not break limits out by model, so we cannot say whether K3.1 Pro has a lower ceiling than other models on the platform.

Subscription quota is a separate system. The Kimi Code membership docs say that for new members the weekly quota limit is removed and only a rolling 5-hour rate window plus a monthly total remain, while legacy plans refresh every seven days; all devices and API keys on an account share one quota, and an Extra Usage balance can be bought to continue past it. Two days after launch Moonshot also posted an apology that is directly relevant if you rely on the subscription.

The post says the reset restores 25% of the monthly quota, “equal to one week of usage,” and that Moonshot adjusted the plan’s parameters and is “reducing unnecessary subagent calls and output length.” It is a first-party admission that quota burn at launch was higher than intended, and it shows that subagent fan-out was one of the causes. If you run agents on a subscription, track consumption in the Kimi Code console and treat the first week of numbers as unsettled. The Codex-side equivalent story is in our Codex out-of-usage resets guide.

Claim and evidence table

Each headline claim, who made it, and how strong the evidence is.

Which variant, which route

The decision is mostly about who is waiting on the output and whether your prompts are cache-heavy.

A short evaluation plan keeps the decision grounded in your own work. First, pick twenty tasks you already run, with a mix that resembles the rows where Kimi leads (long multi-file software changes, document-heavy finance or office tasks) and the rows where it trails (terminal-driven science work, CAD, GUI automation). Second, hold the harness constant; if you test Kimi in Claude Code, test the comparison model in Claude Code too. Third, record cost per completed task including cache hits, since the list price hides the biggest variable. Fourth, run each task at high and max effort to see whether the extra thinking pays for itself. Fifth, wrap any agent that holds credentials or touches production in human confirmation for irreversible actions; nothing in the launch material changes that rule.

Limitations

• Every benchmark on Moonshot’s chart and blog is vendor-reported. This guide read the images and cross-checked values against the blog text; it did not rerun a single benchmark and no hands-on testing of the model was done.
• The benchmark transcription comes from reading a rendered image. The eight values that also appear in the blog text matched; the rest could not be checked against text, and the xdev table values (other than 81.0 and 90.5) come only from the image.
• The independent evidence is Artificial Analysis alone, plus OpenRouter’s operational statistics. The two Artificial Analysis articles use different index versions and cannot be compared directly.
• The open-weights status is based on one set of requests on October 29, 2026. A 401 does not prove the repository does not exist, and the weights may appear at any time before or on the deadline.
• No license, no hardware requirements, no weight format and no model card were found for the weights. None is guessed here.
• The Claude Code and Codex configurations were copied from Moonshot’s documentation and not executed. The two Claude Code guides use different endpoints, and the platform guide’s example does not target K3.1 Pro.
• Subscription quotas are described only qualitatively; no absolute token allowances per plan were published in the material we read, and Moonshot adjusted plan parameters on October 25.
• Cost examples use assumed token counts and published list prices. Your bill depends on your cache hit rate, your effort setting and the 1-hour cache-write surcharge if you use it.

Verdict

Kimi K3.1 Pro is a credible near-frontier coding and agent model at a clearly stated, below-frontier price. The strongest evidence is the agreement between Moonshot’s Terminal-Bench 4.0 number and Artificial Analysis’s independent one, plus an independent measurement that cost per task is about equal to K3 while prices fell by a third. The weakest evidence is everything Moonshot measured on its own benchmarks, including Kimi Code Bench, the hallucination figures and the cyber-control results. The open-weights promise is the biggest open item: it is specific and dated, and it cannot be judged until the repository is public.

If you build agents, the sensible move now is a bounded trial through the API or OpenRouter, using cache-aware cost tracking and your own tasks, and a recheck of the Hugging Face repository after November 4. If you need self-hosting, wait for the weights and read the license first. If you live on a subscription, watch your quota in the first weeks given the October 25 apology.

FAQ

Sources

Sources checked October 28–29, 2026.

• Kimi on X — launch post, API and pricing post, October 25 quota apology and the launch video post
• Introducing Kimi K3.1 Pro — Moonshot tech blog (specifications, benchmarks, footnotes, cybersecurity section, availability)
• Kimi K3.1 Pro pricing — membership plans and API costs
• Kimi K3.1 Pro API quickstart and Recharge and rate limiting
• Kimi Code: Claude Code setup, Kimi API platform: Claude Code guide, Kimi API platform: Codex guide and Kimi Code membership
• Artificial Analysis — Kimi K3.1 Pro launch benchmarks and the Intelligence Index v5 announcement (October 27, 2026)
• OpenRouter — moonshotai/kimi-k3.1-pro
• Hugging Face — moonshotai/Kimi-K3.1-Pro (status check, HTTP 401 on October 29, 2026)

Related reading: Kimi K3 open frontier intelligence, Muse Wonder guide, Claude Opus 5.5 vs Sonnet 5.5 for coding and GPT-6 Astra vs Sol vs Luna pricing and usage.