Kimi K3: The 2.8T Model Promising Open Weights—and a Hidden Harness Contract

Rohit Ramachandran

Jul 17, 2026Updated Jul 17, 2026

• ai
• moonshot-ai
• kimi
• kimi-k3
• open-models
• coding-agents
• model-infrastructure
• long-context

Kimi K3: The 2.8T Model Promising Open Weights—and a Hidden Harness Contract

Moonshot 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.

K3 has two launch dates

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.

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.

The evidence ledger is unusually lopsided

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.

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 architecture is trying to make very large agents economically possible

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.

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.

Open weight does not mean local

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.

The hidden contract lives in the harness

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:

• the chat template and assistant-message schema;
• complete thinking-history preservation;
• tool-call parsing and replay;
• stable ordering of system instructions and tool definitions;
• context compaction that does not corrupt the reasoning chain;
• KDA-aware kernels and cache behavior on self-hosted routes;
• the evaluation harness used to decide what “good” means.

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.

The API price is really a cache-design incentive

Moonshot's official K3 rate card charges per million tokens:

• $0.30 for cache-hit input
• $3.00 for cache-miss input
• $15.00 for output

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.

The benchmarks say “frontier competitor,” not “universal winner”

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.

There are several caveats a launch chart cannot hide:

• K3 uses KimiCode while Claude uses Claude Code and GPT uses Codex on many tests.
• Terminal-Bench competitors may use each model’s preferred harness.
• The table’s DeepSWE result is 67.5, while the footnote reports 67.3 under the official mini-SWE-agent harness.
• K3 benchmark runs use top_p=1.0; today’s public API fixes top_p=0.95.
• BrowseComp rises from 90.4 with raw 1M context to 91.2 when compaction starts at 300K.
• Several K3 evaluations are internal, and the technical report and reproduction code are not available.

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.

The agent design may matter more than the raw model

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.

Safety evidence is missing while autonomy is increasing

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.

There is no public zero-data-retention promise

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:

• whether prompts, outputs, tool results, files, images, and video may be retained;
• whether any of that material may be used for model or service improvement;
• retention duration and deletion processes;
• storage and processing regions;
• subprocessors and cross-border transfers;
• security incident notification and audit rights;
• whether enterprise terms override the public OpenPlatform terms.

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.

Who should test K3 now—and who should hold

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.

Four consequences if K3 delivers

1. Open models become provider markets

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.

2. Agent memory becomes an economic primitive

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.

3. Open weights do not eliminate stack dependence

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.

4. July 27 may matter more than launch day

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.

Final take

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.

Frequently asked questions

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.