Kimi K3.1 Pro released: 2.8T/104B MoE with 1M context, API live
According to a Marktechpost report on October 23, 2026, Moonshot AI released Kimi K3.1 Pro, the first model in the K3.1 series, using a 2.8T total-parameter, 104B activated-parameter MoE structure, supporting a 1M-token context, and now live on the Kimi API, with API pricing lower than K3 and open weights expected in November 2026. Its self-reported benchmarks are near the frontier on coding, but clearly behind on scientific terminal tasks.
What changed
According to a Marktechpost report on October 23, 2026, Moonshot AI released Kimi K3.1 Pro, the first model in the K3.1 series, as a post-trained version of K3, reported to have substantially increased post-training compute and joint reinforcement learning across hundreds of downstream domains. The source says the model has 2.8T total parameters and 104B activated parameters (MoE); the base K3 architecture uses Kimi Delta Attention and Attention Residuals, activates 16 of 896 experts through Stable LatentMoE, supports a 1M-token context, and the API can accept text, images, and video. A Highspeed variant was also released at the same time, which the official blog says is 2 to 3 times faster. The API identifiers are kimi-k3.1-pro and kimi-k3.1-pro-highspeed, with an OpenAI-compatible endpoint. The report cites sources saying API pricing is lower than K3, with cache hits billed separately; open weights have not yet been released and are expected in November 2026. Benchmark figures are all self-reported by Moonshot and mostly obtained at maximum reasoning effort and under a Claude Code harness: Terminal-Bench 4.0 at 65.7%, SWE-Marathon at 51.7, Terminal-Bench Science 0.1 at only 38.1, and on the internal Kimi Hallu Bench Hard, assertion-level hallucination dropped from 23.4% on K3 to 8.3%. The quick-start documentation lists several practical constraints: thinking mode is always on, and reasoning effort is divided into low, high, and max (default max); temperature 1.0 and top-p 0.95 are fixed values; output defaults to 131,072 tokens with a maximum of 1,048,576; visual input does not accept public image URLs and requires base64 or an uploaded file ID.
What it means for developers
The direct impact for developers centers on integration, cost structure, and long-context behavior. First, this is the first model in the K3.1 series, described as a post-training iteration of K3 rather than a new architecture, so migration cost may be lower than a cross-generation switch, but the API identifier and thinking-mode parameters need to be reconfirmed: because thinking mode is always on and reasoning effort defaults to max, existing call paths that relied on turning off reasoning or controlling thinking budget themselves need to be redesigned, otherwise latency and token consumption will be higher than expected. Second, the source reports that the model accepts text, images, and video through the API, but explicitly does not accept public image URLs, requiring base64 or an uploaded file ID, which is a real constraint on multimodality pipeline request construction, payload size, and the upload flow. Third, the 1M context and the maximum output limit of 1,048,576 tokens mean longer repositories or logs can be placed directly into a single request, but the source cautions that the full assistant message should be returned, and K3 previously warned that discarding reasoning history in a harness leads to unstable output, so if you keep truncating reasoning history, the long-context benefit may be offset. On pricing, the source says the standard version costs $2 per million input tokens and $10 per million output tokens, and Highspeed is $4/$20, both lower than K3's $3/$15 — this is vendor pricing relayed by the source on the reporting date, and specific figures should be based on the KimiSeek pricing page and actual call settlement, as prices change. To be clear, K3.1 Pro is currently not listed in the KimiSeek live model catalog, and the API availability described by the source refers to the vendor side.
Integration and evaluation
Consider proceeding along two independent decisions, both conditional analysis rather than source conclusions. Decision one: whether to migrate existing coding or terminal agents from K3 to K3.1 Pro. The change reported by the source is an overall improvement in coding benchmarks and lower pricing, but scientific terminal tasks are clearly worse. The choice depends on your workload mix: if tasks are mainly repository-level coding, SWE-style fixes, and terminal automation, a small gradual rollout is reasonable; if they include a high proportion of scientific computing, simulation, or research-oriented terminal tasks, you should keep the existing model or route in parallel. Measurable evaluation criteria: on your own coding task set, compare task completion rate and the proportion requiring manual correction between K3 and K3.1 Pro, while recording the total tokens needed to reach the same quality, and convert per-task cost using the pricing structure relayed by the source; only expand traffic when completion rate does not drop and per-task cost falls. Decision two: whether to enable the Highspeed variant. The change reported by the source is that Highspeed is 2 to 3 times faster but has a higher unit price, with reasoning effort fixed at max. The choice depends on whether you are constrained by interaction latency: if it is used for inline completion in an IDE or an agent loop requiring human-machine turn-taking, and requests can tolerate the output length caused by fixed max reasoning effort, test Highspeed first; if it is batch offline work and cost-sensitive, the standard version is more reasonable. Evaluation criteria: at fixed concurrency, measure end-to-end P95 latency and tasks completed per second, and calculate whether the latency reduction is enough to offset the higher unit price. A shared precondition for both decisions: first check whether the parameter constraints in the quick-start documentation match your existing client, especially the fixed temperature and top-p, and the fact that visual input does not accept public URLs; before any switch, keep a fallback switch, because open weights have not been released and self-hosting is not possible in the short term.
Limits and open questions
To be clear: Kimi K3.1 Pro is currently not in the KimiSeek live model catalog, and the API availability described by the source refers to the vendor side; before integrating, rely on the vendor documentation and the actual catalog. The source's benchmark numbers are mostly self-reported by Moonshot and mostly obtained at maximum reasoning effort under a Claude Code harness; the comparison charts come from the vendor's comparison page and were not confirmed on competitor pages, so they should not be treated as independently verified performance conclusions; several wins come from internal benchmarks. The clear lag on scientific terminal tasks is a shortcoming listed by the source itself, but its specific figures are likewise self-reported. Open weights are expected in November 2026, a timing relayed by the source as an expectation and subject to change; self-hosting is not currently possible, and the 2.8T scale also points to multi-node serving deployment. Pricing is vendor pricing relayed by the source on the reporting date and may be adjusted at any time. Details such as request parameter constraints, thinking mode always on, and fixed temperature come from the quick-start documentation cited by the source, and actual behavior should be based on the vendor's latest documentation. In addition, the model's release has already been covered by recent reports; the value of this source is in adding integration-level constraints and technical details, not in first confirmation of the launch.