Kimi K3's documentation says thinking cannot be turned off, and that reasoning_effort accepts only "max". In our measurements the API accepts "none" anyway, and it works: the same trivial question that costs $0.00179 with default reasoning costs $0.000285 without it, a 6.3x difference. K3 launched on 2026-07-16 at $3 per million input tokens and $15 per million output, the most expensive list price a Chinese lab has shipped and the same sticker as Claude Sonnet 5. At that output price, the reasoning tokens the model spends by default are the bill, which makes the undocumented off-switch worth understanding precisely.
TL;DR
- Kimi K3 spends 69-93% of its output tokens on reasoning at default settings; a 120-word paragraph billed 2,289 output tokens, $0.0346.
-
reasoning_effort: "none"is accepted despite docs saying otherwise, and cut our simple-query cost 6.3x, but multi-step arithmetic went from 3/3 correct to 0/6. - Kimi K3's prompt cache hits from roughly 256 tokens of prefix, in 256-token blocks, at a $0.30/M read rate.
- Chinese is K3's cheapest CJK lane: 52 net tokens per 100 characters, below GLM-5.2 and DeepSeek at 58.
Everything below was measured on 2026-07-20 against kimi-k3, which is live on the Synthorai gateway at Moonshot's list prices, with repeated prompts salted to defeat response caches and the behavioral claims cross-checked on a second, independent request path. Raw usage records back every number.
What does Kimi K3 cost per answer by default?
Reasoning dominates the bill on every task shape we sent, including ones that need no reasoning at all. Per answer, at default settings:
| Task | Output tokens | Reasoning share | Cost per answer |
|---|---|---|---|
| Trivial arithmetic (17×23) | 99 | 84% | $0.0018 |
| Factual one-liner | 80 | 79% | $0.0015 |
| Small code function | 119 | 69% | $0.0009 |
| Multi-step word problem | 139 | 87% | $0.0025 |
| 120-word paragraph | 2,289 | 93% | $0.0346 |
The cross-model contrast is the point of the chart: GPT-5.6 reasons adaptively (zero thinking tokens on the trivial and factual questions, 65-70% on math and writing), Claude Sonnet 5 ships with thinking off, and GLM-5.2 thinks even harder than K3 in relative terms. But GLM's output price is $4.40/M and K3's is $15/M, so the same 17×23 answer billed $0.00078 on GLM-5.2, $0.00027 on GPT-5.6, $0.0001 on Sonnet 5, and $0.0018 on K3. The gap widens with output length: the identical 120-word paragraph cost $0.0346 on K3 against $0.0186 on GLM-5.2, $0.0072 on GPT-5.6, and $0.0024 on Sonnet 5, a 15x spread on the most ordinary task in the set. The tax rate is comparable to other Chinese reasoning models; the tax bill is not.
Two more default-mode facts worth budgeting for. First, thinking mode injects a hidden preamble of about 67 tokens into every request: an identical one-word message billed 86 prompt tokens with reasoning on and 19 with it off. That is the "hidden system prompt" early testers noticed, and it disappears when reasoning does. Second, K3 is slow at the moment: our trivial-question calls took roughly 19-24 seconds end to end with reasoning on and 3-8 seconds with it off, launch-week serving included. Budget latency, not just dollars.
Can you turn Kimi K3's reasoning off?
Yes, despite the documentation. The official API reference states that K3 "always enables thinking" and that reasoning_effort accepts only "max". In practice the endpoint accepted "none", "low", "medium", and "high" without error, honored them, and we confirmed the same behavior on an independent request path. On the multi-step word problem, the dial is real but coarse:
reasoning_effort |
Reasoning tokens (avg) | Accuracy |
|---|---|---|
none |
0 | 0/6 |
low |
78 | 3/3 |
medium |
94 | 3/3 |
high |
105 | 3/3 |
max / default |
100-121 | 3/3 |
Two things stand out. The intermediate settings cluster: low through max bought similar token counts and identical accuracy on this task, so the meaningful switch is binary. And none has a real cliff: forced to answer a multi-step arithmetic problem tersely, K3 got it wrong six times out of six, with scattered wrong answers rather than one systematic error. When we did not force a terse format, the model sometimes ignored brevity and worked through the steps in its visible answer instead: correct, but the tokens moved from the reasoning field into the text field rather than disappearing.
Latency moves less than the token counts suggest. Streaming the same problem at every effort level, first-byte times ranged 6-24 seconds with the effort levels' ranges overlapping heavily; even none, with nothing to think about, waited 12-13 seconds, so serving dominates time to first token at this task size. What the dial actually changes is the gap between the first byte and the first answer token, which is the thinking phase the user sits through.
The practical reading: none is a genuine cost lever for tasks that are retrieval, formatting, or single-step, and a footgun for anything that needs intermediate steps. There is no documented guarantee this parameter keeps working; treat it as measured behavior, verify it in your own usage fields, and expect it may be formalized or removed when the docs catch up.
When should reasoning stay on in agent workloads?
We ran K3 through five agent-shaped scenarios twice, default versus reasoning_effort: "none", with identical simple tasks that both configurations passed in full:
| Scenario | Thinking share (default) | Cost with none
|
TTFT with none
|
|---|---|---|---|
| Tool-call loop | 8% | −10% | −35% |
| RAG answering | 71% | −37% | −53% |
| Structured tooling | 29% | −16% | −31% |
| Batch extraction | 80% | −15% | −11% |
| Long chat (15 turns) | 34% | −13% | −25% |
The surprise is the first row: in tool-call loops K3 barely thinks even at default settings (8% share), so there is little to save; the model treats tool selection as reflex, not deliberation. The savings concentrate where thinking share is high and the task is mechanical (RAG lookups and batch extraction), which is exactly where a fixed always-on tax least belongs. For genuinely multi-step agent plans, the previous section's accuracy cliff applies; leave reasoning on and spend the tokens.
At scale the latency effect is real even though single calls are noisy: across these scenarios first tokens arrived in 10-19 seconds at default settings and 8-13 seconds with none, and generation ran at a median 35 tokens per second on substantive outputs. Those numbers, launch-week serving included, fit asynchronous and batch shapes better than anything conversational today.
Does the reasoning you pass back re-bill as input?
Yes, token for token. Kimi's docs tell you to keep reasoning_content from every assistant turn in the message history unmodified. We measured what that costs: a second turn sent with the first turn's chain of thought billed 599 prompt tokens; the identical request without it billed 198. The 401-token difference matches the first turn's 402 reasoning tokens almost exactly, so retained thinking re-enters every subsequent request at the full $3/M input rate, and a long conversation re-pays its accumulated reasoning on every turn.
Dropping it is not automatically cheaper, though. Without the prior chain of thought, K3 re-reasoned the follow-up from scratch: reasoning tokens on the second turn rose 31% (343 to 449). At $3/M input against $15/M output, keeping the CoT was the net-cheaper option in our probe, which means the docs' advice holds on cost grounds as well as quality ones. The lever that actually pays here is the prompt cache from the next section: retained history is a stable prefix, and stable prefixes stop billing at full price.
Does Kimi K3 cache prompts, and from how many tokens?
K3's prompt cache is automatic, and its floor is low: hits started at roughly 256 tokens of shared prefix and advanced in 256-token blocks (a 303-token prompt cached 256; a 153-token prompt never cached across repeated attempts). Cached input bills at $0.30/M, a flat 90% discount against the $3/M fresh rate, with no cache-write premium on any call we issued. Warm-up took two to five identical calls before the first hit, so a single retry proves nothing either way; measure across several.
For context, that floor is a quarter of OpenAI's documented 1,024-token minimum, and the block size is coarser than the 64-token granularity we measured elsewhere. Lifetime is best-effort rather than a fixed TTL: cached entries in our probe survived idle gaps of 4 and 15 minutes while one 8-minute gap missed, so treat expiry as load-dependent eviction and verify the cached split on every call. One more pricing fact worth arithmetic: the 1M-token context window is priced flat, with no long-context tier on the price list. A maxed-out window is $3.00 of fresh input per call, and $0.30 once the prefix is warm, so large-context workloads live or die by the cache far more than by the sticker. If your traffic reuses a system prompt of even a few hundred tokens, K3's cache engages where most providers' would not have started yet; the mechanics and how to verify hits from usage are covered in our prompt caching guide and the measured cache minimums study.
Is Chinese actually more expensive on Kimi K3?
No. Chinese is where K3's tokenizer is most efficient relative to peers, which answers a question raised repeatedly in launch-week discussions. Net tokens per 100 characters on semantically aligned passages, envelope overhead subtracted:
| Model | en | zh | ja | ko | hi | Python |
|---|---|---|---|---|---|---|
| kimi-k3 | 19.7 | 51.9 | 87.5 | 83.2 | 62.8 | 26.5 |
| glm-5.2 | 19.7 | 58.4 | 75.7 | 76.9 | 91.3 | 25.6 |
| deepseek-v4-flash | 19.7 | 58.4 | 70.6 | 69.2 | 60.7 | 26.7 |
| claude-sonnet-5 | 32.3 | 114.3 | 94.1 | 106.3 | 70.9 | 41.1 |
K3 bills Chinese at 52 tokens per 100 characters, 11% under GLM-5.2 and DeepSeek and less than half of Sonnet 5. Its weak lane is Japanese, where it pays 16-24% more than the other open-weight models. We also confirmed the tokenizer is unchanged across the family: K3, K2.7-code, and K2.5 produced identical counts on all 23 aligned samples, so per-language budgets built for K2 carry over. How tokenizer density compounds with per-token price across nine languages is the subject of our cheapest LLM by language study.
FAQ
When will Kimi K3's open weights be released?
Moonshot has promised full weights under a Modified MIT license by July 27, 2026; as of this post K3 is API-only. The "largest open-weight model ever" framing is a commitment, not yet a download link.
What is actually new in K3 compared with the K2 family?
On the bill, three things we measured: the price (K3's $3/$15 versus K2.7-code at $0.95/$4, a 3.2-3.75x jump), always-on thinking (K2.5 does not reason at all, K2.7-code has a toggle), and nothing else: the tokenizer is byte-identical across K3, K2.7-code, and K2.5 on all 23 of our aligned samples, so K2-era token budgets carry over. On the spec sheet, per Moonshot: a new 2.8T-parameter MoE (896 experts, 16 active per token) with Kimi Delta Attention, a 1M-token context window against K2.7-code's 256K, and native image input. We measured the billing claims, not the architecture ones.
Does Kimi K3 support structured output?
Yes. A response_format with json_schema returned a valid, schema-conforming object in our probe. Note that reasoning still runs underneath: 66 of the 97 output tokens on that extraction call were reasoning, so schema-constrained calls pay the thinking tax like everything else unless you also set reasoning_effort: "none".
Does turning reasoning off change what you can see?
Yes. At default settings K3 returns its full chain of thought in reasoning_content, and the docs advise passing it back unmodified in multi-turn history. With reasoning_effort: "none" the field is absent entirely, and the ~67-token thinking preamble disappears from your prompt bill with it.
Measured 2026-07-20 on kimi-k3 at launch-week list prices ($3/M input, $0.30/M cached, $15/M output). Repeated prompts were salted to avoid response-level caches; accuracy counts use tasks with single checkable answers; behavioral claims were reproduced on a second, independent request path. Prices and behavior may change as the release matures; verify against your own usage records before relying on any number here.
Top comments (0)