Kimi K3.1 Pro: Prices, Capabilities and Weight Release

On October 24, 2026 Moonshot AI published Kimi K3.1 Pro, the first model of a K3.1 series it describes as a post-trained version of Kimi K3 with substantially more post-training compute. It keeps K3's one-million-token context and native image and video input, ships alongside a Highspeed variant that Moonshot says runs two to three times faster, and costs a third less than K3 on the direct API. The weights are promised by November 4; on October 26 the newest Moonshot repository on Hugging Face was still Kimi K3 from June.

We covered K3 at its July announcement and again when its weights and bespoke licence arrived. K3.1 Pro repeats the pattern: an API launch first, a weight release promised less than two weeks later, and a set of vendor benchmarks that mix harnesses and sources. The difference this time is the price direction. A successor that is cheaper than the model it replaces changes the adoption arithmetic for anyone already paying for K3, and it narrows the gap to the proprietary models Moonshot compares itself with.

This post is for the builder deciding whether to move a coding agent, a document pipeline or a research workflow onto K3.1 Pro now, through the direct API or a router, or to wait for the weights. It goes through what shipped and where, the price table and what it does to a bill, the direct API's contract, the documented differences between the direct and router versions, what Moonshot's benchmark pages do and do not establish, and what remains unknown about the weights until they exist.

The launch post describes two models. Kimi K3.1 Pro is the main release, which Moonshot calls its most capable open-weight model of the three-trillion-parameter class, with a one-million-token context. Kimi K3.1 Pro Highspeed is a faster variant that Moonshot says delivers two to three times the speed of K3.1 Pro; the post does not say how the speed is achieved. Both are live on the same day across the consumer app, the Kimi Work desktop app, the Kimi Code terminal tool and the API platform. A router listed its own route for the model on October 23, a day before Moonshot's research index dates the announcement; a listing is not a launch, and this post uses the vendor's date.

The practical detail is in the availability list. Enterprise administrators have to switch the model on, because it is off by default for organisations at launch. Kimi Work needs version 3.1.0 or later. Kimi Code users pick it with the model command. API users select one of two identifiers, and Moonshot says zero data retention is available to API customers. One example of why the channel matters: a team that trialled K3 inside the consumer app and liked it will find K3.1 Pro there immediately, but the same team's production integration is governed by the API contract in section three, which has rules the app never exposes.

The failure case is the one that always follows a staggered launch. An engineer reads "available today" and raises a pull request switching the production model identifier, while the enterprise administrator has not enabled the model and the account has never topped up. The quickstart is explicit that K3.1 Pro is a flagship model unlocked after a top-up of at least one dollar, and that the cumulative top-up sets the account's rate-limit tier. Check both before the switch.

Moonshot's international pricing page lists three K3-series models, all with the same 1,048,576-token context window, billed pay as you go with no subscription and before tax. The successor is cheaper than its predecessor on every column: $2 against $3 for input, $10 against $15 for output, $0.20 against $0.30 for cached input, and the same proportion on the two cache-write rates. Each is a reduction of one third. Highspeed is priced at exactly twice K3.1 Pro for input, output and writes, while its cached-input rate stays at $0.20.

A worked example makes the direction concrete. Take a hypothetical coding-agent session that sends one million input tokens across its turns and receives two hundred thousand output tokens, with no cache hits. On K3 that is $3 plus $3, or $6. On K3.1 Pro it is $2 plus $2, or $4. On Highspeed it is $4 plus $4, or $8. Caching changes the input side only: if nine hundred thousand of those input tokens were cached reads, K3.1 Pro's input line falls from $2 to $0.20 plus $0.18, about $0.38, before the one-off write charge. Our frontier model price index carries the comparable rates for other labs.

The failure case is the cache. Moonshot stores the cache in blocks, and a partial block that does not fill a whole block is billed as a miss rather than written. A pipeline that varies the first few hundred tokens of every request, say by prepending a timestamp, never fills a reusable prefix and pays the full $2 on every call while the dashboard shows a cache that is technically enabled. The default time to live is five minutes; a workflow with longer gaps between calls needs the one-hour tier, which costs twice as much to write, or it pays the write charge again after every expiry.

The K3.1 Pro quickstart ends with a list it calls important limits, and most of them are departures from what an OpenAI-compatible client assumes. Thinking is always on and cannot be disabled; the only lever is a top-level reasoning-effort field with three values, low, high and max, and max is the default. Sampling is fixed: temperature 1.0, top-p 0.95, one completion, zero penalties, and the guide says to omit them from requests rather than set them. The completion ceiling defaults to 131,072 tokens and can be raised to the full 1,048,576, with the usual caveat that input and output share the window.

Two rules matter most for agents. First, in multi-turn and tool calling loops the complete assistant message must be returned unchanged in the next request, reasoning content included; a client that keeps only the final content field breaks the loop. Second, vision input does not accept public image URLs. Images and video files go in as base64 or as an uploaded file reference, and the content field must be an array of parts rather than a string. An example of the first rule in practice: a tool-use harness that trims assistant messages to save tokens will work on many models and silently degrade on this one, because the model loses its own reasoning between turns.

The failure case is the web-search tool. The guide says it is being updated and is not recommended for production workflows in the near term. A research agent that relies on Moonshot's hosted search through the Formula tool endpoints is building on a component the vendor has flagged; bring your own search tool until the note is removed. Teams that tuned temperature per task elsewhere have no equivalent lever here.

Many teams never call Moonshot directly. They reach the model through a routing service with one key and one billing account, which is convenient and also the source of a specific confusion with this release. Our October 26 catalogue snapshot shows the route for K3.1 Pro listed on October 23 with the same one-million context, a maximum completion of 943,718 tokens, and reasoning described as optional, with a setting of none among the options. Moonshot's own guide says thinking is always on. These are two documents about what is, at the provider's end, one model; the router's metadata describes its request schema, not a different model, and it does not override the provider's contract.

The second trap is the alias. The router's "latest" alias for Moonshot models still resolves to K3, not K3.1 Pro, in the same snapshot, so a team relying on it for free upgrades will not get this one, and a team assuming it moved will benchmark the wrong model. Pin the exact versioned identifier on whichever door you use, and check the route's own price before publishing a comparison: the $2 and $10 figures here are the direct API's.

The example that shows the difference: an evaluation harness sends the same prompt through both doors with reasoning set to none on the router. What the provider does with that parameter is not documented on the router's page, the two responses differ in latency and token counts, and the team concludes the router's version is "worse". It is the same model behind an undocumented request translation. Run comparisons through the door you will ship.

The launch post leads with Terminal-Bench 4.0, where Moonshot reports 65.7% for K3.1 Pro against 58.2% for GPT-6 Astra and 66.4% for Claude Opus 5.5. The footnote is the part to read. K3.1 Pro was run with the Claude Code harness; the competitor figures are the higher of each lab's own post or the public leaderboard. That is a legitimate way to present a vendor's result and it is not a controlled comparison, because the harness, the effort setting and the run count differ by column. The same pattern holds for the 3D reconstruction benchmark, BenchCAD, where the 92.7% with-tools score sits beside figures lifted from Anthropic's and OpenAI's own reports, and for the finance benchmark OfficeQA Pro v2, where Moonshot reports 64.4 and notes that some rival trajectories were zeroed for fetching answers online.

The hallucination claim deserves its own warning. The launch post says the claim-level hallucination rate on Moonshot's internal hard set fell from 23.4% for K3 to 8.3%, with the share of responses containing an error at 42.4% of K3's. The API quickstart, which describes its set differently, as de-identified conversations where users had flagged factual errors, but reports the same K3 baseline to two decimals, prints 23.35% to 6.85% and 46.4%. Both pages add that the set is a deliberate stress test and the rates are not everyday error rates. Two different figures for one claim on two vendor pages is a reason to print neither as a headline, and we have not. Our K3 evaluation guide explains how to run a factual check on your own prompts instead.

What the evidence does establish is narrower and still useful. Moonshot's own internal long-horizon coding benchmark moved from 55.95 to 61.2 between K3 and K3.1 Pro, a within-vendor comparison, though footnote 7 states only that K3.1 Pro ran in a Claude Code harness and other models at their maximum effort setting, so even this pair is not documented as same-harness. The cybersecurity section reports that removing cyber-related data from training cut the model's score on an in-house exploitation benchmark from 90.5% to 81.0% at pass@3, and states that the released model remains behind frontier proprietary models on that axis. None of this ranks K3.1 Pro against its rivals on your workload. Compare it with other models on price, contract terms and your own tasks for that reason, not on mixed benchmark tables.

Moonshot organises the release around four kinds of work. Coding covers the full range from a quick fix in an existing repository to a complete project, with specific attention to game engines, Three.js scenes and front-end polish. 3D creation is the new emphasis: the post describes parametric modelling of mechanical parts, architecture and configurable products, with the model writing and running scripts for tools such as Blender and CAD software rather than relying on connectors, and a consumer-facing 3D Make tool that previews, edits and exports models. Finance covers end-to-end workflows across documents and spreadsheets. The fourth is multimodal input: the API accepts images and video files as input, which is understanding, not generation. K3.1 Pro does not produce video, and a reader who arrives from a video-model headline should leave with that distinction.

One example from the post shows what long-horizon means here. Moonshot says that in an internal test the model built a walking simulator on an open-source anatomical model and, when reward shaping failed, probed the simulator's dynamics and corrected 36 errors in moment-arm calculations before retraining. It is a vendor anecdote, not a benchmark; its value is the shape of the behaviour, diagnosing a tool rather than tuning a reward.

The failure case is scope creep from the feature list. A team reads "3D creation" and plans a product on the API's ability to emit CAD scripts, without checking that the with-tools benchmark figure came from a coding harness with a sandbox, file system and tool loop the team would have to rebuild. Capability shown in Kimi Code or the consumer app is capability in that environment. The API gives you the model and the contract; the scaffolding is yours, and our K3 capabilities guide covers what the long context and effort settings do once it exists.

The launch post states twice that the full model weights will be released by November 4, 2026. On October 26 the Moonshot organisation on Hugging Face listed Kimi K3, created in June, as its newest model repository, with nothing for K3.1. So the open-weight description in the launch post is a statement of intent with a date, and three things a self-hosting team needs are not yet knowable: the licence, the download size and the hardware requirement. K3's weights arrived with a bespoke licence that our earlier post on the K3 licence restrictions walks through, including a revenue trigger for resellers and attribution rules. K3.1 Pro may inherit those terms, may loosen them, or may tighten them; none of the three is documented yet.

The post does say one thing about the open-weight version that is worth holding onto. Moonshot writes that it removed cyber-related data from both the mid-training corpus and the reinforcement learning environments specifically for the open-weight release, and frames the decision as a principle: not to release weights that would extend the frontier of offensive cyber capability, while raising the capability available in open weights gradually. For a security team evaluating the model for defensive code audit, the relevant consequence is that the released checkpoint is, by Moonshot's account, weaker on exploitation tasks than an unfiltered checkpoint from the same pipeline. That is a stated design choice, not a measured guarantee.

The failure case is planning hardware on the predecessor. K3 sits in the same parameter class and its weights were a very large download, so it is tempting to assume K3.1 Pro will match and order capacity. Wait for the repository: file sizes and the licence text can be read from it once it is published, and any quantised variants will be separate releases to check. One housekeeping date from the pricing page: K2-series models close to newly registered users from October 31, 2026, with retirement planned by the end of December.

For a team already paying for K3 on the direct API, the decision is close to made: the successor costs a third less on every rate, shares the context window and the caching rules, and the contract differences are small. The one check is the always-on thinking. A workload that used K3 with reasoning switched off, where that was possible through a particular door, will see different latency and token counts, and the effort setting is the only lever. Move one workflow, compare the usage object, then move the rest.

For a team on another lab's model, the question is what the price buys. At $2 and $10 the direct rates sit below several proprietary frontier models and above the cheapest open-weight options, and the vendor benchmarks do not settle quality for any particular task. The method that works is the one our three-way open-model comparison used: a fixed set of your own tasks, the same harness, the door you will ship through, and a cost line computed from the usage object rather than from the price table. This is the evaluation our AI transformation team runs before recommending a model switch, and it takes days, not weeks.

For a team that wants weights, wait. Confirm the repository and licence when the promised weights arrive, due by November 4; using K3's licence and file size to plan K3.1 Pro deployment could lead to the wrong assumptions. The router question has its own answer: pin the versioned identifier, read the router's own metadata as a schema description rather than a model description, and verify the price on the route the day you publish a comparison, because catalogue prices move independently of the vendor's. Our Kimi, Opus 5.5 and GPT-6.1 Sol comparison works through direct API costs, cache writes and context thresholds.