Kimi K3.1 Pro pushes open-weight coding forward while holding back cyber training

What Moonshot shipped

On October 24, Moonshot introduced Kimi K3.1 Pro [1] as the first model in its K3.1 series. The standard and Highspeed variants are live in Kimi.ai, Kimi Work, Kimi Code and the Kimi API. Enterprise administrators can enable K3.1 Pro for their organizations, and access is off by default at launch.

Moonshot calls it a 3T-class open-weight model. K3.1 Pro is post-trained from Kimi K3, whose published architecture has 2.8 trillion total parameters and 104 billion activated per token. The company has not published a separate architecture table for K3.1 Pro.

Moonshot says the Highspeed variant runs two to three times faster, but the company does not publish latency distributions in the launch post.

What is available now, and what is happening later

The API product guide [2] lists `kimi-k3.1-pro` and `kimi-k3.1-pro-highspeed` for Chat Completions calls. It supports low, high and max reasoning effort, strict JSON Schema output, tool calling, vision input, prefix continuation and automatic context caching.

The official API pricing page [3] describes usage-based billing, separates cached from uncached input and confirms the 1,048,576-token context window for K3-series models.

Full model weights are not yet available. Moonshot says it will release them by November 4, but it has not yet published the exact artifacts, file sizes, inference engine support or hardware requirements. Teams should not describe the model as self-hostable until they can inspect those artifacts.

The published Kimi K3 repository [4] shows the base model's 2.8-trillion-parameter mixture-of-experts architecture, million-token context and Kimi K3 license. That repository does not yet provide K3.1 Pro weights.

How Moonshot reduced cyber-offensive capability

Moonshot says it saw vulnerability-research performance improve as it scaled post-training. Researchers traced part of the gain to cyber-related content in the mid-training corpus and tasks in the reinforcement-learning environments.

The company removed that data from both stages for the planned open-weight release. It kept general-purpose coding tasks because the model still needs to write, debug and operate software.

Reuters reported the release and placed the cyber decision in the context of more capable coding agents and proposed Chinese export controls. The report also noted that open weights reduce a developer's ability to restrict, monitor or update use once the files are widely distributed [5].

What the 81.0% cyber score does and does not show

Moonshot's internal xdev-bench-hard asks an agent to find and exploit recent vulnerabilities in controlled sandboxes. The tasks provide source code, a bug hint and a binary, and the agent must achieve arbitrary code execution to retrieve a secret string.

The released K3.1 Pro solved 81.0% of the problems at pass@3. A checkpoint trained without the cyber restrictions scored 90.5%. Kimi K3 scored 33.3%. The results support the narrow claim that the data removal reduced performance relative to Moonshot's own counterfactual checkpoint.

The result does not measure real-world attack success, safety in an untrusted harness or resistance to fine-tuning. Moonshot built and ran the benchmark, reported pass@3 over a random subset of runs and imposed no hard time or output limits. Reuters noted that the results have not been independently verified [5].

Why this release matters for open-model builders

Kimi K3.1 Pro pairs a model designed for long coding and knowledge-work runs with a planned weight release. If the artifacts match the announcement, teams can inspect the model, run it on controlled infrastructure and adapt it without sending prompts or code to a hosted provider.

The same distribution model weakens central enforcement. Moonshot cannot reliably revoke downloaded weights, apply a new classifier to every copy or observe how every deployment is used. Moonshot says it therefore placed the cyber limit in training before distribution.

Data removal is a specific control, not a proof of safety. General coding skills still transfer to vulnerability research, and users can post-train an open model. Operators still need network boundaries, short-lived credentials, tool allowlists, approvals and monitoring.

How to evaluate K3.1 Pro before adopting

Start with a representative set of repository, terminal, document, verification and visual tasks. Run each task several times and record completion, correctness, wall time, tokens, tool errors and human correction.

Compare the standard and Highspeed API variants with the same prompt, tools, reasoning effort and stopping rules. For self-hosting, repeat the same suite once the weights and a supported inference stack are public.

Do not use the million-token limit as the default test. Long prompts can increase latency, cost and error recovery work. Test the smallest context that completes the task and verify cache hits separately.

• Freeze the test set, harness, tool permissions and judging rules before comparing models.
• Require task-specific tests or verifiable artifacts for coding, document and financial-work results.
• Record tool trajectories and review dangerous commands, network attempts and secret-access requests.
• Track cost per accepted task, not just cost per million tokens.
• Test repositories and files that were not part of any tuning or prompt-development set.
• Keep release, publish, deployment and credential writes behind human approval.
• For self-hosted systems, document the license, hardware, quantization, memory, throughput and patching process.

What is confirmed, and what remains uncertain

• Confirmed: the standard and Highspeed API variants are live across Kimi products, while enterprise administrators must enable access.
• Confirmed: Moonshot says it plans to release full model weights by November 4.
• Confirmed: Moonshot says it removed cyber-related data from mid-training and reinforcement learning.
• Reported by Moonshot: K3.1 Pro scored 81.0% on xdev-bench-hard, versus 90.5% for the unrestricted checkpoint.
• Uncertain: how the weights will be packaged, and which inference engines and hardware shapes will support them at release.
• Uncertain: how well the vendor results reproduce under independent harnesses, hardware and budgets.
• Unknown: how much cyber operators can recover through post-training, tooling or harness changes after the weights are downloaded.

Frequently asked questions

• Are Kimi K3.1 Pro weights available now? No. The hosted models are live, and Moonshot says the full weights will be released by November 4.
• Is K3.1 Pro exactly a three-trillion-parameter model? Moonshot calls it 3T-class. The Kimi K3 base architecture has 2.8 trillion total parameters, but Moonshot has not published a new architecture table for K3.1 Pro.
• Why did the cyber score fall? Moonshot removed cyber-related data and tasks from two training stages. Its internal comparison attributes the lower score to that change.
• Does the lower score make the model safe for cyber work? No. The model still solved 81.0% of Moonshot's exploit tasks at pass@3, and general coding skills can support offensive work.
• When should teams migrate? Test the hosted API now if the model's capabilities match a real workload. Wait for the weights, deployment details and independent tests before committing to a self-hosted migration.
• Does one million tokens mean every long prompt will work? It is a limit. Teams should test retrieval quality, latency, cache behavior and error recovery on their own data.