Kimi K3: The Complete Guide to Moonshot's 2.8T Flagship

Moonshot AI shipped Kimi K3 in mid-July 2026, and it did so backwards: the API documentation, the pricing page, and a live kimi-k3 model ID appeared before any benchmark table, tech blog post, or weight release^[1]. A week of leak threads filled the vacuum, and most of what circulated was wrong in at least one dimension. This guide is the version assembled from Moonshot's own documentation — what is confirmed, what is deliberately fixed, and what is still unpublished.

It is also written from a specific vantage point: we serve Kimi K3 on the reAPI gateway, so the sections below cover not just what the model is, but what calling it actually looks like — the parameters that will reject your request, the caching behavior that decides your bill, and the migration traps waiting for K2.x code.

TL;DR

• Kimi K3 is a 2.8-trillion-parameter flagship built on Kimi Delta Attention (a hybrid linear attention mechanism) plus Attention Residuals, with a Stable LatentMoE that activates 16 of 896 experts per token^[1][3].
• The context window is 1,048,576 tokens with flat pricing — no long-context tier — and output defaults to 131,072 tokens, raisable to the full window^[1][2].
• Reasoning is always on. The only lever is a three-rung reasoning_effort dial (low / high / max, no medium), and it defaults to max^[4].
• Sampling is locked: temperature 1.0, top_p 0.95, n 1, both penalties 0. Sending anything else returns an error^[1].
• Moonshot's published rate is $3.00 input / $15.00 output per 1M tokens (cache-hit input $0.30). On reAPI the same model runs $2.50 / $12.00 — below the published rate on both dimensions^[2][8].
• Vision is native (image and video input), but public image URLs are rejected — base64 or an uploaded file reference only^[5].

Kimi K3 at a glance

Everything in this table comes from Moonshot's API documentation, retrieved July 26, 2026:

Two numbers deserve a second look. The parameter count — 2.8T — puts K3 in a class no open-weight model has occupied before, and Moonshot has committed to releasing weights, which would make it the first open-source model in the 3-trillion class^[3]. And the pricing: at $3.00 / $15.00, K3 costs three to four times what the K2 line did. Moonshot is pricing this as a frontier flagship, not the value play the Kimi name used to imply — while still undercutting the closed frontier models on both sides of the ledger.

The launch: API first, paper trail later

The rollout order is worth understanding because it explains the conflicting information still circulating. In the days before launch, community trackers caught a promo page flashing on Moonshot's platform and beta selectors surfacing in the Kimi app; the consensus leak settled on "~2.5T parameters, 1M context." Close, but the official figure is 2.8T. A wordless teaser video from Moonshot's official account followed, and then the product outpaced the press cycle: the API docs, quickstart, and pricing page went live the same day the first financial reporting on the launch appeared^[1][2].

That sequencing — API and docs before benchmarks and weights — is the reverse of how the K2 flagships launched, each of which arrived with a full tech blog and open weights on day one. The practical consequence: for the first week of K3's life, the documentation was the only reliable source, and everything else was inference.

Architecture: Kimi Delta Attention, LatentMoE, Attention Residuals

The most technically interesting line in the K3 docs is that the model is "built on Kimi Delta Attention, a hybrid linear attention mechanism, and Attention Residuals"^[3]. This is not marketing vocabulary — it is a production deployment of the Kimi Linear research line Moonshot published in late 2025, and understanding it explains both the 1M-token window and the flat pricing that makes the window usable^[6].

Kimi Delta Attention (KDA) is a linear attention mechanism — a refinement of Gated DeltaNet with finer-grained gating. Standard softmax attention grows its key-value cache linearly with sequence length, which is what makes million-token contexts ruinously expensive to serve. Linear attention maintains a fixed-size recurrent state instead. The historical cost was quality: pure linear attention loses precise recall over long documents.

The hybrid layout is how the Kimi Linear paper resolved that trade-off: interleave KDA layers with full-attention layers at a 3:1 ratio, so three of every four layers use the cheap linear mechanism while every fourth retains exact global attention. In the published results this configuration outperformed full attention on quality benchmarks while cutting KV-cache memory by up to 75% and decoding up to 6x faster at 1M-token contexts^[6].

Stable LatentMoE is the sparse mixture-of-experts configuration: 896 experts with 16 active per token^[3]. That sparsity is what keeps a 2.8T model servable at all — the active compute per token is a small fraction of the total parameter count.

Attention Residuals is the one component with no published paper behind it yet; the term first appears in the K3 documentation itself. Until a technical report lands, the honest position is that we know the name and not the mechanism.

Why this matters practically: a 1M-token context is only as good as its economics. Most providers that offer very long contexts either tier the pricing upward or quietly degrade. K3's docs state there is no tiering — the same per-token rate applies whether you send 5,000 tokens or 900,000^[2]. That pricing decision is only rational if the marginal cost of long context really has collapsed, which is exactly what KDA is for. The architecture is the pricing story.

What the API actually ships

The K3 API surface is opinionated in ways that will surprise teams migrating from K2.x or from OpenAI-style models. These are documented constraints, not observations^[1]:

• Reasoning is always on. There is no non-thinking mode — Moonshot's own FAQ answers "how do I turn off the chain of thought" with a flat you can't. The lever is reasoning_effort, a top-level field with three rungs: low, high, and max. There is no medium, and the default is the most expensive rung, max^[4].
• Sampling is fixed. temperature is locked at 1.0, top_p at 0.95, n at 1, and both penalty parameters at 0. Passing any other value returns an error, so requests should simply omit them. If your pipeline tunes temperature per task, that lever is gone.
• Output ceilings are enormous. max_completion_tokens defaults to 131,072 and can be raised to the full 1,048,576 — a single call can, in principle, emit a million tokens. Long-form generation (full codebases, book-length drafts, multi-file refactors) is clearly a design target.
• Streaming separates reasoning from answers. Streamed responses carry reasoning_content deltas distinct from content deltas, so a UI can render the thinking trace separately from the final answer.
• Preserved Thinking is mandatory. In multi-turn and tool-call loops, the complete assistant message — including reasoning_content and tool_calls — must go back into messages unchanged. Trimming to content alone, the habit most OpenAI-shaped code has, silently degrades the model.
• Vision has sharp edges. Image and video input are native, but public image URLs are not accepted — you send base64 data URIs or upload files and reference them by file ID^[5].
• Structured output is first-class. A JSON Schema with strict: true constrains the final answer field (not the reasoning, which is prose).

The new tool-calling stack

Two capabilities debut with K3, and both target the same problem: agents with large tool inventories burning context on tool definitions^[1].

tool_choice: "required" forces at least one tool call on a turn — the way to stop an agent answering from memory when it was supposed to look something up. The K2 models reject this value; K3 accepts it.

Dynamic tool loading is the more novel one: place a complete tool definition inside a system message mid-conversation (a tools field with no content), and the tool becomes available from that point onward. Instead of front-loading 80 tool schemas into every request, an orchestrator injects tools exactly when a workflow phase needs them. One caveat: the server does not retain a dynamically loaded tool — keep that system message in your request history or the tool disappears next turn.

A warning from the docs worth repeating: Moonshot's built-in web_search tool is flagged as being updated and is not recommended for production use right now. If your agent needs search, bring your own.

Automatic context caching

K3's context caching requires no cache IDs, TTL management, or extra parameters — keep a long prefix stable across requests and the platform attempts a cache hit on its own, billed at $0.30 per 1M tokens instead of $3.00^[1]. That is a 90% discount on repeated context, and it is the difference between the 1M window being a demo feature and a working pattern: load a corpus once as a stable prefix, then iterate against it at one-tenth the price.

Two conditions decide whether the hit happens. The previous request's prompt tokens must exceed 256 — below that, nothing is cached. And the reasoning_effort rung must not change: switching effort mid-conversation invalidates the prefix cache^[4]. Pick the rung before the conversation starts.

Early third-party telemetry suggests the pattern works as advertised: OpenRouter's live stats for K3 have shown a cache hit rate above 75% across traffic, pulling the weighted average input price well under a third of list^[7].

Pricing: a deliberate break from the value playbook

Every Kimi release until now competed primarily on cost. K3 does not. Here is where it sits against its own family and the frontier competition (per 1M tokens, cache-miss input rates):

The positioning is legible at a glance: K3 costs three to four times its own siblings and 40–50% less than the closed frontier. Moonshot is betting that a 1M-token window, native video input, and frontier-class capability justify a premium tier within the open-weight world.

Speed is the honest asterisk on that bet. Early third-party telemetry shows K3 producing roughly 28 tokens per second with a time-to-first-token around four seconds^[7] — unsurprising for an always-on reasoning model at this scale, but slow. K3 is built for depth-per-call, not calls-per-minute; latency-sensitive interactive loops belong on a different model.

One housekeeping note: Moonshot is pruning the lineup aggressively alongside the launch. The legacy moonshot-v1 series and older K2.x variants are closed to new users, with a full platform sunset announced for the end of August 2026. Moonshot wants everyone on K3.

Migrating from K2.x: a practical checklist

If you run K2.6 or K2.7-Code today, the migration surface is small but real:

1. Swap the model ID to kimi-k3 — the API remains OpenAI-compatible.
2. Replace the thinking parameter with top-level reasoning_effort. The K2-era thinking object is not a K3 parameter and will error.
3. Strip sampling parameters. Remove temperature, top_p, and penalty settings from K3 requests — they are fixed server-side and any other value rejects.
4. Set effort deliberately. The default is max, the most expensive rung, and reasoning tokens bill as output. Drop to high or low where the task does not earn the deliberation — and do not switch rungs mid-conversation, because it invalidates your prefix cache.
5. Re-audit cost models. Output tokens cost 3.75x the K2.6 rate at list price, and always-on reasoning inflates output counts. Claw back spend by structuring prompts for the automatic cache: stable prefix first, variable suffix last.
6. Rework vision ingestion if you passed public image URLs — K3 accepts only base64 or uploaded file references^[5].
7. Echo assistant messages back complete, including reasoning_content and tool_calls, in every multi-turn loop.

Who should use K3 today

Based strictly on what is confirmed, K3 makes sense right now for long-horizon work where per-task quality dominates per-token cost: multi-hour coding agents navigating large repositories, million-token document corpora queried repeatedly against a cached prefix, and multimodal reasoning jobs that need images, video, and code in one context.

It is the wrong choice today for latency-sensitive interactive products (28 tokens/sec is a different tool for a different job), for pipelines that need tunable sampling (everything is locked), and for pure cost-optimization plays — that is what the cheaper tiers are for.

Running Kimi K3 through reAPI

K3 is live on the reAPI gateway as a drop-in OpenAI-compatible endpoint: swap the base URL to https://api.reapi.ai/v1, send your gateway key as a bearer token, and set the model string to kimi-k3. The same openai SDK you already use works unchanged.

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      { "role": "user", "content": "Refactor this module and add tests." }
    ],
    "reasoning_effort": "high",
    "stream": true
  }'

Two reasons to route K3 through reAPI rather than direct:

• Price. reAPI bills K3 at $2.50 input / $12.00 output per 1M tokens — below Moonshot's published rate on both dimensions, a full fifth lower on output^[8]. On a model whose always-on reasoning inflates output counts, the output rate is the number that matters.
• One key, many models. The same gateway key reaches Claude, GPT, Gemini, DeepSeek, GLM, and the Kimi line, which makes K3 a routing decision rather than a vendor commitment — put it behind the same fallback and load-balancing logic as everything else.

The full request surface — the fixed parameters, the caching conditions, the vision part format, the error catalog — is documented in our Kimi K3 API docs, and current rates are on the model page.

FAQ

Is Kimi K3 open source?

Moonshot describes K3 as an open-source release and has committed to publishing weights, which would make it the first open model in the 3-trillion-parameter class^[3]. As of this writing the weights drop is imminent but the primary access path remains the API.

Can I turn off or reduce K3's reasoning?

You cannot turn it off — reasoning is always on. You can reduce it: reasoning_effort accepts low, high, and max, with max as the default^[4]. low exists precisely for the case where the reasoning is costing more than the answer is worth.

Does the 1M context cost extra?

No. Pricing is flat per token regardless of context length — a 900K-token prompt bills at the same rate as a 9K one^[2]. On Moonshot direct, cache-hit input drops to $0.30 per 1M tokens.

Why did my K3 request return an error about temperature?

temperature, top_p, n, and both penalty parameters are fixed server-side, and sending any other value is an error rather than an override^[1]. Delete them from the request. The same applies to the K2-era thinking object — use top-level reasoning_effort instead.

Can I use K3 in Claude Code, Codex, or Cline?

Yes — the API is OpenAI-compatible, so any tool that accepts a custom base URL and key can drive it, including Claude Code, Codex, Cline, RooCode, and OpenCode. Point the tool at https://api.reapi.ai/v1 with a gateway key and the model id kimi-k3.

How does K3 compare to Claude Opus 4.8 or GPT-5.5 on benchmarks?

Moonshot has published no official evaluation table for K3 as of this writing — no SWE-Bench, no Terminal-Bench, nothing independently verifiable. Treat specific numbers circulating on social media as unverified until the benchmark table and the technical report land.

References

1. Moonshot AI. Kimi K3 Quickstart — official API documentation: model ID, fixed sampling parameters, output ceilings, tool calling, context caching. Retrieved July 2026 from platform.kimi.ai/docs/guide/kimi-k3-quickstart
2. Moonshot AI. Kimi K3 pricing — $3.00 / $15.00 per 1M tokens, $0.30 cache-hit input, no context tiering. Retrieved July 2026 from platform.kimi.ai/docs/pricing/chat-k3
3. Moonshot AI. Models overview — 2.8T parameters, Kimi Delta Attention + Attention Residuals, Stable LatentMoE (16 of 896 experts), open-source commitment. Retrieved July 2026 from platform.kimi.ai/docs/api/models-overview
4. Moonshot AI. Using reasoning_effort — three rungs (low / high / max), default max, cache invalidation on switching. Retrieved July 2026 from platform.kimi.ai/docs/guide/use-reasoning-effort
5. Moonshot AI. Using Kimi vision models — image and video input, base64 and file references, no public URLs. Retrieved July 2026 from platform.kimi.ai/docs/guide/use-kimi-vision-model
6. Moonshot AI. Kimi Linear: An Expressive, Efficient Attention Architecture (arXiv:2510.26692) — KDA, 3:1 hybrid layout, KV-cache and decoding results. Retrieved July 2026 from arxiv.org/abs/2510.26692
7. OpenRouter. MoonshotAI: Kimi K3 — live telemetry: cache hit rate, weighted input price, throughput and TTFT. Retrieved July 2026 from openrouter.ai/moonshotai/kimi-k3
8. reAPI. Kimi K3 — model page, API documentation, and current rates. Retrieved July 2026 from reapi.ai/docs/kimi-k3

Further reading

• reAPI. Kimi K3 API Documentation. reapi.ai/docs/kimi-k3
• reAPI. Kimi K3 Model Page — current pricing. reapi.ai/models/kimi-k3
• reAPI. What Is Claude Opus 4.8? Anthropic's New Model Explained. reapi.ai/blog/what-is-claude-opus-4-8
• reAPI. What Is reAPI? reapi.ai/blog/what-is-reapi