Kimi K3: The 2.8T Model Promising Open Weights—and a Hidden Harness Contract
Rohit RamachandranJul 17, 2026Updated Jul 17, 2026
Rohit RamachandranRohit RamachandranRohit RamachandranMoonshot AI announced Kimi K3 on July 16, 2026 with a number designed to own the launch cycle: 2.8 trillion parameters.
Moonshot describes that as the largest model announced for an open-weight release. It also makes the easiest interpretation—bigger Chinese model, better benchmark chart—almost useless.
The consequential part of K3 is the system around those parameters. Moonshot paired an unusually sparse Mixture-of-Experts design with Kimi Delta Attention, a one-million-token context window, automatic prefix caching, native visual input, long-horizon agent training, and API pricing built around repeated context. The bet is that frontier agents become cheaper when the model architecture, serving fabric, memory format, and agent loop are designed together.
There is one crucial qualification: K3 is not downloadable yet. The API is live, but Moonshot says it will release the full weights by July 27. As of July 17, there is no public K3 checkpoint, repository, license, model card, technical report, or K3-specific safety report.
That leaves K3 in an important in-between state:
frontier API today
open-weight commitment for July 27
institution-scale deployment: the intended path
consumer-local model: not practical
My read is that K3 could become a serious frontier alternative for coding and knowledge-work agents. But its real contract is larger than a set of weights. Production behavior depends on preserved thinking history, a KDA-aware serving stack, prefix-cache discipline, tool parsing, and the harness used to run the model. K3 may be open at the checkpoint layer while remaining demanding—and surprisingly sticky—at the system layer.
Moonshot’s launch article and API quickstart make K3 usable now. The model ID is kimi-k3. K3 is exposed through Moonshot’s OpenAI-compatible Chat Completions endpoint only, with text, image, and uploaded-video input.
The official launch date is July 16, 2026. That is when K3 appeared in Kimi’s products and API.
The second date is July 27. Moonshot says the full model weights will be released by then. Moonshot has discussed a forthcoming technical report, but has not announced a publication date or explicitly tied it to the July 27 weights deadline.
That distinction matters because “open-weight” describes a released artifact, not a launch intention. Until the checkpoint and license exist, developers cannot inspect the tensors, verify the serving recipe, fine-tune the model, compare providers running identical weights, or test whether the official API’s behavior survives self-hosting.
| Layer of the release | Status on July 17 | What builders can actually do |
|---|---|---|
| Kimi products | Live | Use K3 through Kimi.com, Kimi Work, and Kimi Code |
| Official API | Live | Call kimi-k3 through Chat Completions with text, image, or video input |
| Weights | Promised by July 27 | No independent inspection, fine-tuning, or self-hosting yet |
| Repository and license | Not published | Commercial redistribution and derivative-model rights remain unknown |
| Model card and K3-specific safety report | Not published | Training disclosure, safety evidence, and intended-use boundaries remain incomplete |
| Technical report | Forthcoming; no date announced | Compute, data, dimensions, active parameters, and reproducible methodology remain incomplete |
Moonshot calls K3 “open” and sometimes “open-source.” The precise description today is narrower: an API model launched with a commitment to release open weights by July 27.
Prior K2 checkpoints used a Modified MIT license. That is precedent, not K3’s license. Related KDA kernels being MIT-licensed does not establish the rights that will attach to K3’s weights.
K3 arrived with a polished product demonstration and a large benchmark table, but without the artifacts normally required to audit a frontier open-weight model.
Here is the useful way to separate what we know.
API access, price, 1M context, text/image/video input, max reasoning, tool calling, structured output, automatic caching, and the July 27 weight commitment.
2.8T scale, 16-of-896 routing, roughly 2.5× K2 scaling efficiency, long-horizon autonomy, launch benchmark scores, and production cache rates above 90% for coding.
#1 in Arena frontend preference, 74.7% on the Vals Index, 57 on Artificial Analysis, strong simulated automation, and early evidence of high reasoning-token consumption.
Weights, repository, license, active parameters, model card, safety report, serving recipe, training disclosure, local benchmarks, and a complete reproducibility package.
This does not make the launch untrustworthy. It makes it early. The right posture is to test the live product while keeping infrastructure, governance, and procurement conclusions provisional.
K3's 2.8 trillion total parameters are organized in a Stable LatentMoE system that Moonshot says effectively activates 16 of 896 experts. Sparse activation can reduce compute per token, but it does not make the other experts disappear. They still need storage, placement, routing, and fast access when selected.
That is not the same as an active-parameter count.
The model also has shared experts, dense attention and routing layers, a visual path, and other parameters outside the selected routed experts. Moonshot has not disclosed expert dimensions or how much of the network runs per token. Labeling K3 with an active-parameter suffix such as “A50B” would turn an estimate into a specification.
K3's useful pipeline: sparse model capacity becomes a distributed serving problem, then a harness contract, then an API bill, and finally a cost-per-completed-task decision.
Three named architectural ideas matter.
Kimi Delta Attention handles information across time. KDA is a hybrid linear-attention mechanism that uses recurrent state to control what to preserve and overwrite instead of maintaining a conventional full-attention KV cache everywhere.
Moonshot’s earlier Kimi Linear paper reported up to 75% lower KV-cache use and up to 6× decoding throughput at one-million-token context. Those measurements came from a 48B-total, 3B-active research model—not K3. They explain the design direction; they are not K3 performance numbers.
Attention Residuals handles information across depth. Attention Residuals lets a layer retrieve earlier representations with learned, input-dependent weights, aiming to reduce representation dilution in deep models.
Stable LatentMoE handles capacity. Moonshot combines sparse experts with Quantile Balancing and a fully balanced expert-parallel training method using static shapes and no host synchronization on the critical path. Per-Head Muon, Gated MLA, and a Sigmoid Tanh Unit also appear in the launch description.
| Architecture fact | What is confirmed | What remains unknown |
|---|---|---|
| Model size | 2.8T total parameters | Active parameters, layer count, width, and expert dimensions |
| Expert routing | 16 of 896 experts with Stable LatentMoE | Shared-expert structure, capacity factors, and routing overhead |
| Attention | KDA plus Gated MLA | Exact KDA/MLA layout and K3-specific cache savings |
| Depth routing | Attention Residuals | Block arrangement and measured K3 contribution |
| Precision | MXFP4 weights and MXFP8 activations after quantization-aware training | Checkpoint format, scale overhead, and accuracy trade-offs |
| Context | 1,048,576 tokens through the API | Retrieval reliability across different long-context workloads |
The architectural thesis is coherent: use huge dormant capacity, activate a small routed slice, make long context cheaper, and preserve useful information across both tokens and layers.
The missing question is whether the complete K3 system converts those ideas into better task economics, rather than merely fitting an extraordinary parameter count into a cluster.
At a theoretical four bits per parameter, 2.8 trillion parameters require:
2.8 trillion × 4 bits
= 11.2 trillion bits
= 1.4 TB of raw weight values
That lower bound excludes quantization metadata, non-quantized tensors, buffers, activations, recurrent or KV state, redundancy, and serving overhead.
MoE reduces compute because only selected experts run for a token. It does not eliminate the need to keep all experts reachable with enough bandwidth to route tokens efficiently.
Moonshot therefore recommends a supernode with at least 64 accelerators. The important word is not merely “64.” It is “supernode”: expert parallelism needs a large, fast communication domain. Buying enough aggregate memory without the interconnect to keep experts fed is not a viable deployment.
No K3 self-host benchmark exists because the weights are not public. There is no official accelerator matrix, topology, memory measurement, or launch command. Moonshot says a KDA prefill-cache implementation for vLLM will arrive with the model.
This is where the meaning of open weights changes.
For a 7B model, openness can mean running it on a laptop. For K3, it means:
specialist inference providers can compete
large enterprises can operate a private cluster
researchers can inspect or modify the checkpoint
clouds can optimize for different hardware
buyers gain an exit path from one API
That is valuable. It is simply not consumer-local AI.
RohitAI made a related argument in the Tencent Hy3 analysis: headline parameters and active parameters shape different parts of the bill. With K3, a third variable becomes unavoidable—the network needed to make sparse scale usable.
K3 is exposed through an OpenAI-compatible API, but “compatible” does not mean interchangeable.
At launch, the public K3 integration surface is Chat Completions only. Applications call /v1/chat/completions; there is no separate K3 Responses API surface documented. The API accepts text, image, and uploaded video input. It supports tool calls, structured output, and long conversations, but the surrounding client has to respect K3’s operating assumptions.
The largest assumption is thinking history. Every multi-turn request must replay the complete prior assistant message, including reasoning_content; dropping the thinking history or casually switching models can destabilize continuation.
Moonshot explicitly warns that dropping this history can make subsequent generation unstable. Switching models halfway through the same conversation can also break the implicit state contract.
That changes the portability question:
OpenAI-shaped request body
does not equal
drop-in behavioral compatibility
A production K3 agent depends on more than a model ID:
This is the hidden harness contract in the title. The weights may become open, while reliable behavior still depends on reproducing the environment Moonshot trained and serves around them.
Moonshot's official K3 rate card charges per million tokens:
The price is flat across the context window. Automatic prefix caching requires no explicit cache identifier; keeping a long prefix unchanged gives later calls a chance to reuse it. Moonshot says its own Mooncake-based service sees cache-hit rates above 90% in coding workloads. That is a vendor production claim, not a universal expectation.
The 10× gap between cached and fresh input creates a clear agent architecture:
stable prefix:
system policy
repository snapshot
tool definitions
coding conventions
long reference documents
changing tail:
latest request
new tool output
recent patch
current test failure
A product that constantly reorders tools, rewrites its system prompt, or mutates early conversation history may pay ten times as much for those input tokens. A product that keeps its state stable can make a million-token window far less frightening.
Output is the counterweight. Maximum reasoning is always enabled for K3; it cannot currently be disabled or reduced. The default max_completion_tokens value is 131,072 and can be configured up to 1,048,576, subject to the combined input-and-output context limit. The public API also fixes temperature, top-p, sample count, and penalties.
Independent measurements show why this matters. Artificial Analysis recorded 130 million output tokens across its Intelligence Index, versus a comparison average of 63 million. Its complete K3 run cost $2,690.80.
Using K3 through OpenRouter, Simon Willison's early hands-on test sent a 95-token prompt and received 16,658 output tokens—13,241 of them reasoning tokens—for a reported cost of about $0.25. The task was small; the reasoning trace was not.
The right equation is therefore:
agent cost =
fresh context
+ cached context
+ reasoning and output
+ retries
+ review time
+ failed side effects
This extends the point from RohitAI’s agent cost-curve analysis: cheap tokens do not guarantee a cheap agent. The unit that matters is the accepted outcome.
Moonshot is more restrained than some launch commentary. Its own article says K3 still trails Claude Fable 5 and GPT-5.6 Sol overall.
Its benchmark table nevertheless shows serious capability. K3 is competitive on terminal work, program synthesis, browser research, tool use, visual reasoning, and several long-horizon software tasks.
The independent picture has three useful parts.
First, K3 reached #1 on Arena’s Frontend Code leaderboard, with 1679 ±17 in the preliminary July 17 snapshot. Fable 5 scored 1631 ±13, while GPT-5.6 Sol with the Codex harness scored 1618 ±13. This is meaningful human-preference evidence for web-interface generation. It is not proof of superior repository maintenance, backend correctness, or general coding.
Arena’s general text board was less dramatic: K3 was preliminary at #9, with a wide #4–27 rank spread. Fable and several Opus variants ranked above it.
Second, the Vals Index placed K3 at 74.7%, behind Fable 5 at 75.1% and ahead of Sol at 73.1%. That rank belongs to Vals’ finance-and-coding-heavy composite, not every capability, and its sampled private tasks constrain reproduction.
Third, Artificial Analysis measured a 57 Intelligence Index, 62 output tokens per second, and 1.99 seconds to first token. K3 also performed strongly on simulated application automation and professional knowledge work.
| Benchmark | Kimi K3 | Fable 5 | GPT-5.6 Sol | How to read it |
|---|---|---|---|---|
| DeepSWE | 67.5 | 70.0 | 73.0 | Vendor table; K3 used KimiCode |
| Program Bench | 77.8 | 76.8 | 77.6 | Near tie, with sourced competitor results |
| Terminal-Bench 2.1 | 88.3 | 84.6 | 88.8 | Different models use different preferred harnesses |
| FrontierSWE | 81.2 | 86.6 | 71.3 | Strong K3 result, but again with mixed harnesses |
| BrowseComp | 91.2 | 88.0 | 90.4 | K3 used context compaction at 300K |
| HLE Full | 43.5 | 53.3 | 44.5 | A clear area where K3 does not lead |
| MMMU-Pro | 81.6 | 81.2 | 83.0 | Competitive multimodal reasoning |
| OmniDocBench | 91.1 | 89.8 | 85.8 | Strong vendor-reported document result |
There are several caveats a launch chart cannot hide:
top_p=1.0; today’s public API fixes top_p=0.95.The honest conclusion is still impressive: K3 belongs in frontier evaluation suites now. The evidence does not justify declaring the entire frontier-model race settled.
Moonshot built K3 for long tasks, not quick chat. Its demonstrations include a GPU-kernel optimization evaluation that allowed each model up to 24 hours, a compact compiler, a 48-hour chip-design run, visual game development, and a scientific reproduction task spanning more than 20 papers. These are vendor demonstrations, not independently reproduced results. They show the intended workflow:
observe
plan
call tools
inspect output
revise
preserve state
continue for hours
K3 can use screenshots as feedback while editing code, making it relevant for frontend work, games, CAD, dashboards, and visual QA. That likely helps explain its Arena frontend result. Visual input is not native image or video generation.
The Chat Completions API also supports strict JSON Schema, custom functions, tool_choice, dynamically loaded tools, partial completion, and automatic caching. Moonshot recommends retrieving tool definitions on demand instead of dumping a huge tool inventory into every request.
Those features reinforce the earlier portability point: model portability and agent portability are different. The checkpoint may be available while the reliable operating envelope remains hard to reproduce.
Moonshot discloses three practical limitations: incomplete thinking history can destabilize performance; K3 can be excessively proactive when intent is ambiguous; and its user experience still trails Fable 5 and GPT-5.6 Sol. Moonshot recommends explicit behavioral boundaries in system prompts or AGENTS.md.
Those are useful disclosures, especially for an agent model. They are not a safety evaluation.
As of July 17 there is no public K3 model card or K3-specific safety/system card, red-team report, cyber or biology assessment, training-data disclosure, cutoff, bias analysis, or documented evaluation of prompt injection and tool-side effects.
The correct conclusion is not “K3 is unsafe.” It is “K3’s safety evidence is incomplete.” Fresh testing is necessary before a more capable, more autonomous system receives broad tool permissions.
Moonshot makes no public zero-data-retention promise for K3. A statement that content is not used for training is not a ZDR commitment and says nothing by itself about logging or retention. Customers needing tighter model-improvement restrictions or retention guarantees should obtain enterprise or separate written terms.
The broader Kimi OpenPlatform Terms and privacy terms allow broad collection and service-improvement uses of customer content. Public product, support, and legal pages do not establish the tighter model-improvement restrictions many enterprises require.
Before production use, obtain written answers covering:
This connects to a broader point from RohitAI’s repository-upload evidence review: a coding agent’s data path deserves the same scrutiny as its benchmark score.
K3 has unusually strong independent preference evidence for web interfaces, games, dashboards, screenshot-driven iteration, and visually judged prototypes.
Evaluate research, terminal work, large repositories, document-heavy analysis, and tool-rich tasks where stable prefix caching and long state could matter.
Wait for the checkpoint, license, deployment recipe, framework support, active-parameter disclosure, and measured throughput on your intended hardware.
Do not give K3 broad production permissions in security, infrastructure, finance, healthcare, or external communications before targeted safety and governance testing.
A useful pilot should compare K3 with at least one strong closed model and one cheaper open-weight route. Use tasks from your own backlog, not polished demo prompts.
That last metric matters most. As RohitAI argued in the GPT-5.6 agent-budget analysis, the cheapest route is the one that closes acceptable work at the lowest total cost—not the one with the lowest input-token price.
A 2.8T checkpoint is too large for most users, but it gives specialist providers something valuable to optimize. The competition moves to kernels, batching, quantization, interconnect, cache reuse, uptime, regional hosting, and support.
That can push prices down without requiring every customer to own a 64-accelerator cluster.
K3’s 10× cached-input discount makes prompt layout part of product economics. Stable policies, repositories, tool definitions, and reference corpora can become inexpensive reusable state. Careless context mutation becomes a recurring tax.
A KDA model with preserved thinking, specialized cache behavior, dynamic tools, and extreme expert parallelism can be open while remaining operationally difficult to reproduce. Future openness debates need to ask whether weights, license, code, kernels, chat templates, evaluations, and serving recipes are all available.
The second K3 story begins when developers can inspect the license, download the files, measure the checkpoint, read whatever documentation Moonshot publishes, port the architecture, and compare providers running the same artifact.
If Moonshot ships a permissive license, credible documentation, reproducible evaluations, and workable serving support, K3 becomes infrastructure. If the artifacts are delayed or constrained, the launch remains primarily an impressive hosted API story.
Kimi K3 is not important because 2.8 trillion is a satisfying headline.
It is important because Moonshot is testing whether open-weight frontier intelligence can support serious agents at a price below the premium closed frontier—using sparsity, long-context architecture, caching, and distributed serving as one system.
The early evidence is strong enough to test. K3 looks genuinely competitive in agent work and exceptional at frontend generation. It is not yet documented well enough to trust every launch claim, buy a cluster, or call the open-weight release complete.
And the checkpoint will not be the whole product when it arrives. K3’s preserved reasoning state, Chat Completions schema, cache-friendly prompt layout, KDA kernels, tool protocol, compaction policy, and evaluation harness together form a second contract. Teams that ignore it may discover that “same model” does not mean “same behavior.”
For most builders, the practical decision is straightforward:
test the API now
measure completed work
preserve the full thinking history
protect tool boundaries
watch output verbosity
wait for July 27 before believing the portability story
That is a more useful response than either dismissing K3 as benchmark theater or declaring the frontier race over.
What is Kimi K3?
Kimi K3 is Moonshot AI’s multimodal reasoning and agent model, announced July 16, 2026. Moonshot reports 2.8T total parameters, 1M context, visual input, sparse routing, and long-horizon agent training.
Are the Kimi K3 weights available?
Not as of July 17. K3 is live through Moonshot’s products and API; the weights are promised by July 27. No repository, license, public checkpoint, model card, or K3-specific safety report is available. The technical report remains separately undated.
Is Kimi K3 open source?
Not yet as a downloadable, licensed model. Moonshot launched the API and products on July 16 and says it will release the full model weights by July 27. As of July 17, no official K3 checkpoint, K3 license, or technical report was public.
How many parameters does Kimi K3 activate?
Moonshot has not disclosed it. The company says Stable LatentMoE effectively activates 16 of 896 experts, but shared and dense components are unknown, so that ratio cannot produce a reliable active count.
Can Kimi K3 run locally?
Not in the consumer sense. Four-bit arithmetic gives a 1.4 TB raw-weight floor before overhead, and Moonshot recommends at least 64 accelerators in a high-bandwidth supernode.
Which API does Kimi K3 support?
At launch, Moonshot documents K3 through its OpenAI-compatible Chat Completions API. It accepts text, image, and uploaded video input, supports tools and structured output, and always uses max reasoning. Multi-turn clients must preserve and resend the complete assistant message, including reasoning_content.
How much does the Kimi K3 API cost?
Moonshot lists $0.30 per million cached input tokens, $3 per million uncached input tokens, and $15 per million output tokens. Task cost depends heavily on cache reuse and always-on max reasoning.
Is Kimi K3 better than Claude Fable 5 or GPT-5.6 Sol?
It depends. K3 led Arena’s July 16 frontend board and is competitive on agent evaluations; Fable and Sol lead elsewhere. Compare completion, cost, latency, and failures on your own work.
Does Kimi K3 generate images and video?
No. Moonshot documents text, image, and video input, but the API does not generate raw images or video. It returns text content—including JSON-constrained structured output—along with reasoning_content and tool calls. Public image URLs are unsupported, so use base64 or ms://<file-id>.
Does the Kimi API offer zero data retention?
There is no blanket public ZDR promise for K3. Organizations that require no retention or stricter limits on model and service improvement should obtain enterprise terms or a separate written agreement covering retention, training and improvement use, storage, deletion, and subprocessors.
Should a company send proprietary code to the Kimi API?
Only after reviewing and, where necessary, negotiating the data terms. Sensitive users should obtain written restrictions covering model-improvement use, retention, storage, deletion, security controls, and subprocessors before sending proprietary material. Under the current public API terms, customers must not process HIPAA Protected Health Information.
What should builders watch on July 27?
The checkpoint size and format, K3-specific license, repository, active-parameter disclosure, model card or other documentation, safety evidence, vLLM and other framework support, required hardware topology, independent throughput, and whether self-hosted quality matches the official API.