Kimi K3.1 Pro: open weights for long-running AI agents

Kimi K3.1 Pro now has a tangible size: 96 weight files totalling 1,561,293,160,568 bytes, or about 1.56 TB. We checked Moonshot’s official Hugging Face repository on November 9. These files contain the parameters another team can use to run the model on its own infrastructure and observe it inside its own application.

Moonshot’s announcement promised full weights by November 4; they were available on November 9.

For a team assigning terminal work to an AI agent, the public repository makes it possible to connect an answer to a particular weight revision, agent application and server configuration. That combination determines whether a system can work through errors and carry a lengthy assignment to a verifiable result.

The model card describes K3.1 Pro as a development of K3: 2.8 trillion total parameters, 104 billion active parameters and a context window of up to 1,048,576 tokens—the text fragments the model processes. That context figure specifies the maximum sequence length the model is designed to handle. In a working service, room for history, processing speed and simultaneous requests depend on the deployment.

NVIDIA’s NeMo AutoModel implementation describes an indexer in 24 attention layers, selecting up to 2,048 preceding positions for each query. The other 69 layers use Kimi Delta Attention. This reduces part of the computation involved in consulting a long history, where calculating every relationship between its fragments becomes expensive.

In the same documentation, the advertised million-token length remains unvalidated for training in that implementation. The indexer in the documented path still scans all available keys—numerical representations of preceding text fragments. Its score buffer grows with the square of length: doubling the number of positions requires approximately four times as much buffer memory, with other conditions unchanged.

The Terminal-Bench page already lists the model at 65.7. Public tasks show the kind of work involved: one supplies genomic data and local analysis tools and expects a report file as its output. The evaluation examines the system’s actions and output files inside a working environment.

Moonshot’s table gives Kimi K3.1 Pro 65.7% on Terminal-Bench 4.0, Claude Opus 5.5 66.4% and GPT-6 Astra 58.2%. These figures compare published results on that particular benchmark. The table does not supply uncertainty intervals with which to judge how consistently the closely spaced results would differ.

The announcement’s evaluation notes explain that Kimi ran through the Claude Code agent harness. For most competitors, Moonshot selected the highest figure in their publications or the official Terminal-Bench leaderboard. Its own measurements default to maximum reasoning effort, temperature 1.0 and top-p 0.95—settings that govern randomness in choosing the next text fragment and the range of available choices. This compilation differs from a single editorial rerun of every system.

When moving the model into an application, one small requirement in the Kimi API documentation becomes especially useful: the next request must preserve the complete assistant message, including reasoning_content and tool_calls. Those fields carry the model’s reasoning and tool invocations. An integration that keeps only the user-visible content changes the history available to the next step.

Consider an assignment to repair a program. The agent proposes a change, runs tests, reads an error and decides what to do next. A user sees only part of that exchange. Evaluating a long session requires preserving the test result, the call structure and the assistant-message fields the model expects.

The quickstart guide documents separate reasoning and final-answer streams, and instructs applications requesting strict JSON to parse content. That distinction matters when software produces a report, fills a form or supplies a machine-checked result: an agent’s working history and its final document serve different purposes.

This supports a more precise experiment than comparing chat-window answers. A fixed task, preserved message sequence, identical tools and a predetermined result check make it possible to locate the point at which the agent lost track of its work.

The weight files total about 1.56 TB even in the compressed form supplied. We obtained that figure by adding the sizes of the 96 safetensors files in the repository’s official API. It excludes intermediate-state memory, active request history and the serving program’s working buffers.

The mixture-of-experts architecture distributes computation across expert blocks: it selects 16 of 896 routed experts for a token, alongside two shared experts. The parameter count used at one step is therefore much smaller than the total. The remaining blocks are still part of the model and may be needed on subsequent steps.

Infrastructure sizing depends on where the full weights reside and how long access takes. The 104-billion figure describes the computation path; it cannot by itself determine disk capacity or specify a server. The public checkpoint makes those costs inspectable against a concrete set of files.

The vLLM recipe starts with eight graphics accelerators (GPUs): two GB300 trays or one B300 node. Its authors explicitly say the baseline was not throughput-tuned. An MI355X node is also documented. These are concrete starting configurations against which a team can record its own deployment results.

For long sessions, vLLM describes a distinct tradeoff. The DCP8 mode distributes the history cache across eight graphics accelerators. In the reported measurement it holds about seven times as many cached tokens as ordinary TP8, which distributes model computation across eight accelerators, while decode steps run 7–25% slower at the same batch size. That capacity matters when several agents keep large histories open for long periods.

The SGLang cookbook likewise separates configurations by hardware and the number of concurrent agents. Individual commands carry Verified, Final Verification In Progress or Not Verified labels. The documentation says some configurations are still being checked and that a cookbook-format speed sweep is not yet available across the configurations.

A buyer of server time can now compare specific things: the latency of one assignment, the number of simultaneous assignments that retain long histories, and the exact command verified on the chosen hardware. Together these determine the cost of a working agent. We have not run this version of the model on our own cluster; the configurations and measurements here belong to the serving-engine maintainers.

Kimi K3.1 Pro uses its own licence. It permits use, modification, fine-tuning and redistribution with the required notices. A separate threshold applies when the licensee or an affiliate operates a Model as a Service business: aggregate revenue above $20 million over any consecutive 12 months requires an agreement with Moonshot before commercial use.

The licence defines Model as a Service as third-party access to inference or fine-tuning with meaningful control over inputs, parameters or training data. It excludes products whose model capabilities are solely embedded in specific features or harnesses, and merely relaying requests to a model hosted by another provider.

There is a separate branding condition. A commercial product with more than 100 million monthly active users or more than $20 million in monthly revenue must prominently display Kimi K3.1-Pro in its interface. The agreement and branding conditions have specified exemptions: internal use as defined in the licence and access through official Moonshot products or certified inference partners.

The definition of internal use is narrow: the software, its outputs and its underlying capabilities must not be made available to third parties. An organisation running the model on its own servers therefore still needs to determine who receives access and results. The location of the installation alone does not establish an exemption.