Kimi K3: Moonshot's 2.8T Flagship, Open Weights, 1M Context

TL;DR

Kimi K3 is Moonshot AI's open-weight flagship model: 2.8 trillion total parameters with 104 billion active per token, a 1-million-token context window, and native vision. It launched July 16, 2026, and the weights shipped July 27 on Hugging Face under the Kimi K3 License. The API costs $3 per million input tokens and $15 per million output, flat at any context length.

Published launch day, July 16, 2026; last updated September 7, 2026 with the provider-selection table (measured speed against Vendor Verifier conformance and the two hosts serving reduced context), a local-deployment section with the community quant sizes and hardware floors, the harness bugs that drop reasoning_content, the fixed-sampling rule, and the subscription-capacity pause.

Kimi K3 is Moonshot AI's flagship mixture-of-experts model, launched July 16, 2026. It has 2.8 trillion total parameters, 104 billion active per token, a 1M-token context window, native visual understanding, and a new architecture: Kimi Delta Attention (hybrid linear attention) plus Attention Residuals. Moonshot reports 81.2 on FrontierSWE and 88.3 on Terminal-Bench 2.1, and 1686 Elo on GDPval-AA v2 against Claude Fable 5's 1747 and Claude Opus 4.8's 1593. The weights shipped July 27 under the Kimi K3 License as a native MXFP4 checkpoint.

Kimi K3 at a Glance

Every row below comes from the Hugging Face model card, the checkpoint config, or Moonshot's platform pricing page, as of September 7, 2026.

What Is Kimi K3?

Kimi K3 is the successor to Moonshot AI's K2 line (K2.6 shipped April 2026 at 1T total / 32B active parameters; K2.7 Code followed in June and reached general availability inside GitHub Copilot). K3 nearly triples the total parameter count to 2.8T and more than triples active parameters to 104B, extends context from 200K to 1M tokens, and adds native visual understanding for images and video. Thinking is always enabled, with reasoning traces exposed as separate deltas in the streaming API.

The launch was API-first: kimi-k3 on Moonshot's OpenAI-compatible platform, with the consumer Kimi app exposing two tiers, K3 Max and K3 Cluster Max. The weights followed eleven days later, on July 27. Moonshot is reportedly raising at a $31.5 billion valuation on the back of the release, up from $20 billion in May 2026, and is consolidating its platform around K3: the older kimi-k2.5 and moonshot-v1 model series were closed to new users and sunset on August 31, 2026.

Before the official launch, a beta checkpoint codenamed "Kivine" ran anonymized on LM Arena, where early testers flagged two traits that carried into release coverage: elaborate, visually rich generations (interactive 3D scenes were a repeated example) and long runtimes on hard agent tasks.

Confirmed vs Leak Noise

K3 leaked for two days before it shipped, so early coverage mixed first-party facts with estimates. The weights release and six weeks of documentation updates have resolved nearly all of it. The split as of September 7:

Architecture: Kimi Delta Attention at 1M Context

K3 is the first Moonshot flagship built on Kimi Delta Attention (KDA), the hybrid linear attention mechanism from the Kimi Linear paper (arXiv 2510.26692, October 2025). The shipped model stacks 69 KDA linear-attention layers with 24 Gated MLA full-attention layers across 93 layers, roughly the paper's 3:1 interleave: linear layers handle local sequence structure cheaply, full-attention layers preserve global information flow. At matched scale in the paper, this cut KV-cache memory by up to 75% and delivered up to 6x decoding throughput at 1M-token context while matching or beating full-attention baselines on short-context, long-context, and RL-style post-training tasks. K3 pairs KDA with what Moonshot calls Attention Residuals.

The architecture is why the pricing is flat. Serving a 1M-token context with full attention means the KV cache, not the weights, dominates memory at long sequence length, which is why several competitors charge a long-context premium. Cut the cache 75% and the premium disappears from the cost structure. Whether serving economics at 2.8T actually work at $15/M output is Moonshot's bet.

The MoE side is where the scale lives. The model card describes a "Stable LatentMoE" design that routes each token to 16 of 896 experts plus 2 shared experts, for 104B active parameters out of 2.8T, and claims roughly 2.5x the scaling efficiency of K2. Hidden size is 7,168 with 96 attention heads, the vocabulary is 160K, and vision comes from a 401M-parameter MoonViT-V2 encoder. The checkpoint is natively MXFP4 quantization-aware trained from the SFT stage onward (MXFP4 weights, MXFP8 activations), so the shipped artifact is already a quantized model, not a BF16 model someone quantized afterward. Which precision path a provider serves is a real fidelity question; Moonshot ships a public conformance harness, Kimi-Vendor-Verifier, for exactly this.

Benchmarks: Vendor Table, Then Independent Signal

The K3 column below is Moonshot-reported from the Hugging Face model card, at max reasoning effort and temperature 1.0. Competitor columns are the model card's own citations: Anthropic, OpenAI, Z.ai, and Artificial Analysis as of July 23, 2026. Launch-day skepticism on Hacker News centered on vendor-reported scores from open-weight-lineage models; treat the table as the vendor's framing and read the independent section after it.

Two footnotes from the model card change how to read the headline rows. The BrowseComp 91.2 uses a context-compaction strategy triggered at 300K tokens; with the full 1M window and no context management the score is 90.4, so the "single agent, no compression" framing from launch coverage is off by 0.8 points but directionally right. And the DeepSWE 67.5 is with the Kimi Code harness; the official DeepSWE leaderboard scores K3 at 67.3 with mini-SWE-agent. Competitor harnesses differ per row (Terminus 2 for Claude, Codex for GPT), so deltas of a few points are harness noise.

Independent signal, six weeks in

Independent testing settled about where day-one skeptics predicted: strong, one tier below the closed frontier. Artificial Analysis scores K3 44 on Intelligence Index v4.3 at max effort, checked September 7, 2026, just behind GLM-5.3's 45 for the open-lineage lead and above GLM-5.2 (39) and DeepSeek V4 Flash (35). Running that index cost 160M output tokens, which is the always-on-thinking bill in one number. On Together AI's DeepSWE head-to-head, Fable 5 wins pass@1 69.9 to 68.5 while K3 leads at pass@2 and pass@4; the full breakdown is on Kimi K3 vs Claude Fable 5. Developers consistently praise one thing the closed frontier does not offer: fully exposed reasoning traces, which one Hacker News commenter called "far, far more informative" than Fable's opaque summaries for debugging agent behavior.

Throughput: What Kimi K3 Actually Runs At

A 2.8T model with 104B active parameters is bounded by memory bandwidth per token and by how much KV state each request drags along. The numbers below are the public measurements that exist as of September 7, 2026, with the workload and hardware each one assumes. They do not agree with each other, and they should not: per-user speed and per-GPU throughput trade against each other on every serving stack.

InferenceX on B300 (SemiAnalysis, measured)

InferenceX runs the AgentX agentic-coding trace, a long-context multi-turn workload, against vLLM in FP4 on NVIDIA B300 and sweeps concurrency. The interactivity target is what you promise each user; throughput per GPU is what you get to sell. Peak measured throughput across all configurations was 12,566 tokens per second per GPU.

Source: InferenceX, Kimi K3 on B300. Read the 100 tok/s row as the interactive-agent operating point: 4,051 tok/s per GPU is about 40 concurrent users per GPU at that speed. Halving the per-user target to 50 tok/s buys 1.5x the throughput; pushing to 200 tok/s costs half of it.

SGLang day-zero numbers (LMSYS, July 27, 2026)

SGLang's bring-up post reports about 113 tok/s at batch 1 before speculative decoding, and about 423 tok/s at batch 1 with DSpark, a draft model the team trained for K3, with a "ReplaySSM" trick that replays raw inputs into the KDA state instead of snapshotting it (roughly a 32x cut in draft-window memory). At the throughput end, one PP8 prefill worker feeding one TP8 decode node under prefill-decode disaggregation delivers 2,808 tok/s per GPU on the FP4 arm. The prefill and decode measurements were taken on 2x4 GB300. See speculative decoding for why the batch-1 gain shrinks as concurrency rises.

Hosted providers (Artificial Analysis, live)

The same weights land anywhere from 42 to 251 output tokens per second depending on who serves them. Artificial Analysis currently tracks 13 hosts. That is a 6x spread on identical weights, and per-provider time to first token ranges from 0.80 to 8.90 seconds, which matters more than peak speed for agent loops. The full table, cross-referenced against Moonshot's own conformance leaderboard, is in the next section.

Kimi K3 on Morph

Morph serves morph-kimik3 on GB300 NVL72 racks. The Morph Models page describes the same coding job on two stacks: baseline serving grinds line by line while Kimi K3 on Morph snaps every edit in and settles at 100 tok/s. A latency-tuned SKU, morph-kimik3-fast, runs identical weights with prefill/decode disaggregation tuned for lower per-request latency. For a private endpoint sized to your own concurrency and speed target, use the dedicated inference calculator or the planner at the bottom of this page; the dedicated inference benchmarks page and LLM inference guide cover the serving-stack tradeoffs in general.

Which Provider Should You Use?

"Best API provider for Kimi K3" has no single answer, because the two public scoreboards measure different things and disagree about who wins. Artificial Analysis measures speed. Moonshot's own Kimi-Vendor-Verifier measures whether a host reproduces the reference model's answers. Ranking a host on one tells you nothing about the other.

Speed, time to first token, and served context are from Artificial Analysis (read September 7, 2026). Conformance scores are from the Kimi-Vendor-Verifier leaderboard, which only lists hosts that submitted. Morph is not on either leaderboard; morph-kimik3 runs on GB300 NVL72 racks at $2.50/M input, $0.29/M cached, and $14.00/M output with the full 1,048,576-token window.

Three things fall out of putting the two tables side by side. Modal is the fastest generally available host at 151 tok/s and posts the lowest DeepSWE score on the verifier, 0.658, below Moonshot's own 0.675. Nebius runs 121 tok/s and posts the lowest BEAM long-context score of any submitted host, 0.2913 against Moonshot's 0.31. Baseten is a third slower than Modal and scores the highest DeepSWE of the commercial hosts at 0.693, within noise of the vLLM reference implementation's 0.695. Speed and fidelity are not correlated across this set, so pick on both, and prefer a host that submitted results at all.

A third disagreement is worth knowing about before you trust any single number. OpenRouter publishes its own rolling throughput and uptime per provider, measured on whatever traffic actually routed through it over the last three days, and its figures diverge from Artificial Analysis by several times for the same host, because a provider with little OpenRouter traffic is being sampled from a handful of requests. Uptime is the column OpenRouter is uniquely good for: it currently shows Parasail at 89.85% and Makora at 92.74% against 99.9%-class numbers for Modal, Fireworks, Together, and Moonshot. Treat speed tables as directional and run your own measurement against your own prompt shape before committing volume.

The Token Economics: Always-On Thinking at $15/M

K3's pricing reads mid-tier until you account for how it generates. Thinking mode cannot be disabled. reasoning_effort now accepts low, high, and max (launch docs listed only max), and the default is still max, so every request that does not set it pays for a full reasoning trace at $15/M output tokens. This is the same failure mode that makes cheap-per-token models expensive per task: GLM-5.3 burns tens of thousands of output tokens per Artificial Analysis task at max effort, and K3 defaults to max.

Day-one Hacker News math framed it directly: $3/$15 with $0.30 cache hits matches Anthropic's Sonnet-series pricing, which is expensive for a model from the open-weight lineage, and commenters noted GLM-5.2 delivers similar coding quality at roughly one-third the per-token price. The counterpoint from K3's defenders: if the GDPval-AA positioning holds under independent testing, Sonnet-tier pricing for near-Fable capability is underpriced, not overpriced. Both can be true; which one matters depends on whether your workload needs the top tier.

The flat 1M-context pricing is a genuine differentiator. Anthropic charges a premium above 200K input tokens and Google tiers Gemini pricing by context length; Moonshot charges $3/M whether you send 4K or 900K tokens. For long-context-heavy workloads (repo-scale analysis, long agent traces, document piles) that flatness changes the calculus more than the headline rate does.

Is Kimi K3 Free?

Not through the API. Moonshot's platform is prepaid: a top-up is required before you can call kimi-k3, the minimum is $1, and the quickstart is explicit that "your cumulative top-up amount also determines your account tier and rate limits (concurrency, RPM, TPM, TPD)." There are no trial credits and no free tier on the API. Every hosted provider in the table above charges too, and OpenRouter carries no free K3 route, unlike the free variants it offers for some smaller open models.

The consumer Kimi app is the free path, and it has been supply-constrained since launch week. Moonshot paused new paid subscriptions on July 19, 2026, three days after the K3 launch, saying on X that demand had "pushed close to the limits" of its systems within 48 hours. Existing subscribers kept their access; new capacity was promised "in batches" with no date. This is the part of the K3 story most spec pages skip: the constraint on a 2.8T model is not the weights, it is who has enough accelerators to serve it, which is also why a model with open weights still has a queue in front of it.

Free in the sense of no license fee, yes. The weights are downloadable and the Kimi K3 License permits internal use with no payment and no revenue threshold. What you pay instead is hardware: see the local-deployment section below, where the smallest usable community quantization needs roughly 610 GB of combined RAM and VRAM.

Kimi K3 API: Pricing and How to Call It

Morph serves Kimi K3 on GB300 NVL72 racks as morph-kimik3, on the same OpenAI-compatible API as the rest of the open-model lineup, at $2.50/M input, $0.29/M cached, and $14.00/M output, under Moonshot list pricing on every leg:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.morphllm.com/v1",
    api_key="YOUR_MORPH_API_KEY",
)

resp = client.chat.completions.create(
    model="morph-kimik3",
    reasoning_effort="high",  # low | high | max (default max)
    messages=[
        {"role": "user", "content": "Trace this race condition and propose a fix."},
    ],
)
print(resp.choices[0].message.content)

Moonshot's first-party API is OpenAI-compatible too: base URL https://api.moonshot.ai/v1, model kimi-k3. It supports streaming with separate reasoning and content deltas, structured JSON output with strict schema enforcement, tool calling with dynamic loading, vision inputs (base64 or uploaded file IDs), and a partial mode for prefix continuation. max_completion_tokens defaults to 131,072 and goes to 1,048,576. The examples below use the Morph endpoint; swap the base URL and model name for Moonshot's and they run unchanged.

Streaming: reasoning deltas arrive before content deltas

Moonshot's docs: "Streaming responses provide separate reasoning_content and final-answer content deltas." The reasoning field is non-standard, so read it with getattr rather than assuming the SDK types know about it:

stream = client.chat.completions.create(
    model="morph-kimik3",
    messages=[{"role": "user", "content": "Explain why the sky is blue."}],
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta
    reasoning = getattr(delta, "reasoning_content", None)
    if reasoning:
        print(reasoning, end="", flush=True)   # thinking trace
    if delta.content:
        print(delta.content, end="", flush=True)  # final answer

Multi-turn: send the whole assistant message back

The rule from the K3 quickstart, verbatim: "For multi-turn conversations and tool calls, add the complete assistant message returned by the API to the next request. Do not keep only content." The simplest correct pattern appends the message object itself, which carries reasoning_content and any tool_calls along with it:

messages = [{"role": "user", "content": "Find the bug in this function: ..."}]

first = client.chat.completions.create(model="morph-kimik3", messages=messages)
assistant = first.choices[0].message

# Append the complete assistant message (content + reasoning_content + tool_calls).
# Do NOT rebuild it as {"role": "assistant", "content": assistant.content}.
messages.append(assistant)
messages.append({"role": "user", "content": "Now write the failing test for it."})

second = client.chat.completions.create(model="morph-kimik3", messages=messages)
print(second.choices[0].message.content)

Replayed reasoning_content counts toward prompt tokens, which Moonshot's thinking-model docs state plainly ("historical thinking content keeps occupying the context window and is billed accordingly"). That is what the cached-input rate is for. On Morph, prompt caching is keyed by a per-conversation prompt_cache_key in the request body (or the same id in an x-session-id header), so every turn that replays the same prefix bills at $0.29/M instead of $2.50/M; see the caching docs. On Moonshot, caching is automatic once the previous request's prompt exceeds 256 tokens, as long as the prefix stays byte-identical.

Sources: Moonshot platform pricing (flat pay-as-you-go, no context-length tiering, unchanged since launch); OpenRouter model listing. Morph rates are read from the same pricing constants that bill the API. Since the weights opened, a dozen providers serve K3 with real spread in throughput and price (Artificial Analysis lists Makora at $2.55/$12.75, Bitdeer at $2.66/$13.30, DigitalOcean at $2.85/$14.25); check the live provider tables and the Vendor Verifier leaderboard before committing volume.

Sampling parameters are fixed: omit them

The quickstart states that temperature=1.0, top_p=0.95, n=1, presence_penalty=0, and frequency_penalty=0 are fixed, and tells you to omit them from requests. Most OpenAI-compatible harnesses send temperature: 0 by default for determinism, which is the wrong default here and is one of the misconfigurations the harness bugs below are built from. Unsloth's local recipe agrees on the API values and recommends top_p 1.0 rather than 0.95 for agentic runs.

The harness bugs that make K3 look bad

The replay rule is not a theoretical footnote. It is currently broken in shipping coding agents, in ways that are documented with numbers.

The clearest case is Zoo Code issue #1316 (opened August 21, 2026, still open), filed against K3 routed through OpenRouter. The reporter captured three separate defects in the outgoing request: no reasoning field at all, because the model parser only populates reasoning effort for Anthropic models and drops it for everything else; max_tokens: 209716, a number the client synthesized as 20% of the context window rather than reading the route's real cap; and temperature: 0 against a model that fixes temperature at 1.0. The symptom was turns that consumed the entire completion budget of 32,768 tokens and returned under 40 KB of visible text, with two logged turns running 507 seconds and 309 seconds. After the reporter's patch set a Moonshot capability profile with a correct token cap, a default reasoning_effort of high, and temperature 1.0, the worst turn went from 32,768 tokens in 507 seconds to 804 tokens in 6.7 seconds. Nothing about the model changed.

The same failure class shows up as dropped reasoning in tool-calling turns. OpenCode issues #23828 and #23831 describe assistant messages that carry tool_calls but no reasoning_content once they scroll behind the last user turn, which the API rejects on replay. OpenClaw issue #81988 is the mirror image: the client forwards a reasoning field the endpoint does not accept and gets "Extra inputs are not permitted" on turn two. There is enough of this across clients that a third-party plugin, opencode-thinking-fix, exists purely to cache reasoning text from responses and reinject it on later requests; its own writeup reports patching 34 fields across a single 104-message session.

The practical test before you conclude K3 is slow, expensive, or dumb in your agent: log one outgoing request body. Confirm reasoning_effort is present and set to what you intended, that temperature is absent, that max_tokens is a number you chose, and that the previous assistant message went back with its reasoning_content intact.

How to Run Kimi K3 Locally

You can, and the honest framing is that "locally" means a server, not a desktop. The shipped checkpoint is 2.8T parameters in native MXFP4, which is a multi-node deployment on datacenter accelerators. What made single-box experiments possible is Unsloth's dynamic GGUF requantization, which trades accuracy for a footprint you can hold in system RAM.

Source: Unsloth: Kimi K3, how to run locally. Their rule of thumb is that combined RAM plus VRAM should be at least the quant size; below that it still runs, just much slower because it is paging weights off disk.

What the sizes mean in practice

The floor is 610 GB of combined memory for the 1-bit build, which is a dual-socket server with a full DDR5 complement or an NVIDIA DGX Station, not a workstation. The 128 GB Apple Silicon machines that run 70B-class models comfortably do not hold any of these quantizations. A 594 GB file also has to be downloaded and stored before any of this starts, which is the answer to "how to download Kimi K3" for most people: the practical constraint is disk and bandwidth before it is compute.

Two gotchas from the same recipe. Not all community quantizations are equal: Unsloth reports a competing 618.9 GB conversion measuring 21x worse perplexity than its own similarly sized build, so the file name and size tell you almost nothing about quality. And K3 is thinking-only in this path, with preserved thinking always enabled and max effort on by default, so a local run inherits the same output-token behavior the API has; there is no instant mode to fall back to. Unsloth's fork of llama.cpp is what carries vision support.

If you have real GPUs: requantize instead

For datacenter hardware the better path is a GPU-native requantization rather than GGUF. VESSL AI published Kimi-K3-W4AFP8, an INT4-weight, FP8-activation conversion of the MXFP4 checkpoint at group size 128, served on 16 H200s across two nodes under SGLang with TP16 and EP16. Against the original MXFP4 checkpoint on the same hardware they measure output throughput up 17.9% (277.7 to 327.5 tok/s), median time to first token down 33.9% (0.924s to 0.611s), and per-token latency down 8.1% (23.21ms to 21.32ms), with six benchmarks landing within two standard errors of Moonshot's published figures. That is the realistic shape of a self-hosted K3: two nodes, sixteen accelerators, and a requantization step.

Both vLLM and SGLang shipped Kimi Delta Attention support at the weights release, so neither engine needs a patched build. Sizing a deployment against a concurrency and speed target is what the dedicated inference calculator is for; the throughput section above has the per-GPU numbers to plug into it.

Where Are the Weights?

Out since July 27, 2026. Moonshot released Kimi K3 on Hugging Face (moonshotai/Kimi-K3) under the Kimi K3 License, eleven days after the API launch, as a native MXFP4 checkpoint with an accompanying technical report. The K2-family precedent held on timing but not on license name: K2 shipped under "Modified MIT", K3 ships its own text. It grants MIT-style rights with two conditions. A Model-as-a-Service business with more than $20 million in revenue over any consecutive 12 months needs a separate agreement with Moonshot before commercial use, and any product with more than 100 million monthly active users or $20 million in monthly revenue must display "Kimi K3" in its UI. Internal use is exempt from both. vLLM and SGLang shipped day-zero support for the Kimi Delta Attention architecture, so the standard serving stacks ran it from week one.

Two details matter before you deploy it. First, the checkpoint is natively MXFP4 quantization-aware trained: MXFP4 weights with MXFP8 activations, so "the shipped checkpoint" is already a quantized artifact, and the community requants circulating on Hugging Face (NVFP4A16, W4AFP8, GGUF) are a second quantization on top. Second, the repo has had exactly three commits since release day: a community evaluation-results update the same day, an encoding_k3.py fix on August 20, and the Toolathlon-Verified score on September 1. The weight tensors themselves have not been revised, so a provider that pulled on July 27 serves the current weights. Moonshot publishes Kimi-Vendor-Verifier, a conformance harness that scores hosts on OCRBench, MMMU Pro Vision, BEAM (1M), and DeepSWE plus pre-flight checks on API parameters and tool-call schemas; its public leaderboard currently lists Moonshot, Fireworks, Baseten, Together, Inferact (the vLLM reference), Nebius, and Modal, with DeepSWE scores between 0.658 and 0.695.

The footprint is a different weight class than anything in the K2 line: even in native MXFP4 a 2.8T-total model is a multi-node deployment, and a hypothetical BF16 dequant would run roughly 5.6TB before KV cache. For comparison, GLM-5.3 at 753B is about 465 GB as an NVFP4 checkpoint and fits one 8-GPU node. Morph runs K3 on GB300 NVL72 racks; see the throughput section above.

Kimi K3 vs GLM-5.3 and DeepSeek V4 Flash

The relevant comparison set is the open-lineage frontier Morph serves today: GLM-5.3 (Z.ai's August 14 post-training upgrade of the 753B GLM-5.2 base; the official repo was gated at launch, a public ModelOpt NVFP4 checkpoint is what ships), DeepSeek V4 Flash (284B total / 13B active, MIT), and K3. GLM-5.2 is the same base as 5.3 and is covered on GLM-5.2 vs Kimi K3. The summary six weeks in: K3 posts the strongest agentic numbers of the set and ties GLM-5.3 on the independent index, at 3x to more than 20x the per-token price, with native vision as its unique capability.

Benchmark caveat: the Terminal-Bench row spans two versions. Moonshot and DeepSeek report 2.1; Z.ai reports GLM-5.3 on 3.0, a harder suite where GLM-5.2 scored 4.6, so the 28.3 is not comparable to the 88.3. Every score is self-reported by its vendor; the Artificial Analysis row is the one apples-to-apples number. What is not noise: the price gap. DeepSeek V4 Flash on Morph costs $0.1234375/M input and $0.3475/M output, about 2% of K3's output rate, and GLM-5.3 ties K3 on the independent index at under a third of K3's per-token price. K3's case rests on vision, the 1M flat window, and the agentic rows where it leads.

For the previous Moonshot generation, see Kimi K2.5 and agent swarms. For the models Morph serves on custom codegen kernels, see Morph Models: GLM-5.3, GLM-5.3-Flash, and DeepSeek V4 Flash.

Kimi K3: Pros and Cons

When to Use Kimi K3

Use K3 when the workload is long-horizon and context-heavy: single-agent research over large document sets (the BrowseComp setup), repo-scale analysis that genuinely needs several hundred thousand tokens in one window, or multimodal tasks where GLM-5.3 and DeepSeek V4 Flash are disqualified for lacking vision. The flat 1M pricing makes it the cheapest way to actually use a million tokens of context in one call, even though its per-token rate is the highest of the open lineage.

Skip it when the workload is high-volume codegen where per-task cost dominates. At $15/M output with max-effort reasoning by default, an agent loop that runs thousands of tasks a day costs an order of magnitude more on K3 than on DeepSeek V4 Flash or GLM-5.3-Flash, and GLM-5.3 matches it on the independent index for a third of the price. Set reasoning_effort to low or high before concluding K3 is too slow or too expensive; the default is max. Teams running open models at real volume should also weigh serving quality: the same weights land anywhere from 42 to 251 tok/s across hosts depending on quantization, speculative decoding setup, and caching, which is where Morph's codegen-tuned serving earns its keep on the models it runs.

FAQ

What is Kimi K3?

Moonshot AI's flagship MoE model, launched July 16, 2026: 2.8T total parameters, 104B active, 1M-token context, native vision, built on Kimi Delta Attention and Attention Residuals. Available as kimi-k3 via API, as K3 Max / K3 Cluster Max in the Kimi app, and as open weights on Hugging Face since July 27.

How much does the Kimi K3 API cost?

$3/M input tokens, $0.30/M on cache hits, $15/M output tokens on Moonshot, flat at any context length. Morph serves the same model as morph-kimik3 at $2.50/M input, $0.29/M cached, and $14.00/M output.

How fast is Kimi K3?

Between 42 and 251 output tok/s across the 13 hosts Artificial Analysis tracks; Moonshot's own API measures 42 tok/s at a 3.25-second time to first token. InferenceX measured 4,051 tok/s per B300 GPU at 100 tok/s per user with vLLM in FP4. Morph describes K3 on its GB300 NVL72 racks as settling at 100 tok/s.

Is Kimi K3 open source?

The weights are open, since July 27, 2026, on Hugging Face (moonshotai/Kimi-K3) under the Kimi K3 License: MIT-style terms plus a separate-agreement clause for Model-as-a-Service businesses over $20M in 12-month revenue and a UI attribution clause above 100M monthly users or $20M monthly revenue. Shipped as a native MXFP4 QAT checkpoint with a technical report and day-zero vLLM and SGLang support.

Is Kimi K3 better than GLM-5.3?

K3 scores 44 and GLM-5.3 45 on Artificial Analysis Intelligence Index v4.3, checked September 7, 2026. K3 adds native vision and a flat-priced 1M window; GLM-5.3 costs under a third as much per token. Against GLM-5.2, K3 leads on agentic benchmarks (88.3 vs 82.7 on Terminal-Bench 2.1 per Moonshot's card) and on the AA index (44 vs 39).

Can I run Kimi K3 in Claude Code or Cline?

Yes. Morph's endpoint speaks both the OpenAI API and the Anthropic Messages API, so Claude Code runs morph-kimik3 by pointing ANTHROPIC_BASE_URL at https://api.morphllm.com; setup is on the Kimi K3 API page. Any OpenAI-compatible client also works against https://api.moonshot.ai/v1 with model kimi-k3. Keep the always-on reasoning in mind: agent loops that fire many small calls pay max-effort reasoning on each one unless you lower reasoning_effort.

Is Kimi K3 free?

Not on the API. Moonshot's platform is prepaid with a $1 minimum top-up, and your cumulative top-up sets your rate limits; there are no trial credits and no free API tier, and OpenRouter carries no free K3 route. The consumer Kimi app is the free path, but it has been capacity-constrained since launch week: Moonshot paused new paid subscriptions on July 19, 2026, three days after K3 shipped. The weights carry no license fee for internal use, so local running costs hardware instead of tokens.

How do I run Kimi K3 locally?

On system memory, use Unsloth's dynamic GGUF builds with llama.cpp: 594 GB and about 610 GB of combined RAM plus VRAM for the 1-bit UD-IQ1_S, 861.3 GB and about 880 GB for the 2-bit UD-Q2_K_XL. On datacenter GPUs, requantize: VESSL's W4AFP8 conversion runs on 16 H200s across two nodes under SGLang at 327.5 output tok/s. Full table and caveats in how to run Kimi K3 locally. No 128 GB workstation holds any of these builds.

How big is Kimi K3, and how do I download it?

2.8 trillion parameters, published at moonshotai/Kimi-K3 on Hugging Face as a native MXFP4 checkpoint, roughly 1.4 TB of raw four-bit weights. Unsloth's full-precision GGUF conversion is about 1.56 TB and its smallest 1-bit build is 594 GB. A BF16 dequantization would be roughly 5.6 TB before KV cache.

Who makes Kimi K3, and when was it released?

Moonshot AI, a Beijing-based lab. The API and Kimi app launched K3 on July 16, 2026; the open weights followed on July 27, 2026. It succeeds K2.6 (April 2026) and K2.7 Code (June 2026).

Which provider should I use for Kimi K3?

There is no single answer, because measured speed and measured fidelity do not track each other. Modal is the fastest generally available host at 151 tok/s and posts the lowest DeepSWE score of any submitted vendor on Moonshot's conformance leaderboard; Baseten is a third slower and scores near the vLLM reference. Two hosts serve a truncated context window. The provider table puts both scoreboards side by side.

Why does Kimi K3 perform worse in my coding agent than in the Kimi app?

Almost always a request-construction bug, not the model. Log one outgoing request body and check four things: reasoning_effort is present and set to what you intended, temperature is absent (Moonshot fixes it at 1.0), max_tokens is a value you chose, and the previous assistant message went back with its reasoning_content intact. Shipping agents get all four wrong; the harness-bug section documents a case where fixing them took the worst turn from 507 seconds to 6.7 seconds.

What happened to the 2.5T parameter figure?

That was the pre-launch leak number. The shipped spec in Moonshot's platform documentation and the Hugging Face model card says 2.8 trillion, with 104 billion active.