Kimi K3.1 Pro Posts 65.7% on Terminal-Bench, With Weights Still Promised

Moonshot has released Kimi K3.1 Pro on Kimi.ai, Kimi Work, Kimi Code and the Kimi API, with open weights pledged by November 4. The company reports 65.7% on Terminal-Bench 4.0 for the 3T-class model, which has a stated 1M context window. Hosted availability and the promised weight release are distinct procurement facts.

The reported Terminal-Bench result places it ahead of GPT-6 Astra's 58.2% and narrowly behind Claude Opus 5.5. Moonshot also reports 92.7% on BenchCAD and 64.4 on OfficeQA Pro v2. Those results provide task-specific reasons to investigate the model, not a substitute for testing the workflow you intend to deploy.

Moonshot's release includes a consequential curation claim: cyber-attack data was removed from both training stages before the open-weight release, while general coding competency was retained. Buyers evaluating the release need to examine that claim separately from benchmark position. Performance and misuse controls answer different questions.

A benchmark lead applies to the named test

The relevant comparison is Terminal-Bench 4.0, with Moonshot reporting 65.7% against the supplied 58.2% figure for GPT-6 Astra. The benchmark version belongs beside the score whenever the result is repeated. Removing the version makes it easier to compare numbers that may not describe the same evaluation, and the supplied facts do not support that shortcut.

The comparison with Claude Opus 5.5 is described only as narrowly behind. There is no exact Opus score in the fact sheet, so an exact gap cannot be supplied. Keeping that limit visible prevents a qualitative comparison from acquiring false numerical precision. The reported ranking is useful without inventing a missing result.

BenchCAD and OfficeQA Pro v2 add other reported measurements, but their scores should stay attached to their names. The supplied account does not establish how those results translate into your error rate or operating cost. A builder can use the results to choose candidate tasks for evaluation while withholding a deployment decision until the model is tested on relevant work.

Hosted access and open weights are different decisions

Kimi K3.1 Pro is already released across the named Kimi products and API. The November 4 weight pledge describes a later availability milestone. Treating the model as already downloadable would collapse a promise into a completed delivery. A team that specifically needs weights should track that milestone independently of its hosted evaluation.

The stated 3T-class scale and 1M context window also leave practical questions unanswered. The supplied facts do not include self-hosting requirements, a license or inference pricing. Those details cannot be inferred from parameter class or context length. They remain diligence items for a buyer comparing hosted use with a potential deployment based on released weights.

That distinction helps sequence work this week. You can define an evaluation against the available product without assuming that a later deployment route will meet your requirements. If local control is essential to the purchase, make the actual weight release and its terms a condition of the decision. A future milestone is not evidence that today's deployment requirement has been satisfied.

The trade-off is an attributed safety claim, not a guarantee

Moonshot says its own hallucination stress test improved from 23.4% to 8.3%. The attribution and test boundary are essential. The figures do not establish a general error rate across all uses of Kimi K3.1 Pro. A buyer applying the lower number to every document or coding task would be making a claim the supplied evidence does not support.

The reported removal of cyber-attack data from both training stages is a curation decision intended to curb misuse. Moonshot also says general coding competency was retained. The supplied facts do not quantify a causal relationship between that removal and any particular benchmark result. They also do not establish that the model cannot produce harmful behavior under different conditions.

For builders, the cost is an evaluation obligation that the release narrative cannot remove. If your application gives a model tools or relies on factual answers, test the behavior that matters to that application. Do not treat a curation statement as an access-control policy, or a vendor stress-test result as your acceptance threshold. The evidence supports investigation, not automatic clearance.

What To Do About It

• Preserve benchmark versions: Add the exact evaluation name to your model comparison sheet and reject rankings assembled from unlabeled scores. Keep the supplied comparative result intact rather than calculating an unsupported cross-version conclusion; the Kimi measurement is 65.7% on Terminal-Bench 4.0.
• Separate release milestones: Assign your model evaluator to track hosted access separately from weight availability. If weights are a purchase requirement, ask for the delivered artifact and applicable terms before approving that route; Moonshot's pledged date is November 4.
• Test factual behavior: Select representative inputs from your own application and record which outputs need human checking. Use the vendor's stress-test result as a claim to investigate, not as an assumed production rate; the reported lower figure is 8.3%.
• Review tool permissions: Examine the permissions you would give the model before extending a trial beyond controlled tasks. Keep that review independent of training-data curation and identify which actions require approval, even when evaluating a model with a reported Terminal-Bench score of 65.7%.

The Bottom Line

Kimi K3.1 Pro's reported 65.7% Terminal-Bench 4.0 result gives builders a concrete reason to evaluate it. The November 4 weight pledge remains a separate milestone, and Moonshot's safety measurements remain attributed vendor claims. Buy based on the available deployment route and observed behavior on your tasks. A benchmark position should start the evaluation rather than finish it.