Kimi K3.1 Pro Pairs Million-Token Context With

Moonshot AI has announced Kimi K3.1 Pro with a one-million-token context window, 2.8 trillion total parameters and 104 billion parameters active per token. It also claims a 65.7% score on Terminal-Bench 4.0, a test of terminal-based tasks. API use is listed at $2 per million input tokens and $10 per million output tokens, with open weights expected by November 4.

Those figures address different problems. The context window determines how much material a user can put in front of the model. The active-parameter count helps explain how Moonshot can operate a model with a much larger total parameter pool. The benchmark offers a claim about task performance. The API prices tell customers what they would pay to try it through Moonshot's service. None substitutes for the others, though a launch announcement has every reason to stack them together.

For someone choosing a model to search documents or work through a software project, the useful question is more prosaic: Can K3.1 Pro find the right information in a large input, perform the requested work and do so at a predictable cost? Its specifications make that combination plausible. Testing it will require more than reading the specifications.

What 2.8 Trillion Parameters Buy

K3.1 Pro uses a mixture-of-experts architecture, or MoE. Think of the total parameter count as the collection of specialist components in the model. For each token it processes, a routing mechanism selects a portion of that collection. Moonshot's stated 104 billion active parameters describe the portion used per token; the 2.8 trillion figure describes the larger pool.

That design gives a model access to more capacity without running every token through every parameter. It does not make the other parameters disappear from the engineering problem. Serving a large MoE still requires storing its weights and moving data through the hardware quickly enough to keep the system responsive. The active count is therefore a useful clue about computation per token, while the total count helps explain why running the model yourself could remain a substantial undertaking.

Neither number is a quality score. Routing choices, training and the tasks a user gives the model all affect what comes back. A small model that consistently finds the relevant line in a file can be more useful for that job than a larger one that confidently edits the wrong file. Parameter counts are easier to print on a product page than that distinction is to test.

The architecture also shapes who can use the model independently. If Moonshot releases the weights as planned, developers would have access to the model files rather than only an API. Whether a team can afford to host a 2.8-trillion-parameter MoE is a separate question from whether it can download those files. The market for a model this large may include organizations that inspect or adapt the weights but still pay someone else to run inference.

A Million Tokens, with a Catch in the Workflow

A million-token context window offers room for a vast amount of text in a single request. A developer could, in principle, place extensive documentation, code and an issue description together instead of first cutting them into small pieces. An analyst could supply a long collection of records and ask a question spanning them. That could reduce the work of building a separate retrieval system, which normally finds relevant excerpts before sending them to a model.

Capacity is only the first step. A model asked about one line buried in hundreds of thousands of tokens must locate it, use it correctly and resist distractions elsewhere in the input. A large window can hold the material; it does not guarantee attention to the right passage. Tests that move the same relevant fact from the beginning to the middle and end of a long input would be more informative than a context limit alone.

The economics change with the amount of text sent, too. At the listed rates, sending one million input tokens would cost $2 before counting the response; a 100,000-token output would add $1. Those are illustrations of the published per-token prices, not a guarantee about how much of the context a single request can devote to input or how long an output the service permits. Repeat a large request many times while debugging a workflow, and each attempt incurs another bill. A long window can simplify an application while making careless prompt design expensive.

For some jobs, selecting a few relevant passages before making a request will remain the sensible choice. For others, keeping the full document set together could help the model follow cross-references that a search step might miss. Users will have to measure which approach produces better answers per dollar, rather than treating the largest possible prompt as the default.

The Coding Score Needs Its Test Setup

Moonshot's reported 65.7% on Terminal-Bench 4.0 points toward work in a command-line environment. That is closer to a developer's everyday tools than a multiple-choice quiz: terminal tasks can involve reading files, running commands and responding to the results. A percentage on such a benchmark, however, depends on the evaluation setup, including the tasks, permitted tools and how attempts are scored. Those conditions and independent comparisons are needed to judge where K3.1 Pro stands.

The earlier Kimi K3 beat Claude Fable 5 on a Frontend Code Arena benchmark. That result concerns a different Kimi model and a different test. Frontend work and terminal tasks can reward different abilities, so combining the two scores into a single story of steady improvement would be arithmetic by vibes.

A customer trying to choose a coding assistant would want to know what happens on their own repository: whether the model identifies the right files, makes a working change and explains what it did. A benchmark can guide that trial. It cannot replace it, particularly when the customer's tools, codebase and standards for a correct result differ from the test environment.

The November 4 Checkpoint

Moonshot is offering a way to try K3.1 Pro through an API now, while the planned open-weight release is still ahead. That sequence gives the company control over access during the initial rollout. It also gives prospective users two different decisions: whether the hosted service fits their budget today, and whether the eventual weight release will let them run or examine the model on their own terms.

The release terms will shape that second decision. A license determines what users may do with weights; a downloadable model does not, by itself, specify permission for every commercial or modified use. Reproducible tests after release could also let outside groups examine performance under their own conditions and compare it with the hosted version.

Moonshot's announcement brings together a very large model, a very long context window and pricing that can be calculated in dollars per million tokens. November 4 is the next practical checkpoint: the point at which developers may be able to take the model beyond Moonshot's API and see what it costs, and what it takes, to run those numbers themselves.