Kimi K3.1 Pro's weights are out: Can you train cyber capability out of an open model?

On November 4, Moonshot AI published the full weights of Kimi K3.1 Pro on Hugging Face. The model has been available through Kimi's apps and API since late October. Now anyone can download it and run it on their own infrastructure. Large open-weight releases arrive almost every week now. What sets this one apart is that Moonshot openly says it limited the model's offensive cyber capability, and it published numbers showing how.

I'll start with a quick look at the model. Then I'll get to the more interesting question: when the weights are public, where can safety actually live?

The model at a glance

According to the Hugging Face model card, these are the key facts:

• Architecture: Mixture-of-Experts. There are 2.8 trillion parameters in total, but only about 104 billion are active per token (16 of 896 experts are selected).
• Context window: About 1 million tokens.
• Input: Text and images.
• Size: Weights ship in MXFP4, produced with quantization-aware training. The download is roughly 1.56 TB split across 96 safetensors shards.
• Serving: vLLM and SGLang are supported. Huawei has also announced inference support on its Ascend hardware.
• License: Moonshot's own "Kimi K3.1 Pro License", not Apache 2.0 or MIT.

On Moonshot's coding and agent benchmarks, the model is roughly on par with closed frontier models. For example, it scores 65.7 on Terminal-Bench 4.0. Many of these numbers are self-reported, though, and some benchmarks are internal. The part that caught my attention was the safety work, not the leaderboard.

How Moonshot limited cyber capability

According to the company, the team noticed that exploit-writing and vulnerability-finding skills grew as training scaled. That growth came from security content in the general training corpus and from cyber tasks in the reinforcement learning environments.

The fix was to filter that data out at two stages. Cyber content came out of the mid-training corpus, and cyber tasks came out of the RL environments. General-purpose coding tasks stayed in so the model would remain useful.

On xdev-bench-hard, Moonshot's internal exploit benchmark, the results are:

| Version | Success rate |
|---|---|
| Experimental checkpoint, no data removal | 90.5% |
| Released Kimi K3.1 Pro | 81% |
| Previous model, Kimi K3 | 33.3% |

The table tells two stories. First, data removal does make a measurable difference. Second, that difference is smaller than you might hope. Moonshot admits as much: as programming ability improves, exploit-writing ability comes with it. A model that reads code, debugs it and drives a terminal already knows most of what it needs to exploit a bug.

Moonshot's stated principle is also worth noting: it does not want to release open weights that push the absolute frontier of cyber capability. The company says K3.1 Pro still trails proprietary models that have been public for at least three months. That is the company's own assessment and has not been independently verified.

Why it matters

With a closed model, safety comes in layers: refusal behavior learned in training, filters at the API, usage monitoring and account bans. Once the weights are downloadable, almost all of those layers disappear. There is no API filter and no monitoring. Refusal behavior can be removed with fairly little effort, using techniques like "abliteration" or a short fine-tune.

This isn't just theory. Before the weights shipped, a Hugging Face account unrelated to Moonshot announced that it would publish an "unrestricted" K3.1 Pro with the guardrails stripped out. The repo is gated, so I couldn't verify its contents, but the intent is clear.

That is why Moonshot's data-level approach is interesting. You can strip out refusals, but you can't surface knowledge the model never learned. In my view, this is one of the more honest safety tools available for open-weight models right now. It has limits, though. The 81% result shows that general coding skill still carries a lot of cyber capability along with it. A determined actor could likely win back part of the gap by fine-tuning on their own data.

There is a strong opposing view, too. A few days earlier, Mistral released the weights of its trillion-parameter Mistral Large 4 with the opposite argument. Mistral says defenders need strong cyber capability, and open weights let organizations hold that capability in a way that "cannot be cut off". Both companies see the same risk. Moonshot chooses to cap the capability, while Mistral chooses to spread it.

What this means for developers

1. This is not a laptop model. 1.56 TB of weights and 104B active parameters per token means a serious multi-GPU setup. For most teams, the realistic path is to start with the API ($2 per million input tokens, $10 per million output tokens) and move to self-hosting only if data residency or cost really demands it.

2. Read the license. "Open weights" is not the same as "open source". K3.1 Pro ships under its own license. Mistral Large 4 uses a modified MIT license that requires large cloud providers reselling the model as a service to sign a separate agreement. If you're building a product on top of either, involve whoever handles legal.

3. Don't outsource safety to the model vendor. When you self-host, none of the API-side filters exist. In agentic setups, you have to constrain which tools the model can call, what network it can reach and what it can touch on the filesystem.

4. Test capability claims against your own workload. The benchmarks are self-reported. If you're a security team considering the model for code auditing, measure how the mitigation affects the defensive tasks you care about, such as finding vulnerabilities and suggesting patches, using your own examples.

5. Avoid abliterated copies. Third-party "unrestricted" uploads on Hugging Face are weights of unknown provenance. In a company setting, pull only from official repositories and verify checksums.

Bottom line

Kimi K3.1 Pro shows once again how close open-weight models have come to closed ones. Its bigger contribution is putting real data into the safety debate: data filtering works, but on its own it doesn't keep up as general coding skill grows. In the coming months, much of the safety work for open models looks set to happen in the infrastructure of the teams running them, not at the model vendor.