Kimi K3.1 Pro: the same 2.8T model, more RL, and what the −65% counts

Moonshot launched Kimi K3.1 Pro at 17:15 UTC on 23 October, after a teaser earlier the same day. The launch post calls it "our most capable 3T-class open-weight model": a 1M-token context, 2.8T total and 104B active parameters, multimodal, full-project game builds in Unreal, Unity and Godot, parametric 3D in Blender and CAD, finance hallucination "down by 65%", and "matching the strongest proprietary models across coding, agentic and knowledge benchmarks". It is live on the Kimi API now, with a Highspeed variant "2–3× faster". The weights are promised by 4 November 2026.

They are not out yet. On 24 October the Hugging Face API lists one K3 repository under moonshotai, the July Kimi-K3, and nothing for K3.1 (measured). So there is no config.json to diff, no tokenizer to read and no safetensors header to count. Everything below about the model itself is what Moonshot says, labelled that way. What I can check is the launch blog's own benchmark table, the pricing pages, a third-party measurement, and the arithmetic of the demo that went viral with it.

If you have not read the Kimi K3 article, the short version: K3 is a 93-layer MoE that routes each token to 16 of 896 experts, mixes Kimi Delta Attention with Gated MLA 3:1, reaches back across depth with Attention Residuals, and was post-trained as nine RL experts merged into one model by on-policy distillation. None of that changes here.

What changed from K3

The blog's first technical sentence settles the architecture question: "Kimi K3.1 Pro is a post-trained version of Kimi K3, with substantially larger post-training compute" (reported). Same base, same shape. The 2.8T / 104B, the 1,048,576-token window and the text, image and video inputs in the launch post are K3's numbers, and the API docs say "All K3 series models support a 1,048,576-token context window." OpenRouter lists both K3.1 Pro endpoints with the quantization tag mxfp4, which matches the MXFP4 expert weights K3 was trained to serve in (third-party listing).

So the diff is not in the weights' shape. It is in training data, RL scale, price and speed:

The one row that does not fit "post-trained version" is the cyber row. The blog says that for the open-weight release Moonshot "identified and removed cyber-related data from both training stages": the mid-training corpus and the RL environment mix. You cannot remove data from a stage you did not rerun, so a mid-training stage was redone for K3.1 Pro, not only RL stacked on the K3 checkpoint (reasoned). That is still "the same base model" in the sense that pre-training was not redone, and it is the same move Z.ai made with GLM-5.3, which kept GLM-5.2's base and spent a month on post-training.

For reference, here is the architecture the K3.1 Pro weights should carry, from K3's own report. If the 4 November config.json differs from K3's, this is the line that will be wrong:

expand

Where the gain comes from: scaling RL, not the model

If the network is the same, every point K3.1 Pro gains over K3 was bought with post-training. Moonshot's account of how is one paragraph, and it is about plumbing, not a new objective. To run "large-scale joint RL across hundreds of downstream domains" they optimized "the RL framework, long-context inference, training efficiency, sandbox infrastructure, rollout scheduling, and a shared platform for environment quality checks", so that "each increment of RL compute delivers stable, predictable returns" (reported).

That list reads like a list of the ways RL spending gets wasted, and it is worth taking one item at a time:

• Long-context inference is most of the cost. An agent's RL step is mostly generation: long trajectories against tools before any gradient. K3 already paused straggler trajectories and resumed them next iteration so a few long ones would not stall the batch.
• Sandboxes and rollout scheduling decide how many environments are live at once. K3's AgentENV microVMs sit idle up to 98% of their lifetime waiting on the model, and pausing them is what made 51 million sandboxes affordable.
• Environment quality checks are the quiet one. Hundreds of domains means hundreds of reward functions, and one that pays for the wrong behaviour poisons the shared policy. K3's GPU-kernel reward already needed a growing list of hacking detectors.
• "Joint" is the change from K3, whose RL trained nine separate experts, three domains by three effort levels, and merged them with Multi-Teacher On-Policy Distillation. Joint RL across hundreds of domains is a different recipe, but the blog does not say whether the expert-then-distil structure survived.

The blog gives no number for the compute: no GPU-hours, no ratio to K3's post-training, no curve of score against RL steps behind "stable, predictable returns", and no technical report yet.

The results that can be laid side by side with K3 are all Moonshot's (reported): Kimi Code Bench 3.0 Long-horizon from 55.95 to 61.2, financial modeling up 7.2 points, financial research up 11.6, a simulated business operation at about 4.2× K3's score, and xdev-bench-hard, Moonshot's exploit-writing benchmark, from 33.3 to 81.0. One independent number agrees on direction: Artificial Analysis's current Intelligence Index has K3 (Max) at 43.6 and K3.1 Pro at 55.1 (third-party, read from AA's model page on 24 October; that is a newer index version than the v4.1 score in the K3 article, so the two are not comparable).

The benchmark table, not the chart

The launch chart is 14 bar panels. The blog's table, at the bottom of the same page, has 47 rows across coding, agentic, knowledge-and-vision and cyber, against five models: Claude Fable 5.1, GPT-6 Astra and Claude Opus 5.5 on the proprietary side, DeepSeek-V4.1-Flash-1017 and GLM-5.3 on the open side. Here is the chart:

expand

I pulled the table out of the JSON the page ships and ranked every row (measured from the page). With the three proprietary models as the comparators, 45 rows have at least one of their scores, and K3.1 Pro is ahead or tied on 16 of them. Counting all five comparators, it is first on 16 of 47 rows, and by category the picture is lopsided: first on 13 of 25 agentic rows, 2 of 10 coding rows, 1 of 9 knowledge-and-vision rows, and 0 of 3 cyber rows. The chart is a mild selection: K3.1 Pro is first in 6 of its 14 panels, against 10 of the other 33 rows (measured). Program Bench (31.5 against Opus 5.5's 65.0) and HLE-Diamond (39.4 against GPT-6 Astra's 65.8) are in the table and not the chart.

Toggle the comparators and categories to see which claims hold against which models:

Four things in the footnotes change how much any single row says (all reported):

1. Who ran what. K3.1 Pro was run by Moonshot at max effort, temperature 1.0, top-p 0.95, mostly in the Claude Code harness, but in Kimi Code for BioMysteryBench and Agents' Last Exam and in the Kimi Agent harness for OSWorld. Most comparator scores were copied from each lab's report or a public leaderboard, run in their own harnesses. Terminal-Bench 4.0, the headline row, takes "the maximum value reported in either their blog posts or the official Terminal-Bench 4.0 leaderboard" for everyone else.
2. Fallbacks and guards. Every Claude column is labelled "max, with fallback" and the GPT-6 Astra column too. The chart note adds that "GPT Models may include cyberguards". Both are mechanisms that tend to lower a comparator's score, so if anything they cut against the comparators, not for them.
3. Zeros assigned by Moonshot. On OfficeQA Pro the blog says some external models "retrieved reference answers online; Consequently, we assigned a score of zero to these tasks", and Agents' Last Exam zeroes runs that bypass the task. Both are defensible. Both are a lab adjudicating its competitors' transcripts.
4. Internal rows. Kimi Code Bench 2.0 and 3.0, Business Operation, DECK-Arena, Design Bench, both Kimi Hallucination rows and xdev-bench-hard are Moonshot's own. Drop them in the widget and the agentic lead survives; it rests mostly on public benchmarks.

So "matching the strongest proprietary models" is true of agentic work with tools: browsing, document and office tasks, Agents' Last Exam, Automation Bench. Terminal-Bench 4.0 is the honest headline, 65.7 against Opus 5.5's 66.4 and GPT-6 Astra's 58.2, a near tie in a harness that is not Moonshot's. It is not true of closed-book knowledge, of the harder vision sets, or of Program Bench, where K3.1 Pro scores 31.5 and Opus 5.5 65.0. Artificial Analysis's index lands in the same place: K3.1 Pro at 55.1 sits between Opus 5.5 (Max) at 57.6 and GPT-6 Astra (Max) at 52.7 (third-party).

What the −65% counts

"Hallucination down by 65%" comes from one sentence in the blog: on "Kimi Hallu Bench Hard", "an internal benchmark designed to stress-test factual accuracy, its claim-level hallucination rate fell from 23.4% for K3 to 8.3%" (reported). That is a 64.5% relative drop (reasoned), which the post rounds to 65%. The same sentence gives the response-level number, which is less dramatic: "the share of responses containing at least one factual error was just 42.4% of its predecessor's rate", a 57.6% drop.

A claim-level rate means a model's answer is split into individual factual claims and each claim is checked; the footnote says the checking is done by "fact-checking agents". Two things follow. The rate depends on how the splitter counts claims, so a model that writes more small, safe claims looks better per claim than per response, which is why the response-level 42.4% is the more conservative figure. And the checker is an LLM agent, so the benchmark measures agreement with Moonshot's fact-checker, not with ground truth.

expand

The blog is careful to say the rates "do not represent overall error rates in daily use". On its own chart GPT-6 Astra is lower than K3.1 Pro on both hallucination rows, 5.5 against 8.3 on the hard set.

The more interesting finding is on the API platform. The K3.1 Pro quickstart at platform.kimi.ai, read on 24 October, carries what looks like an earlier draft of the blog. Its version of the same paragraph says the rate "fell from 23.35% for K3 to 6.85%", with the error-containing share at "46.4% of its predecessor's rate", and it describes the set differently: "de-identified conversations where users had flagged factual errors in earlier models's responses" (measured, from the page). The same page still has unfilled slots, [xx.x%] where the Terminal-Bench numbers go.

Two readings follow, both reasoned. The numbers moved between drafts, from a 70.7% drop to a 64.5% drop, so the published 65% is the more cautious of the two. And if the set really is built from prompts where users flagged errors in earlier models' answers, it is selected on the predecessor's failures. A model rerun on its own worst prompts regresses toward its average, so part of K3's 23.4% is the selection itself, and K3.1 Pro's drop overstates the improvement on a fresh sample. The published blog no longer says how the set was built, and it is internal, so I cannot check which description is current.

Highspeed: same price for a cache hit, double for everything else

Highspeed is the variant with the least explanation. The model list calls it "the high-speed variant of Kimi K3.1 Pro — same capabilities at about 2-3× the speed". Prices: $4.00 per million input tokens and $20.00 output, exactly double the standard $2.00 and $10.00, with cached input unchanged at $0.20 (reported). OpenRouter lists it as a second endpoint of the same model, tagged moonshotai/highspeed, with the same mxfp4 quantization and the same 943,718-token output cap (third-party listing). No tokens-per-second figure is published for either, and Artificial Analysis does not list Highspeed yet. The 2–3× is unverified.

How would the same weights at the same precision go faster? The usual levers, none confirmed by Moonshot (reasoned):

• Smaller batches per replica. Decode for a big MoE is memory-bound: each step reads the active weights and the KV and KDA state once, whether it serves one sequence or many. Batching amortizes that read across users, which is what makes tokens cheap and each user slow. Serve fewer sequences per replica, or spread one replica over more GPUs, and each user's step gets shorter while each GPU's throughput falls. The GB300 decode article shows the trade on K3 itself: one user on 16 GPUs at batch 1 is a configuration chosen for speed, not for cost.
• Harder speculative decoding. K3 ships an EAGLE-3-style draft built from its multi-token-prediction layer. More draft tokens per step raise speed for one user and waste compute on rejected drafts, which also costs throughput.

Both cost GPU-time per token, which fits a doubled per-token price. The unchanged cache price fits too: a cache hit skips prefill, and the speed-up is in decode. That is consistent; it is not evidence.

The standard endpoint already moved. Artificial Analysis measures K3.1 Pro's median output speed at 77.1 tokens per second against 38.5 for K3 (Max), and its average time per Intelligence Index task at 609 seconds against 1,174 (third-party). That is about 2× on the regular endpoint before Highspeed enters (reasoned), and since the network is the same, it is a serving change or shorter reasoning, not a faster model.

expand

The Spider-Man demo, checked against list price

The demo that travelled with the launch was a post of a Spider-Man city game: "Kimi K3.1 Pro built Manhattan, added web swinging between skyscrapers, then threw in street combat. 8 hours. 3.8M tokens. Total cost: $34.72." Three things do not add up.

The arithmetic. At list price, 3.8M K3.1 Pro tokens cost between $0.76, if every token is a cache hit, and $38.00, if every token is output (reasoned). To land on $34.72 with nothing cached, 3.39M of the 3.8M tokens, 89%, must be output. On Highspeed it takes 1.22M output tokens, 32%, still with no cache hits. Neither looks like an agent session. Moonshot's own cyber table gives the mix of a long agentic trajectory: 159.8M input and 546K output tokens per successful xdev-bench-hard run, 0.34% output (reported). Artificial Analysis's runs of K3.1 Pro across its whole index used 5.39B input and 148M output tokens, 2.67% output, and 94% of input was served from cache; they cost $3,117 in total, about $0.56 per million tokens (third-party token counts and costs, my division). At that rate 3.8M tokens is about $2.14, and $34.72 buys about 62M tokens. One reply on the post makes the same point from experience, estimating an hour of agent work at ten to twenty million tokens. The post claims under half a million an hour.

The clock. The demo was posted at 18:36 UTC, 81 minutes after the 17:15 launch post (measured from the two posts' timestamps). Eight hours of building needs access from before the announcement. Early testers exist for most launches, so this is not impossible, but the post does not say so.

The provenance. The developer behind an earlier project, spiderbench, posted a similar browser Spider-Man city on 27 September, made with Claude Opus 5.5 using Blender, image generation and Three.js, and published its source and assets. He replied that the K3.1 Pro post is his project with new lighting, and says a community note was added. I compared the two clips frame by frame at 2 fps and found no identical frames: the repost is relit at golden hour and has no minimap (measured). That neither proves nor rules out a derived build, and I make no claim either way. What I can say is that the post's cost and token numbers are not consistent with each other at Moonshot's prices, so the demo is not evidence for K3.1 Pro's cost or ability. The blog's own examples, built "end to end by K3.1 Pro", are the ones to judge it by, and none of them comes with a token count either.

Cyber: capability removed on purpose

The cyber section is the part of the blog with the most actual numbers, and it is unusual enough to note. During development, Moonshot saw vulnerability-research scores rise steadily with post-training scale, traced the source to cyber content in the mid-training corpus and cyber tasks in the RL mix, and removed both for the open-weight release.

expand

The same pipeline without the removal solves 90.5% at pass@3; the final K3.1 Pro solves 81.0%; K3 solved 33.3% (reported). So the removal cost about 9.5 points of exploit capability on Moonshot's own benchmark, while general coding gains still lifted it far past K3. On the public cyber rows, ExploitBench and ExploitGym, K3.1 Pro is fourth of five, behind all three proprietary models, which is what Moonshot says it is aiming for: open weights that do not "extend the absolute frontier of cyber capability". The tokens column doubles as a cost receipt for the previous section: a successful run is around 160M tokens.

What to watch on 4 November

When the weights land, three things are checkable that are not checkable now:

1. The config against K3's. If it is the same base model, config.json should match K3's field for field, and the tensor names and shapes in the safetensors headers should be identical while every shard's hash changes. That is the test the DeepSeek-V4.1-Flash-1017 diff ran.
2. The licence. K3 shipped under a custom Kimi K3 License. The K3.1 Pro blog does not name one.
3. Local speed. Highspeed is a serving configuration, so it will not ship. What ships is the same 2.8T MXFP4 shape that the TPU megakernel and kimi-k3-in-c already run for K3, so both should load it unchanged if the config matches.

Until then, K3's own card is the closest public record of what K3.1 Pro's weights should look like:

The take

K3.1 Pro is the clearest case yet of a lab shipping a new flagship without a new network. The same 2.8T shape, the same 1M window, an implied mid-training rerun with cyber data removed, and a large, unquantified increase in RL. What that buys is real but narrow: K3.1 Pro leads on agentic, tool-using work and finance-flavoured document tasks, nearly ties Opus 5.5 on Terminal-Bench 4.0, and still trails the proprietary models on closed-book knowledge, harder vision sets, Program Bench and, by design, cyber. It costs a third less than K3 and the standard endpoint runs twice as fast.

The −65% is a real number from an internal stress test, measured per claim by an LLM fact-checker, and the per-response figure is 58%. An earlier draft of it, still live in the API docs, said 71% and described a set selected on earlier models' failures. And the demo is not a measurement of anything: its tokens and its price cannot both be right at Moonshot's own rates.

Sources: the Kimi K3.1 Pro tech blog (benchmark table and footnotes, finance, hallucination and cyber sections; figures 1-3 here are its charts), Moonshot's launch thread (figure 4), the Kimi API pricing page, model list and K3.1 Pro quickstart, OpenRouter's endpoint listing for moonshotai/kimi-k3.1-pro, and Artificial Analysis's model page (speed, index, token counts and run cost), all read on 24 October 2026. The architecture figure is from the Kimi K3 technical report. Tallies are mine, computed from the table the blog page ships; the widgets use the same data.