Kimi K3.1 Pro Open-Sourced: 2.8 Trillion Parameters Close In on Opus

An open-source "near-frontier" model has arrived

Moonshot has officially released Kimi K3.1 Pro. It is an open-source Mixture-of-Experts (MoE) model with 2.8 trillion total parameters and roughly 104 billion activated parameters, keeping the same scale as Kimi K3. The real change happened during training: Moonshot invested more reinforcement learning (RL) into this version and claims its performance now matches or approaches the best closed-source models.

According to a YouTube channel's breakdown of the release, Kimi K3.1 Pro has a clear positioning—to offer an "almost Opus-level" option with open weights. Whether that claim holds up can be examined across three dimensions: benchmarks, cost structure, and security trade-offs.

Mixture of Experts (MoE) is a sparsely activated model architecture: the network contains multiple "expert" subnetworks and a routing module, and each token is routed to only a few experts for computation. As a result, a model's "total parameters" can be enormous, while the "activated parameters" actually involved in a single forward pass are far fewer than the total. Take Kimi K3.1 Pro as an example: of its 2.8 trillion total parameters, only about 104 billion are activated each time, which brings training and inference compute costs closer to those of a hundred-billion-scale dense model while retaining the knowledge storage and representational capacity that come with large capacity. The cost of MoE is high memory usage and greater difficulty in handling routing balance and training stability, which is also where implementations differ significantly across vendors.

Reinforcement learning (RL) here refers to post-training a large model using verifiable task outcomes as reward signals. Unlike supervised fine-tuning, which imitates standard answers, RL lets the model try multiple solutions on its own and learn strategies from success and failure. It is especially good at forging "process" capabilities such as multi-step planning, tool calling, and error recovery—which is the main reason a terminal-operation benchmark can approach closed-source frontier models.

Benchmarks: Less than one point behind on terminal tasks

On Terminal Bench 4.0, Kimi K3.1 Pro trails Claude Opus 5.5 by less than 1 point while leading GPT-6 Astra. The significance of this result lies in the fact that terminal-operation tasks place high demands on a model's planning, tool calling, and error recovery abilities and have historically been a strength area for closed-source frontier models. An open-source model narrowing the gap to within 1 point shows that the gains from RL training are substantive rather than merely benchmark optimization.

It is worth noting that Moonshot did not publish complete sub-scores or evaluation configurations, and the margin of leadership on a single benchmark is limited. It is more accurate to understand this as "entering the same tier" rather than "having caught up."

Terminal Bench is a class of agent evaluation benchmark oriented toward command-line environments. Tasks typically require completing multi-step operations in a real or sandboxed terminal, such as troubleshooting configurations, fixing scripts, and managing files and processes. Scoring is generally based on whether the task is ultimately accomplished, so the model must break down goals on its own, call shell tools, read error messages, and adjust its next action; single-turn Q&A ability is not enough to pass. The reason such benchmarks are regarded as a "strength area" for frontier models is that they simultaneously test long-horizon planning, reliability of tool use, and the ability to recover from failure—weakness in any one link will cause the task to break down. For this reason, a gap of less than 1 point carries more weight on terminal tasks than on knowledge-Q&A benchmarks, but it also depends more on the specific runtime environment, number of retries, and tool interface design, so consistency of evaluation configurations should be noted when making cross-model comparisons.

Cost: About one-third of Opus

Moonshot's published cost curve shows that K3.1 Pro's cost to complete a single task is about one-third that of Opus. On the API side, it is already available on the Kimi API, at half the per-token price of Opus. For cost-sensitive agent workflows that require large numbers of calls, this price gap is enough to change technology choices.

Open weights are planned for release on November 4. This means teams can first validate results through the API and then decide whether to self-deploy, making the migration path relatively smooth.

Case study: It goes back to check "the simulator itself"

Moonshot shared a representative test: asking the model to build a human walking simulation. When the walking effect stopped improving, the model did not keep repeatedly tuning parameters at the policy level; instead, it went back to review the implementation of the simulator itself and ultimately found 36 errors in the mathematical calculations for the shoulder muscles.

This behavior pattern is noteworthy. Most models tend to circle within existing assumptions when optimization stalls, whereas proactively questioning the underlying tool and incorporating "the environment may have bugs" into the search space is a debugging strategy closer to that of a human engineer. This is also one of the behavioral traits reinforced by RL training.

Security trade-off: Cyber data removed, exploit capability still doubled

The most noteworthy part of the release is cybersecurity. Before the open-source release, Moonshot removed cybersecurity-related content from the training data because the model's exploit capability kept rising during training.

But even after removing the data, the number of exploit tasks K3.1 Pro solves is still more than twice that of Kimi K3. According to the same source's analysis, this shows two things: first, exploit capability may come partly from transfer of general reasoning and coding ability rather than direct injection of domain-specific data; second, training-data filtering alone is difficult to use to suppress this kind of capability effectively.

For open-source models, this is a structural problem: once weights are released, the capability boundary is no longer controlled by the releaser. Moonshot's approach is ex ante data governance, but the results show that such governance has limited effect, and the community needs more systematic evaluation and usage norms.

"Capability spillover" refers to a model performing well in a sensitive domain not because of specialized training data in that domain, but as a result of general reasoning, code understanding, and long-horizon planning capabilities transferring into that domain. Exploit tasks happen to rely heavily on reading code, locating flaws, constructing inputs, and iteratively validating them, and these abilities share the same underlying skill set as ordinary software engineering tasks. Therefore, even if cybersecurity corpora are removed during pretraining and post-training, the model may still "assemble on its own" usable attack ideas through general capabilities. This explains an apparently contradictory phenomenon: data filtering reduces direct knowledge injection but cannot suppress behavior derived from reasoning ability, which also means that data-centric governance methods have a structural ceiling.

How to view this release

The value of Kimi K3.1 Pro lies not in any single benchmark score, but in combining "a near-frontier open-source model + one-third the cost." For developers, this means high-call-volume scenarios such as agents, terminal automation, and code repair now have another realistic option.

At the same time, stay clear-headed: benchmark coverage is limited, the cost advantage is based on vendor-reported data, and the security issue of capability spillover remains unresolved. After the open weights are released on November 4, third-party reproduction evaluations will provide more reliable answers.