Kimi K3

Why this oneWhat it is actually for

You reach for Kimi K3 when the job is long-horizon coding or agent work, the input is enormous, and you want frontier-class output at a fifth of what the US flagships charge for output tokens. The 1M window means a repository or a full document corpus goes in without chunking, and the cache-hit rate of $0.30 per million makes a fixed system prompt or codebase preamble nearly free to re-send. You reach for something else if you need deterministic sampling — K3 does not accept temperature or top_p at all — if you need a batch discount, or if your compliance posture cannot route data to a Chinese API endpoint. There is no self-host escape hatch yet either.

What it isArchitecture, lineage, training

Kimi K3 is a sparse mixture-of-experts model. Moonshot's own model list on the Kimi API Platform describes it as having "2.8 trillion parameters" with visual understanding and a 1M-token context window. That parameter count is the only architectural number this page could confirm from a Moonshot-controlled page.

The figures circulating elsewhere — that it routes the top 16 of 896 experts per token, that it is built on Kimi Delta Attention and Attention Residuals — appear in press coverage and third-party write-ups, not on any Moonshot documentation page read for this article. They are plausible and consistent, but they are not confirmed here, so they are not stated here as fact.

The open-weight question matters more than the architecture, and it has a clear answer today. As of 2026-07-25 there is no Kimi-K3 repository on the moonshotai Hugging Face organisation. The newest repositories there are Kimi-K2.7-Code, Kimi-K2.6 and Kimi-K2.5. So while K3 is widely described as an open-weight release, the weights were not published at the time of writing and no licence has been announced on a Moonshot page. Treat "open-weight" as a stated intention, not a present capability.

What is unambiguous is the serving behaviour, because Moonshot documents it precisely. K3 always runs with thinking enabled — the docs call it "Preserved Thinking" — and the only control over how hard it thinks is a top-level reasoning_effort field taking low, high or max, defaulting to max. The generation parameters that other models expose are fixed on the server side rather than exposed to you.

At a glanceSee it

How a Kimi K3 request is priced and shaped, from cached prefix through always-on thinking to billed output.

CapacityContext, output and what fits

The parametersEvery knob, and what moving it does

Two knobs actually matter. reasoning_effort is the whole steering wheel — it is the only thing that changes how the model deliberates, and since thinking is billed inside the $15 output rate, moving it from max to low is the most direct cost control you have. After that, response_format with a JSON schema is what buys back the determinism you lost when Moonshot took away temperature. Everything else is plumbing.

SamplingShaping the output distribution

There is nothing to tune. Moonshot's chat API reference lists temperature, top_p, n, presence_penalty and frequency_penalty as unsupported for kimi-k3, and the K3 quickstart states the server holds them at temperature=1.0, top_p=0.95, n=1 and both penalties at 0. That is a deliberate design: the model is tuned as a thinking model at one operating point, and Moonshot does not want callers moving off it. The practical consequence is that you cannot make K3 more deterministic by turning temperature down, and you cannot widen it for brainstorming either. Repeated identical requests will vary. If you need low-variance structured output, get it from response_format with a JSON schema rather than from sampling, and use logprobs if you need a confidence signal. If you genuinely need a temperature dial on a Moonshot model, the moonshot-v1-* generation still exposes one; K3 does not.

ReasoningThinking, effort and budgets

Thinking is always on and cannot be disabled. There is no thinking object on K3 the way there is on Kimi K2.6 and K2.5 — instead K3 takes a top-level reasoning_effort string accepting low, high or max, with max as the default. The docs describe the behaviour as "Preserved Thinking", and reasoning is visible: the streamed response carries separate reasoning_content and content deltas, and the non-streaming message exposes a reasoning_content attribute. There is no token-budget parameter — you get three coarse levels, not a numeric cap, which is a real limitation next to the numeric budgets Alibaba and Anthropic expose. Whether thinking tokens are billed at the output rate is not stated on the K3 pricing page; the honest assumption is that they are, since they are generated tokens, but that is inference and not a documented fact. Because max is the default, the expensive setting is what you get if you send nothing.

ToolsFunction calling and server tools

Function calling works and parallelism is explicit: the tool-calls guide states the model "can return multiple tool_calls at once" and notes it will tend to call independent tools in parallel, so your executor should fan out rather than loop. tool_choice accepts auto, none, required or a named function, and structured output is available through response_format including json_schema. There is no documented built-in server-side web search tool for K3 — Moonshot's own examples build search and crawl as ordinary user-defined tools with JSON Schema. Three failure modes are called out in the docs and worth pre-empting. First, every tool_call must be answered by a matching message with role=tool and the correct tool_call_id, or the next request errors. Second, the tools block itself is counted in your input tokens, so a fat tool registry is a per-turn tax. Third, when streaming, delta.tool_calls arrives only after delta.content finishes — parsers that assume interleaving will hang.

CostPrice, caching, batching, what drives the bill

List price from Moonshot's own Kimi K3 pricing page, in USD per million tokens:

The page states "Prices exclude applicable taxes" and shows no context-length tiering and no volume discount. Three things drive the actual bill. Caching is automatic — "Context Caching is automatically enabled for all model requests", no parameter required — but a cache hit only happens if the previous request's prompt tokens exceeded 256, so short prompts never cache; the 10x discount is real and applies to the repeated prefix only. Second, there is no batch discount available here: Moonshot's Batch API prices inference at 60% of the standard rate but lists only kimi-k2.7-code, kimi-k2.6 and kimi-k2.5 as eligible, not kimi-k3. Third, output is 5x input and thinking is always on at max by default, so output dominates unless you lower reasoning_effort. On vision input, the K3 pricing page publishes no separate image or video token rate and no resolution-based billing formula — how multimodal input is metered could not be confirmed. The vision guide gives only operational guidance: images should be no larger than 4K resolution and videos no larger than 1080p.

Where it runsSurfaces and availability

StrengthsWhat it is good at

• 1,048,576-token context with a documented path to 1M output tokens via max_completion_tokens — the input and output ceilings are the same number, which is unusual.
• Cache-hit input at $0.30 per million against a $3.00 miss rate, applied automatically with no cache-control parameter to manage.
• Parallel tool calls are documented behaviour, not an accident: the guide explicitly tells you to execute returned tool_calls concurrently.
• Native video understanding alongside images — the vision guide lists mp4, mov and webm for K3, which most competitors at this tier do not accept.
• Reasoning is visible: reasoning_content streams separately from content, so you can log or display the deliberation.

LimitsWhere it falls down

• No sampling control at all. temperature, top_p, n and both penalties are unsupported, so you cannot tighten or widen the distribution for a given task.
• Weights are not published. No Kimi-K3 repository exists on the moonshotai Hugging Face organisation as of 2026-07-25, and no licence has been announced, so "open-weight" is a promise rather than a fact you can act on.
• No batch discount. The BatchJob pricing page lists K2.7-Code, K2.6 and K2.5 as eligible; K3 is not among them.
• Thinking cannot be turned off, and the budget is three coarse levels rather than a token cap — awkward for latency-sensitive classification work.
• Not on Bedrock, Vertex or Microsoft Foundry, so the vendor API is the only route, with the jurisdictional consequences that implies.

Against its neighboursHow it compares

Against DeepSeek V4 Pro, the comparison is stark on price: DeepSeek charges $1.32 in and $3.96 out per million at peak, and half that off-peak, against Kimi's $3.00 and $15.00 — roughly 3.8x cheaper on output at peak and 7.6x off-peak — for the same 1M context. DeepSeek also gives you temperature, top_p, a thinking toggle you can switch off, and MIT-licensed weights you can actually download. Kimi's claim is native vision and video, which DeepSeek V4 does not have at all, and a stronger reported coding profile. Against Claude Fable 5, Kimi is the budget option with a comparable context window, but Fable is available on Bedrock, Vertex and Foundry with the procurement and residency options that brings, while Kimi is vendor-API-only today.

Getting startedThe smallest call that works

POST https://api.moonshot.ai/v1/chat/completions
Authorization: Bearer $MOONSHOT_API_KEY
Content-Type: application/json

{
  "model": "kimi-k3",
  "messages": [
    {"role": "user", "content": "Introduce Kimi K3 in one sentence."}
  ]
}

Change reasoning_effort first — add "reasoning_effort": "low" and watch latency and output tokens fall, because the default is max. Then add "stream": true with "stream_options": {"include_usage": true} so you can see the cache-hit split. Do not bother adding temperature; it is not supported and will not do anything.

SourcesWhere every claim above came from

• Kimi K3 — Kimi API Platform
• Flagship Model Kimi K3 Pricing — Kimi API Platform
• Create Chat Completion — Kimi API Platform
• Model List — Kimi API Platform
• Reasoning Effort — Kimi API Platform
• Tool Calls — Kimi API Platform
• Configure Kimi Vision Models — Kimi API Platform
• Context Caching — Kimi API Platform
• BatchJob Pricing — Kimi API Platform
• moonshotai — Hugging Face organisation
• moonshotai/Kimi-K3 — Hugging Face model card
• Models at a glance — Amazon Bedrock
• Foundry Models sold by Azure — Microsoft Foundry
• Could not confirm from a primary source as of 2026-07-25: the expert count and per-token routing (widely reported as 16 of 896), the Kimi Delta Attention and Attention Residuals architecture claims, the release date, the knowledge cutoff, whether thinking tokens are billed separately from output tokens, and any open-weight licence. None of these appear on a Moonshot-controlled page read for this article.

RelatedGo deeper