Kimi K3.1 Pro cut its price 33% and still ranked 4th

The 33% price cut on Kimi K3.1 Pro exists only on the price list. Released by Moonshot AI on Oct 23, the model costs $2 per million input tokens and $10 per million output tokens, a third cheaper than its predecessor K3 ($3 and $15), and it landed 4th out of 215 models on the composite index of Artificial Analysis (AA), an independent evaluator of AI models. Yet the cost per task that AA measured by running the same work is $2.00 for K3 and $2.11 for K3.1 Pro, effectively the same, and the 4th place comes from outside measurement, not from the vendor’s own table. Unit price, score, and token volume were measured by different parties on different days, so this article reads the three numbers separately. The reference date is Oct 27.

Price list -33%, receipt +6%

First, the price list. These are Moonshot’s published prices per million tokens, excluding tax and tool fees, with no tiered surcharge for context length.

Per 1M tokens	Input	Cached input	Cache write (5 min / 1 hour)	Output
K3 (previous)	$3	$0.30	$3 / $6	$15
K3.1 Pro	$2	$0.20	$2 / $4	$10
K3.1 Pro Highspeed	$4	$0.20	$4 / $8	$20

Caching is a mechanism that automatically recognizes requests with the same beginning and processes them cheaply. AA also shows these prices as a blended rate weighted 7 cache hits : 2 input : 1 output, which works out to 0.7×$0.20 + 0.2×$2 + 0.1×$10 = $1.54. Output is only 10% of the tokens here but $1.00 of the bill, about 65%. In other words, this model’s invoice grows as its answers grow longer.

So did the receipt shrink as much as the unit price? The figure below sets K3 at 100 and shows in four lines where K3.1 Pro moved. Green lines went down, red lines went up.

Figure 1. The unit price went down, but the cost per task went up. The index relative to K3 is the editors’ calculation

On launch day, AA reported a cost per index task of $1.98, nearly the same as K3, and average output per task grew 14%, from about 48,000 to 55,000 tokens. On AA’s model page on Oct 27, K3 is at $2.00 and K3.1 Pro at $2.11, while the output tokens used across the whole index actually fell 6%, from 160M to 150M. The token counts at the two points move in different directions, but the conclusion is the same: a model whose unit price was cut by a third still sits at about two dollars per task. In the cyber evaluation, the cost per task rose 15%, from $2.45 to $2.81, reportedly because input token consumption roughly doubled. AA’s K3 page now marks that model as deprecated and recommends K3.1 Pro.

When planning a budget, this gap turns into numbers right away. Take a coding agent that uses 10 million input and 2 million output tokens a day. A simple calculation without caching gives $60 for K3, $40 for K3.1 Pro, and $80 for Highspeed. Applying only the launch-day 14% increase in output makes K3.1 Pro $42.80, which shrinks the saving from 33% to about 29%. That is why a budget built on “a third saved every month” can go off track.

One thinking level can double the receipt

K3.1 Pro’s thinking mode cannot be turned off. You pick the level from low, high, and max, and the default is max. One outlet measured how much this setting matters for the bill on a small agent task. It ran a small Python assignment three times per setting and compared only the runs that passed all 96 hidden checks.

Figure 2. Changing only the thinking level of the same model produces cost ranges that do not overlap. This is a single experiment by one outlet, and Kimi is shown as a range because the account-balance change and the unit-price calculation differ

max used about 3 times the output tokens of low (17.3K vs 5.4K), cost a little over double ($0.35 to $0.46 vs $0.16 to $0.21), and took 4.9 minutes against 2.2 minutes. Of the 17.3K output tokens max used, 12.2K were reasoning tokens (low used 1.4K), and these are also billed at the output rate. Within the same model, the gap created by one setting is bigger than the 33% price cut. The comparison models, Opus 5.5 ($0.37), Sonnet 5.5 ($0.18), and DeepSeek V4.1 Flash ($0.016), each used 4.2K to 6.6K output tokens on this small task. With only one task, it should be read purely as an example that token consumption, not unit price, decides the ranking; the ratios may differ on harder work.

Caching works in the same direction. In the editors’ example of uploading a 200,000-token contract and asking 10 questions, no caching costs 0.2M × $2 × 10 = $4.00. With caching, the first request is $0.40 (a 5-minute cache write costs the same as the input price) and the other 9 are 0.2M × $0.20 × 9 = $0.36, for a total of $0.76. You must ask follow-ups within 5 minutes, though, and changing reasoning_effort mid-conversation invalidates the prefix cache, so the next request is billed at the input price again. If your requests are more than 5 minutes apart you can choose 1-hour retention, but the write fee doubles.

Re-ranking the 55-point index by cost per task

The composite index is a score AA builds by combining 10 evaluations (AA-Briefcase, GDPval-AA, AutomationBench-AA, Terminal-Bench 4.0, SciCode, HLE, CritPt, AA-Omniscience, and others). K3.1 Pro rose from K3’s 44 to 55, 4th among models. It sits behind Claude Opus 5.5 (58), Claude Sonnet 5.5 (56), and Meta Muse Wonder Full (56), and ahead of MiMo-V2.6-Pro (46) and DeepSeek V4.1 Flash (45). The ranking alone is impressive, but the picture changes once you put the money spent to earn the score on the horizontal axis. Higher means a higher score, and further left means a cheaper index task.

Figure 3. The AA leaderboard on Oct 27. The horizontal axis is a log scale. Points with a reasoning level attached are different settings of the same model

Three things can be read from it. First, at about the same $2 as K3.1 Pro, K3 scored 44 and GLM-5.3 scored 45, so the real gain from this cut is not a smaller receipt but being able to buy an 11-point higher score for the same money. Second, the top end is still expensive. Opus 5.5 max is 3 points higher at $5.98 per task, about 2.8 times as much, and Sonnet 5.5 is 1 point higher at $5.46, about 2.6 times. Third, the efficient zone is not K3.1 Pro’s alone. Run Opus 5.5 at high and you get 54 points for $1.82, and GPT-6.1 Sol max gets 52 points for $0.72, which is cheaper still. Choosing a model is really choosing a pairing of model and thinking level. The fact that total output tokens across the index were 150M, about 1.7 times the median of 87M, tells the same story: this model is talkative.

Speed goes the other way. By AA’s measurement, output speed is 51.5 tokens per second, 159th of 186 (median 82.5), while time to first token is 2.99 seconds, faster than the median of 3.91 seconds. Think of it as slow on tasks that need long answers and quick to react to short questions. The faster Highspeed variant serves the same model 2 to 3 times faster in exchange for double the unit price.

Why the winner flips on the same test

Coding-agent scores such as Terminal-Bench 4.0 depend heavily on the runtime environment (the scaffold) and the thinking level, not just the model. So the order of the same two models on the same test flips depending on who measured. Blue is the value AA measured itself, and orange is the value Moonshot announced.

Figure 4. On Terminal-Bench, K3.1 Pro leads in AA’s measurement while Opus 5.5 leads in Moonshot’s announcement

On Terminal-Bench 4.0, AA measured K3.1 Pro at 67% and Opus 5.5 at 60%, while Moonshot’s table has 65.7 vs 66.4. “Kimi came out ahead” and “Opus was ahead by 0.7 points” can both be true sentences because most of the coding comparisons in Moonshot’s table were run on the Claude Code harness at the highest thinking level, while the other models’ scores were taken from each vendor’s announcements or public leaderboards, so the conditions are mixed. On HLE, by contrast, Opus 5.5 leads in both places (52 vs 61 at AA, 51.1 vs 59.8 with no tools at Moonshot), so the direction agrees. A row where the direction agrees has more reason to be trusted, and for a row where the sources split, suspect environment differences first.

Here is the full table Moonshot published. It claims first place in 16 of 47 rows, which also means other models lead in the remaining 31.

Moonshot’s published figures	K3.1 Pro	Claude Opus 5.5	GPT-6 Astra
Terminal-Bench 4.0	65.7	66.4	58.2
DeepSWE v1.1	75.5	74.2	74.1
SWE-Marathon (long coding)	51.7	46.3	42.5
HLE-Full, with tools	70.0	67.7	57.2
HLE-Full, no tools	51.1	59.8	53.6
GPQA Diamond	94.2	93.9	96.1
BenchCAD, with tools	92.7	96.2	95.9
Terminal-Bench Science	38.1	63.3	68.1

One pattern stands out in this table: strong with tools, weak bare. On HLE, K3.1 Pro is highest at 70.0 with tools but falls short of Opus 5.5’s 59.8 with 51.1 without them. The score when run as an agent and the knowledge the model carries in its head are different matters. Terminal-Bench Science, which solves science problems as an agent (38.1 vs 63.3 and 68.1), and ProgramBench, a program-implementation test (31.5 vs Opus 5.5’s 65.0), are on the same weak side.

What rose and what stayed the same since K3

For how much changed from K3, the values AA measured itself are the most trustworthy. The biggest movement is in terminal tasks.

Independent measurement (AA)	K3	K3.1 Pro	Comparison
Terminal-Bench 4.0	13%	67%	Opus 5.5 60%, Sonnet 5.5 64%
GDPval-AA (work deliverables, Elo)	1,534	1,846	Opus 5.5 1,866
AutomationBench-AA	58%	73%	Opus 5.5 70%
Humanity’s Last Exam	47%	52%	Opus 5.5 61%
CritPt	23%	25%	Opus 5.5 32%
SciCode	59%	61%	Opus 5.5 67%

On office deliverables and automation it is on par with or ahead of Opus 5.5, and it is still behind on knowledge without tools (HLE) and on science tests (CritPt, SciCode). AA’s outlook is that the roughly 12-point index gap between open and closed models narrows to 3 points once the weights are released.

What Moonshot leads with as the improvement is hallucination (unsupported claims). On Moonshot’s internal test Kimi Hallu Bench Hard, K3’s error rate of 23.4% dropped to 8.3% for K3.1 Pro, but Moonshot itself states that this test was built from deliberately error-prone questions and is not an everyday error rate. On the independent AA-Omniscience, the hallucination rate moved from 53% to 44% and accuracy from 48% to 51%. It went down, but it is still a level that needs verification for work that requires fact-checking.

Only 104B of 2.8T does the work

The number “2.8 trillion parameters” alone makes it sound as if all of it is computed on every call, but a Mixture-of-Experts (MoE) architecture does not work that way. The model contains 896 expert blocks, and each time a token arrives, a router picks only 16 of them to compute. Because some parts are always traversed for every token, about 104B parameters in total are active (about 3.7% of the whole).

Figure 5. The 880 experts are only stored and take no part in this token’s computation

This is part of the background that allowed the price to fall, and it connects to the fact that this model was not newly designed but is the same architecture as K3 (released July 16) with substantial reinforcement-learning-centered post-training added. That is why it is called 3.1 rather than K4, and why the context window of 1,048,576 tokens, with text and image input and text output, matches K3. The context window is the amount of tokens a model reads and remembers at once; 1 million tokens holds several books, and the unit price is the same whether or not you use that length. The default maximum output is 131,072 tokens and can be raised to 1,048,576 tokens through a setting.

You can use it in the Kimi web and app (the free plan has usage limits), the Kimi Work desktop app (v3.1.0 or later), Kimi Code (switch with /model), and the Kimi API. Highspeed requires a Pro plan or higher in the app and uses roughly double the quota in Kimi Code. For enterprise organizations access is off by default and an administrator must turn it on, and the API opens with a minimum $1 top-up, with call limits set by cumulative top-up amount.

A model with its cyber capability deliberately trimmed

The design decision that stands out in K3.1 Pro is that cyber-attack-related material was removed from training ahead of releasing the weights. Moonshot says it removed cyber-related content at two stages, the mid-training data and the reinforcement-learning environments, while keeping general coding tasks.

The effect shows up in Moonshot’s internal test xdev-bench-hard (tasks that write vulnerability-exploitation code, passing if any of 3 attempts succeeds). The checkpoint without the data removed scored 90.5%, and the public K3.1 Pro scored 81.0%, 9.5 points lower. On the same test, K3 scored 33.3%, GLM-5.3 57.1%, and DeepSeek V4.1 Flash 85.7%. These numbers come from Moonshot’s internal test with no outside verification, and Moonshot explains that this capability lags commercial frontier models released at least 3 months earlier.

The independent numbers point a different way. On AA’s cyber index, K3 rose from 41% to 64% with K3.1 Pro, ahead of DeepSeek V4.1 Flash (57%) but short of an access-restricted model (69%). AA also reported that Kimi showed no safety refusals on these tasks. That is welcome for people who want to use it for defensive work (finding, reproducing, and patching vulnerabilities), but it also means access controls must be designed along with any tool you attach it to. Released weights cannot be recalled, and one vendor has already said it will strip out the safeguards after release. A capability that was left out of training, however, does not appear just because safeguards are stripped.

Seven snags when moving K3 code over

The call itself is easy. Just change the base URL and you can call it with the OpenAI SDK as is; below is a minimal example following the official quick-start guide.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.ai/v1",
)

resp = client.chat.completions.create(
    model="kimi-k3.1-pro",  # for fast responses use kimi-k3.1-pro-highspeed
    messages=[{"role": "user", "content": "Find the cause of the error in this log: ..."}],
    # thinking level: low, high, max (default max). The SDK doesn't know this field, so pass it via extra_body
    extra_body={"reasoning_effort": "low"},
    # do not pass temperature or top_p (fixed values)
)
print(resp.choices[0].message.content)
print(resp.usage)  # check input and output token counts against the bill

Going through the constraints carried over from K3 one by one makes the move less painful.

1. Thinking cannot be turned off. Use low to cut latency; the default max uses the most tokens.
2. Sampling values are fixed. They are temperature 1.0, top_p 0.95, n 1, and penalties 0, and the docs tell you to leave them out of the request. There are also reports that passing other values causes an error.
3. Send the whole assistant message back. In multi-turn use and tool calls, you must include the reasoning_content and tool_calls the API returned in the next request as they are.
4. Images and video cannot be public URLs. Pass them as base64 or an uploaded file ID.
5. Caching is automatic and block-based. The default is 5 minutes, you can choose 1 hour with prompt_cache_options.ttl, and a block that is not full is not cached.
6. Changing the thinking level breaks the cache. Set a level per task type and keep it fixed during a conversation.
7. The web search tool is not recommended for production. Moonshot says so in its current documentation.

Now consider two situations. If you already run a customer-support chatbot on K2.6, K2.6 had a mode that turned thinking off and K3.1 Pro does not, so responses to the same question may get slower; match the thinking level and measure latency again. If your existing code calls with temperature=0.2 for consistency, you must remove that value, and your tests need to account for responses that can differ even for the same input. The K2 family closes to new sign-ups from Oct 31 and all K2 models are planned to be shut down by the end of December (existing users are not affected right now), so you need to schedule the migration. The context window is 256K (262,144) for K2.6 and K2.7 Code and 1M for the K3 family.

Two things to know about data handling. Moonshot says API customers can use Zero Data Retention, and the upload, extraction, and storage API for extracting documents from uploaded files is temporarily free for now, but content that is extracted and fed to the model is billed as input tokens.

Two questions before you pay

Is Highspeed worth paying double for?

For an interactive service where a user waits at the screen for an answer, waiting time is itself a cost, so it is worth considering. Moonshot says the speed is 2 to 3 times the base model, and the unit price is exactly double at $4 input and $20 output. But as we saw above, the receipt is decided by token count rather than unit price, so lowering the thinking level to low is the first thing to try for both cost and speed. For batch jobs that run overnight, where waiting is not a cost, the base model is the right choice.

Can I run it on a personal PC once the weights are released?

Realistically, it is hard. With 2.8T parameters, even K3’s model card recommends server-grade inference engines such as vLLM, SGLang, and TokenSpeed, and technical write-ups say a multi-GPU server is needed. The practical meaning of releasing the weights is less that individuals run it themselves than that hosting providers sell the same model at their own prices, and AA’s page for this model already lists 5 API providers.

While waiting for the weights

The upcoming schedule is short. K3 opened first through the API and app on July 16, and its weights appeared on Hugging Face about ten days later. K3.1 Pro opened on Oct 23, new sign-ups for the K2 family close from Oct 31, and Moonshot says it will release the weights by Nov 4. As of Oct 27, there is no K3.1 repository on the moonshotai account on Hugging Face, and the K2 models are scheduled to shut down at the end of December. K3’s weights were released under a custom license called the Kimi K3 License, so if you plan commercial self-hosting, the first step is to read the license text that arrives with the K3.1 weights.

Every number in this article carries a date. The cost per task that was $1.98 on launch day became $2.11 four days later, and even the output speed was written differently, 51.5 tokens per second on AA’s page and 57.5 by another outlet. Once the weights are released and providers multiply, price and speed will differ per provider and the same model’s numbers will split again. In front of a model like this, the habit of noting “who measured, on which day, with which settings” alongside a single model’s score stays useful longer than the price list.