Kimi K3.1 Pro: Same Architecture, Eleven More Points

Moonshot's new flagship has, by its own account, the shape of its June model, and it gains 11 points on Artificial Analysis's Intelligence Index, from 44 to 55, fourth overall. Most of the gain is agentic, half of it in a single coding benchmark, and the cheaper tokens don't make it a cheaper model per task.

What shipped on 23 October

Moonshot released two API models and put them in its apps the same day: kimi-k3.1-pro and kimi-k3.1-pro-highspeed. The weights are promised "by Nov 4"; on 26 October the newest model in Moonshot's Hugging Face organization was still K3. Moonshot describes K3.1 Pro as "a post-trained version of Kimi K3, with substantially larger post-training compute" and calls it "3T-class". The 2.8 trillion total and 104 billion active parameters come from Artificial Analysis, not from Moonshot.

On the API, thinking is always on, with three efforts: low, high and max, the default. Sampling is fixed server-side (temperature 1.0, top-p 0.95), the context is 1M tokens, and the model reads text and images (video too) (quickstart). Moonshot's own coding product, Kimi Code, defaults to high.

So "same architecture" is a statement, not yet something you can check. Until the config ships, the honest description of K3.1 Pro's internals is K3's, which is public.

The architecture underneath: K3

From the K3 config and technical report:

The weights' shape is K3's; what changed is on the training side.

For serving, the layout is the point. KDA is linear attention: each of the 69 layers keeps a fixed-size state instead of a cache that grows with the context. Only the 24 MLA layers cache anything per token: 576 values per layer, 27 KiB per token in BF16, against 68.6 KiB for K2's 61 MLA layers. The KDA state is about 207 MiB per request in BF16 (414 MiB in FP32, the engine's choice) whatever the context length. A million-token request needs 27 GiB of cache, where K2's layout would need 68.6 GiB. Our hybrid attention piece explains the mechanism, and the Kimi lab piece the lineage. Sizing a deployment of the released weights is the follow-up's job.

What post-training changed

K3's own recipe, from its report, already leaned on reinforcement learning: supervised fine-tuning, then RL in three domains (general tasks, general agents, coding agents) at three efforts, nine specialist models consolidated into one by on-policy distillation. Effort is trained with token budgets: an answer that overruns its budget scores −1. Agents trained in a "unified white-box RL environment" that composes different harnesses, so the model doesn't overfit to one.

For K3.1, Moonshot says it ran "large-scale joint RL across hundreds of downstream domains" and optimized every layer of the stack: "the RL framework, long-context inference, training efficiency, sandbox infrastructure, rollout scheduling, and a shared platform for environment quality checks". It gives no compute figure, and there is no K3.1 report.

Where did the 11 points go? Artificial Analysis publishes the weight of each evaluation in its index; its launch article gives rounded scores, and its model data, as transcribed by kingy.ai, the unrounded ones in the figure. That is enough to see:

Agentic evaluations carry the gain; Terminal-Bench alone is half of it.

Terminal-Bench 4.0 went from 12.6% to 67.2% (13% to 67% in the launch article). At a 10% weight, that is about 5.5 index points on its own: half the gain (our arithmetic from Artificial Analysis's weights). AutomationBench, agentic SaaS workflows, rose from 58% to 73%; GDPval, agentic knowledge work scored in Elo, rose by 312 to 1,846, third behind Claude Opus 5.5 and Muse Wonder Full. Humanity's Last Exam moved from 47% to 52%, SciCode and CritPt by about a point, and long-context reasoning (AA-LCR) went down, from 88.7 to 86.3. The hallucination rate on AA-Omniscience fell from 53% to 44%. LiveBench shows the same shape: long-agentic up from 26.4 to 39.1 and coding from 59.3 to 81.8, reasoning and data analysis flat.

The gains land where the RL was aimed: behaviour in agent loops much more than knowledge. Artificial Analysis notes that once the weights ship, the gap between the best open-weight and the best proprietary model on its index falls from 12 points to 3.

Moonshot also used post-training to take something away. It says cyber-related data sat in both its mid-training corpus and its RL environments, and that it removed both for the open-weight release. On its internal xdev-bench-hard (exploit development, pass@3), the checkpoint without the removal solved 90.5%, K3.1 Pro 81.0%, K3 33.3%. Moonshot presents the released model as the 81.0% one and doesn't describe a separate API checkpoint. It says it aims not to release open weights that "extend the absolute frontier of cyber capability". The benchmark is internal; the aim is one you can check against the weights when they ship.

Reading the numbers

The same benchmark gives three numbers, depending on who runs it and with which agent:

K3's baseline needs care. Artificial Analysis added Terminal-Bench 4.0 to its index in September, three months after K3 shipped, and runs it with mini-swe-agent, a harness K3 wasn't tuned for; Vals, with the same harness, has K3 at 17.17%, while K3's own card reports 88.3% on the earlier Terminal-Bench 2.1 with Moonshot's harness. Part of the jump from 13% to 67% may be K3.1 Pro working better in an unfamiliar agent loop, which is itself a result of more varied RL. That is our reading, not a measured fact.

In Moonshot's own table, K3.1 Pro runs at effort max with its fixed sampling; most competitors' numbers are copied from their vendors or leaderboards, not rerun. Several of its headline numbers come from internal benchmarks: Kimi Code Bench 3.0 (61.2% against K3's 55.95%), the finance suites, Hallu Bench, xdev-bench-hard. And its own pages don't agree on one of them: the English blog reports Hallu Bench Hard falling from 23.4% to 8.3%, the Chinese API guide describes a different set (conversations users had flagged for factual errors) and gives 23.35% to 6.85%. For hallucinations, Artificial Analysis's external number (53% to 44%) is the one to quote.

What it costs, and what Highspeed buys

Prices fell by a third. Per million tokens, from Moonshot's pricing page:

Caching is automatic on repeated prefixes, with a 5-minute or 1-hour lifetime; a write costs the input price (twice it for one hour), a hit a tenth.

A task didn't get cheaper. Artificial Analysis puts K3.1 Pro at $1.98 per index task at launch ($2.11 on 26 October), against $2.00 for K3. Output tokens per task rose 14% (55K against 48K), which on its own, at two thirds of the price, would make a task about 24% cheaper. The arithmetic shows where the rest went: output is 48K × $15 per million = $0.72 of K3's task and 55K × $10 = $0.55 of K3.1 Pro's, so everything else (uncached input, cache writes and hits) went from $1.28 to $1.43 at two thirds of the price, about 1.7 times the input-side tokens. For an agent, the input side is most of the bill. (Our arithmetic from Artificial Analysis's totals; it doesn't publish the split.)

Token prices fell by a third; the cost of a task didn't, because the input side of each task grew.

Highspeed is the same model served faster. OpenRouter lists both as Moonshot endpoints of one model, both MXFP4; Moonshot calls it "same intelligence" at "about 2–3x output speed". Artificial Analysis measures less: 77 against 132 tokens per second on 24 October and 57 against 113 on the 25th (its snapshots as captured by kingy.ai), 48 against 86 on its leaderboard on the 26th, so 1.7 to 2x, on prompts of about 10,000 tokens, as 72-hour medians. It charges twice the input and output price but the same cache-hit price. With K3.1 Pro's token mix, output doubles to $1.10 and the input side lands between $1.43 (all cache hits) and $2.86 (none): a task costs 1.3 to 2 times as much, nearer 1.3 the more of it is cached.

Why would an operator sell speed? Because per-user speed is bought with fewer requests per GPU: smaller batches leave each request more of the memory bandwidth. K3's report names the other levers a provider has: an EAGLE-3 draft model trained from K3's multi-token-prediction layer for speculative decoding, and decode kernels built for small batches. Moonshot doesn't say which Highspeed uses.

Gotchas

Compare at the same effort. The API defaults to max, Kimi Code to high, and every benchmark above is at max. A test in Kimi Code isn't a test of the benchmarked setting.

Budget per task, not per token. K3.1 Pro writes and re-reads more per task than K3. Measure cost per task on your own workload, with your own cache-hit rate.

Quote a dated speed. Highspeed's advantage ranged from 1.7x to 2x in three days of Artificial Analysis snapshots. Measure it under your own load before paying the premium.

Don't plan hardware on "same architecture" yet. It is Moonshot's statement until the config ships. The license is unknown too; K3's has a model-as-a-service clause above 20 million US dollars a year.

Verdict

K3.1 Pro is the strongest open-weight candidate announced so far on Artificial Analysis's index, three points from the best proprietary model, and a clean case of what post-training alone buys on a fixed architecture: 11 points, most of them in agent loops. It is not cheaper per task than K3, and its knowledge and long-context scores are about where they were. Highspeed costs 1.3 to 2 times as much per task for 1.7 to 2 times the output speed.

What would change that call: a released config that differs from K3's, a license stricter than K3's, an independent quality check showing Highspeed isn't the same model, or a K3.1 report with the RL compute.

If you use the API for coding agents, switch from K3, measure cost per task, and pay for Highspeed only where a person is waiting. If your workload is long-context retrieval or knowledge questions, it gives you no reason to switch: AA-LCR slipped and Humanity's Last Exam moved five points. If you plan to self-host, wait for the weights. If you compare benchmarks, compare at the same harness and effort.

Next: the follow-up on serving K3.1 Pro once the weights are out; meanwhile, hybrid attention, sized explains why K3's layout keeps the cache small.