Moonshot published the Kimi K3.1 Pro weights to Hugging Face on 5 November 2026. It is a mixture-of-experts design with 2.8T total parameters and room for 1M tokens of context. Its 65.7% on the Terminal-Bench 4.0 evaluation leaves it 0.7 points under Claude Opus 5.5, which posts 66.4%, while GPT-6 Astra trails at 58.2%. BenchCAD changes character with tools: 92.7 for K3.1 Pro, 96.2 for Opus 5.5. OfficeQA Pro v2 records 64.4, and Kimi Hallu Bench Hard puts the wrong-claim share at 8.3%, down from 23.4% under K3. All figures came from Moonshot. Weights do not reduce the hardware bill, so most teams will rent access through an endpoint.
Two numbers decide how to read this release. The first is 2.8 trillion, the parameter count. The second is 65.7%, the Terminal-Bench 4.0 score.
The parameter count explains why almost nobody will host the model in-house. The score explains why plenty of teams still want access to it. Moonshot put the weights online on November 5, and most practical questions come from holding both facts at once.
How good is the coding result, really?
Terminal-Bench 4.0 gives an agent a job and grades whether it finishes with command-line tools. That is closer to paid agent work than a single-file completion test, which makes the score worth arguing about.
Kimi K3.1 Pro posts 65.7%.
| Model | Terminal-Bench 4.0 |
|---|---|
| Claude Opus 5.5 | 66.4% |
| Kimi K3.1 Pro | 65.7% |
| GPT-6 Astra | 58.2% |
Treat the 0.7-point difference from Opus 5.5 as a tie. How the harness is set up, how retries are handled, and how the prompt scaffolding is written can each move a run further than that. The larger gap is the 7.5 points separating it from GPT-6 Astra, and that number weakens the old assumption that an open-weight model is the budget compromise. On this benchmark it is not the cheap tier.
Also note who produced the numbers. All three come from Moonshot's release material. No independent harness has published a run, and vendor results usually show the best case.
What went up on November 5?
The download sits on Hugging Face, in the moonshotai/Kimi-K3.1-Pro repository. The architecture is mixture-of-experts with 2.8T total parameters and a context window of 1M tokens. That combination is why the release travelled beyond the usual open-model audience.
NVIDIA AI's account posted congratulations that morning. Some replies described a Fable-class model that developers could finally download.
Moonshot shipped a consumer feature in the same news cycle as well. 3D Make now runs in kimi.ai and in the Kimi App. Inside either one you can open and modify a 3D model, save it for 3D printing, or export a clip together with a Live Photo. It remains a product feature rather than an API, yet it reveals where the team believes the model is steady enough to put in front of users directly.
The humanoid demo is the better signal
Ask a model to write a patch and you learn how it handles code. Ask it to build a walking simulator from nothing and you learn how it handles failure. Moonshot chose the second test.
The scene contains 296 skeletal parts and 402 muscle parts. The first build falls after two steps. K3.1 Pro read the output, found the controller error, changed it, and got 11.2 seconds of alternating steps out of the simulated body.
Then the arm movement refused to improve. Instead of tuning the reward function harder, the model inspected the simulator's dynamics and traced 36 faults to the moment-arm math for the shoulder muscles. It corrected them and retrained.
That is environment debugging, not code generation. Agent buyers say they want it. Leaderboards almost never show it.
3D and CAD: what the score includes
Give the model a description, a rough drawing, or a photo for reference. It works out shape, proportions, and how the parts sit in space, then writes an openable file. A demo shows a landing page for a robotic arm generated as code. It runs inside a browser, carrying 2,300 components and almost 300 animated pipes.
Because it writes and runs scripts, it can operate Blender and CAD applications. Mechanical parts, architectural pieces, and furniture made to order all fall inside that parametric scope.
On BenchCAD, the tool-assisted score is 92.7. Claude Opus 5.5 scores 96.2 and GPT-6 Astra 95.9. The published table carries a no-tools column as well, and the distinction matters. A with-tools result describes the model plus the pipeline around it. Hand it a script runner and the figure is realistic. Remove the runner and it is not.
Finance: fewer wrong claims, still not signable
The finance claim is a workflow, not a single score. Finding documents, reconciling figures across them, building the model, and analyzing profitability. OfficeQA Pro v2 asks for analysis of actual financial documents and gives it 64.4. Moonshot calls that the best published result when the model launched.
The demo is an NVIDIA valuation model assembled from scratch. Formulas stay linked across the file, assumptions are written down, operating drivers can be adjusted for each scenario, plus a sensitivity table shows how each adjustment moves the valuation.
Accuracy matters more in finance than in the other demos. Kimi Hallu Bench Hard puts the wrong-claim share at 8.3%, down from 23.4% under K3. The proportion of answers with one or more factual mistakes equals 42.4% of the earlier model's figure.
One bad claim in twelve is progress and still too many. A first draft can absorb that. A document a client signs cannot.
What breaks when you deploy it?
These are ordered by how often they cause trouble.
- Total size. At 2.8T parameters the model belongs in a data center. Sparse activation cuts compute per token, not the footprint down to something one server can hold. Most teams should plan on an endpoint.
- Context billing. A 1M token window helps repo-scale agents, but every turn resends the input. An agent that stuffs an entire repository into its context will cost more than one that retrieves.
- Who ran the test. Every score here is vendor-reported. Read the ordering as directional, not final.
- Tool access. The BenchCAD and finance tests presume the model can execute code. Confirm your sandbox before comparing your numbers with the published ones.
Latency at scale is the question the announcement leaves open. A 2.8T model can be inexpensive per token yet remain too slow inside a tight agent loop. Only whoever serves it can answer that.
Want to try Kimi K3.1 Pro for coding, 3D, or finance work? Explore the SaveMyToken Multi-Model Coding Plan.
FAQ
Are the Kimi K3.1 Pro weights actually downloadable?
Yes. Moonshot posted them to Hugging Face in the moonshotai organization on 5 November 2026. The model is described as a 2.8T-parameter MoE design with room for 1M tokens of context, and the base model is offered as weights rather than a hosted-only product.
How close is it to Claude Opus 5.5?
The Terminal-Bench 4.0 run puts K3.1 Pro at 65.7% and Opus 5.5 records 66.4%, a gap of 0.7 points. BenchCAD with tools: 92.7 for K3.1 Pro, 96.2 for Opus 5.5. Both sets are Moonshot-reported, so read the order as directional.
Can one server host it?
Not realistically. With 2.8T parameters the model is data-center class before throughput even matters. A hosted endpoint is the practical choice.