How to Use Kimi K3: Complete Guide to Moonshot AI's 2.8T-Parameter Flagship Model

On July 16, 2026, Moonshot AI flipped the switch on Kimi K3 — and did it in the quietest way imaginable for a 2.8-trillion-parameter flagship. There was no benchmark chart, no launch blog, no Hugging Face drop. Instead, a banner appeared at the top of the Kimi API Platform docs: "🎉 Kimi K3 has launched!" — followed by a full quickstart guide, a pricing page, and a live kimi-k3 model ID on the OpenAI-compatible API.

That rollout order matters, because most of what has circulated about K3 over the past week has been leak and speculation. This guide separates the two. Everything in the sections below is sourced from Moonshot's own API documentation, the live OpenRouter listing, and the published research behind the architecture — and we flag, explicitly, what Moonshot has not yet published, including the official benchmark table. If you followed our Kimi K2.6 coverage in April, treat this as the next chapter: same lab, same open-weight lineage, but a very different pricing posture and a genuinely new attention architecture.

Kimi K3 at a Glance

Here is what Moonshot's documentation confirms as of July 17, 2026:

Two things jump out immediately. First, the parameter count: 2.8T is nearly triple the 1T of Kimi K2.6 and K2.7-Code, and it lands inside the "2 to 3 trillion" range that the Financial Times reported (via TechCrunch) would make K3 the largest open-weight model released by a Chinese lab. Second, the pricing: this is not another ultra-cheap Kimi release. At $3.00 input / $15.00 output, K3 costs roughly three to four times what K2.6 does. Moonshot is pricing this as a frontier flagship, not a value play — while still undercutting Claude Opus 4.8 ($5 / $25) and GPT-5.5 ($5 / $30) on both sides of the ledger.

The Launch Timeline: Teaser, Leaks, Then Docs

The K3 rollout was unusual enough to be worth reconstructing, because it explains why so much conflicting information is circulating.

July 14–15: Community trackers reported a K3 promo page briefly appearing on Moonshot's Open Platform before vanishing, along with beta model selectors surfacing in the Kimi app and CLI. Reddit and X leak threads settled on a consensus rumor: a ~2.5T-parameter Mixture-of-Experts model with a 1M-token context window. (Close, as it turned out, but the official figure is 2.8T.)

July 15, 22:33 UTC: Moonshot's official X account posted a wordless video teaser — no specs, no date, just visual "3" motifs. It drew hundreds of thousands of views in hours.

July 16: The Financial Times reported that K3 would launch "in the coming days" with 2–3 trillion parameters, and that Moonshot was simultaneously raising at a $31.5 billion valuation — up from $20 billion just two months earlier. The report was outpaced by the product: the same day, the API platform docs went live with the launch banner, the kimi-k3 quickstart, and the pricing page, and OpenRouter listed the model with a July 16 release date.

July 17 (as of publication): Moonshot's homepage still headlines K2.6. There is no K3 entry on the Kimi tech blog, no Kimi-K3 repository on GitHub, and no model card on Hugging Face. The API shipped first; the paper trail is still catching up.

That sequencing — API and docs before benchmarks and weights — is the reverse of how Moonshot launched K2.6, which arrived with a full tech blog and open weights on day one. It reads like a launch pulled forward, possibly to land inside the fundraising news cycle.

Architecture: Kimi Delta Attention and Attention Residuals

The single most technically interesting line in the K3 documentation is this one: K3 is "built on Kimi Delta Attention, a hybrid linear attention mechanism, and Attention Residuals."

This is not marketing vocabulary — it is a direct production deployment of the Kimi Linear research line Moonshot published in late 2025 (arXiv 2510.26692, with code and 48B research checkpoints on GitHub). Understanding it explains both the 1M-token context window and the flat pricing that makes it usable.

Kimi Delta Attention (KDA) is a linear attention mechanism — a refinement of Gated DeltaNet with finer-grained gating that manages the model's finite recurrent memory more efficiently. Unlike standard softmax attention, whose key-value cache grows linearly with sequence length and eats GPU memory alive at long contexts, linear attention maintains a fixed-size state. The cost has traditionally been quality: pure linear attention models lose precise recall over long documents.

The hybrid layout is how Kimi Linear 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 layer retains exact global attention. In the published paper, this configuration outperformed full attention on quality benchmarks while cutting KV-cache memory by up to 75% and delivering up to 6x faster decoding at 1M-token context lengths.

Attention Residuals is the one component with no published paper behind it yet — the term first appears in the K3 docs themselves. Until Moonshot publishes a K3 technical report, the honest position is that we know the name and not the mechanism.

Why does this matter practically? Because a 1M-token context window is only as good as its economics and latency. Most providers that offer very long contexts either tier the pricing upward past a threshold or quietly degrade. K3's docs state there is no tiering by context length — the same $3 / $15 applies whether you send 5,000 tokens or 900,000. That pricing decision is only rational if the marginal cost of long contexts really has collapsed, which is exactly what the KDA architecture is for. The architecture is the pricing story.

One caveat worth stating plainly: Moonshot has not disclosed K3's active parameter count, expert count, or routing configuration. K2.6 activated roughly 32B of its 1T parameters per token; if K3 follows a similar sparsity ratio it would activate somewhere near 80–90B, but that is inference on our part, not a published number.

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 all documented constraints, not observations:

• Reasoning is always on. There is no non-thinking mode. K3 introduces a top-level reasoning_effort parameter (replacing the K2.x thinking parameter), and it currently accepts exactly one value: max. Moonshot says more levels are coming. Until then, every K3 call pays the full deliberation cost — you cannot dial it down for easy tasks.
• Sampling is fixed. temperature is locked at 1.0, top_p at 0.95, n at 1, and both penalty parameters at 0. 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 — meaning a single K3 call can, in principle, emit a million tokens of output. Long-form generation workloads (full codebases, book-length drafts, multi-file refactors) are clearly a design target.
• Streaming separates reasoning from answers. Streamed responses carry reasoning_content deltas distinct from final content deltas, so UIs can render the thinking trace separately.
• Vision has sharp edges. Image and video input are native, but public image URLs are not supported — you must send base64 data or upload files and reference them by ms:// file ID. Images are capped at 4K resolution, video at 1080p.
• Structured output is first-class. JSON Schema with strict: true constrains the final message content, and Partial Mode lets you force continuation from a text prefix.

The New Tool-Calling Stack

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

Tool choice constraints (tool_choice) let you require at least one tool call on a turn — useful for forcing an agent to ground itself in retrieval or execution rather than free-associating.

Dynamic tool loading is the more novel one: you can place complete tool definitions inside system messages mid-conversation, and the tool becomes available from that point onward. Instead of front-loading 80 tool schemas into every request, an orchestrator can inject tools exactly when a workflow phase needs them. Moonshot pairs this with a dedicated tool-calling best-practices guide about combining dynamic loading, tool_choice, and reasoning effort to control token spend.

One warning from the docs worth repeating: Moonshot's built-in web_search tool is "currently being updated" and explicitly 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 automatically attempts a cache hit, billed at $0.30 per 1M tokens instead of $3.00. 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 system prefix, then iterate against it: every follow-up request re-reads the corpus at one-tenth the price.

Early production data suggests this works as advertised: OpenRouter's live telemetry for K3 already shows a 77.7% cache hit rate across traffic, with a weighted average input price of $0.903 per 1M tokens — well under a third of the list price.

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 (all prices per 1M tokens; input prices are cache-miss rates):

The positioning is legible at a glance: K3 costs 3–4x its own siblings and 40–50% less than the closed frontier. Against DeepSeek V4 — the reigning open-weight value champion — K3 is substantially more expensive per token, and DeepSeek's cache-hit input is even cheaper. Moonshot is betting that a 1M-token window, native vision, and (presumably) frontier-class capability justify a premium tier within the open-weight world.

Speed is the honest asterisk on that bet. OpenRouter's early telemetry shows K3 producing about 28 tokens per second with ~4-second time-to-first-token — unsurprising for an always-on-max reasoning model at this scale, but slow. For latency-sensitive coding loops, Moonshot's own kimi-k2.7-code-highspeed (180–260 tokens/sec at $1.90 / $8.00) remains the speed play. K3 is built for depth-per-call, not calls-per-minute.

Two housekeeping notes from the launch. Moonshot is running a top-up rebate through the launch window — up to 30% back in vouchers on API credit purchases. And the model lineup is being pruned aggressively: kimi-k2.5 and the entire legacy moonshot-v1 series are closed to new users, with a full platform sunset on August 31, 2026. The K2 series proper was already discontinued in May. Moonshot wants everyone on K2.6, K2.7-Code, or K3.

What Moonshot Hasn't Published Yet

This is the section most launch-day coverage skips, and it is the most important one for anyone deciding whether to route production traffic today.

No official benchmarks. As of July 17, Moonshot has published no evaluation table for K3 — nothing on SWE-Bench, Terminal-Bench, HLE, or its own internal Kimi Code Bench. The only performance claim in the docs is the phrase "industry-leading intelligence." The FT's sources framed K3 as targeting parity with Claude Opus 4.8, and leak threads circulated impressive-sounding numbers, but none of it is verifiable. For reference, the lab's track record is real — K2.6 posted a genuinely leading 58.6% on SWE-Bench Pro at launch — but track record is not a benchmark table. We will update this guide when official numbers land.

No weights. The Hugging Face moonshotai org has no Kimi-K3 repository yet. Every prior flagship in this lineage (K2, K2.5, K2.6, K2.7-Code) shipped open weights, OpenRouter's listing describes K3 as "open-weight," and the FT reporting assumes it — but as of today, K3 is accessible only through APIs and Moonshot's own products. If open weights are a hard requirement for you, K3 is not yet that; K2.6 and GLM-5.2 are.

No technical report. The 2.8T parameter figure, the KDA claim, and "Attention Residuals" all come from documentation prose. There is no paper describing K3's MoE configuration, training data scale, RL recipe, or how the Kimi Linear architecture was scaled 58x from its 48B research checkpoint.

No arena signal yet. K3 appeared too recently to have meaningful LMArena or leaderboard placement. Community leak threads referenced beta appearances in arena selectors, but there is no public ranking to cite. Early third-party evals in the K2.7 era showed Moonshot models placing near the very top of independent tests, so the arena results will be worth watching over the next two weeks.

None of this means K3 is weak — it means the burden of proof is currently on Moonshot, and prudent teams should treat capability claims as pending until the benchmark table and weights arrive.

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 at api.moonshot.ai/v1.
2. Replace the thinking parameter with top-level reasoning_effort: "max" (or omit it; max is the default and only level).
3. Strip sampling parameters. Remove temperature, top_p, and penalty settings from K3 requests — they are fixed server-side.
4. Re-audit cost models. Output tokens now cost 3.75x K2.6's rate, and always-on max reasoning inflates output token counts. Budget accordingly, then claw back spend by structuring prompts for the automatic cache (stable prefix, variable suffix).
5. Rework vision ingestion if you passed public image URLs — K3 accepts only base64 or ms:// file references.
6. Keep K2.7-code-highspeed in the router for latency-sensitive paths. K3's 28 tokens/sec is a different tool for a different job.
7. Return complete assistant messages (including reasoning fields) in multi-turn and tool-call loops — the docs are emphatic that trimming to content alone breaks things.

Who Should Use K3 Today

Based strictly on what is confirmed: K3 makes sense right now for long-horizon agentic 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. Moonshot's own integration docs target exactly this surface, with day-one setup guides for Kimi Code, Claude Code, Codex, Cline, RooCode, OpenCode, OpenClaw, and Hermes Agent.

It is the wrong choice today for latency-sensitive interactive products (28 tok/s), for teams that need tunable sampling or lightweight reasoning modes (everything is locked to max), for pipelines requiring open weights (not yet published), and for pure cost-optimization plays (that is what K2.6 and DeepSeek V4 are for).

What Kimi K3 Means for AI Slide Generation

Every frontier model release eventually collides with the same question we care about at Tosea.ai: does this change how source documents become finished decks? K3's spec sheet is unusually relevant to AI slide generation, for three concrete reasons.

The 1M-token window collapses the multi-document outline problem. Real presentation work rarely starts from one clean file — it starts from a 200-page annual report, three research PDFs, and a folder of meeting notes. Most document-to-PPT workflows handle this by chunking and summarizing before outlining, which is where nuance dies. A 1M-token context holds the entire corpus natively, and K3's automatic caching makes iterating on that corpus economical: load it once as a stable prefix, then regenerate slide structures at the $0.30 cache-hit rate. That is the pattern we explored for massive slide decks from long documents, now viable at 4x the previous context ceiling.

Agentic coding strength translates directly to deck markup quality. Modern AI presentation tools render slides as HTML/CSS before export, so a model that writes cleaner front-end code produces measurably better slide structure — alignment, hierarchy, responsive layout. The Kimi line has been strong here since K2.6's long-horizon coding results, and K3 is positioned as the successor for exactly those workloads. The same skills that let it refactor a repository let it maintain a consistent design system across a 40-slide deck.

Vision input closes the loop. Because K3 reads images natively, a slide-generation pipeline can render a draft slide, feed the screenshot back, and let the model critique its own layout — the self-correction pattern that separates production pipelines from demos.

The distinction that remains: a raw model is not a presentation workflow. Getting from a PDF corpus to an investor-ready deck still requires parsing, layout systems, template governance, and export to editable formats — the orchestration layer that PDF-to-PowerPoint tools like Tosea.ai provide on top of whichever frontier model wins the quarter. For research-heavy decks specifically, our research-paper-to-slides workflow shows what that pipeline looks like end to end. K3 slots into that stack as an engine upgrade: bigger context in, better markup out, same workflow around it.

FAQ

Is Kimi K3 open source? Not yet. Every prior Kimi flagship shipped open weights, and both OpenRouter and press reporting describe K3 as open-weight, but no weights or model card have been published as of July 17, 2026. Watch the moonshotai Hugging Face org.

Can I turn off or reduce K3's reasoning? No. Thinking is always on, and reasoning_effort currently accepts only max. Moonshot says additional levels are coming. If you need cheap fast calls, route them to K2.6 or K2.7-code-highspeed.

Does the 1M context cost extra? No — pricing is flat at $3.00 input / $15.00 output per 1M tokens regardless of context length, with cache-hit input at $0.30. There is no long-context surcharge tier.

How does K3 compare to Claude Opus 4.8 or GPT-5.5 on benchmarks? Nobody outside Moonshot knows yet. The FT reported K3 targets parity with Opus 4.8, but no official or independent benchmark results have been published. Treat any specific numbers circulating on social media as unverified.

Can I use K3 in Claude Code, Codex, or Cline? Yes — the API is OpenAI-compatible, and Moonshot ships official integration guides for Claude Code, Codex, Cline, RooCode, OpenCode, OpenClaw, Hermes Agent, and its own Kimi Code CLI.

Sources

• Kimi K3 Quickstart — official API documentation — Moonshot AI, July 16, 2026
• Flagship Model Kimi K3 Pricing — Moonshot AI
• Model List — Kimi API Platform — Moonshot AI
• MoonshotAI: Kimi K3 — API pricing and providers — OpenRouter
• Moonshot's upcoming Kimi 3 is expected to close the gap with Anthropic's flagship — TechCrunch, July 16, 2026
• Kimi K3 video teaser — @Kimi_Moonshot on X, July 15, 2026
• Kimi Linear: An Expressive, Efficient Attention Architecture — Moonshot AI, arXiv 2510.26692
• Kimi-Linear repository and research checkpoints — MoonshotAI on GitHub
• Kimi K2.6: Advancing Open-Source Coding — Moonshot AI tech blog, April 20, 2026