Kimi K3 is Moonshot AI's largest model yet: a 2.8-trillion-parameter mixture-of-experts system with native image input, a maximum one-million-token context window, and a launch pitch centered on coding, knowledge work, and long-horizon agents. The scale is remarkable. The more useful question is what that scale changes for people who need to choose, run, or evaluate the model.
This guide synthesizes three Chinese launch-day articles rather than translating any one of them: the detailed benchmark and hands-on account from Digital Life Kha'Zix, the architecture and official-case summary from Jingguan Home, and the pricing and independent-benchmark roundup from AI Cambrian. Their overlap is substantial, so repeated launch specifications and charts appear only once here. Their distinct contributions—especially the first article's production failure—are preserved and clearly attributed.
The result is a more cautious picture than the launch headlines. Kimi K3 is already usable through Moonshot's hosted products and API, and it has credible early strengths. But its weights were not yet downloadable when this article was prepared on July 17, 2026; several spectacular demonstrations are vendor-reported; benchmark harnesses are not uniform; and operating a 2.8T model is a different proposition from downloading a conventional open-weight checkpoint.
What Is Kimi K3?
Moonshot introduced Kimi K3 on July 16, 2026. Its headline specifications are:
- 2.8 trillion total parameters in a highly sparse mixture-of-experts architecture;
- 16 routed experts active out of 896 for each token, alongside shared experts;
- up to one million tokens of context;
- text and image input, with text output;
- max reasoning effort as the launch default;
- access through Kimi.com, Kimi Work, Kimi Code, and the Kimi API.
That last point matters. Kimi K3 is not only a model card or future checkpoint. It is available now as a hosted model. In Kimi Code, the model ID is k3, and users can select it with the /model command. Moonshot describes it as especially capable in coding, games and 3D, and knowledge work.
The phrase “one-million-token context” needs a qualifier. It describes the model's maximum supported window, not an entitlement for every account and product tier. Kimi Code's current documentation limits Moderato users to 256K and enables up to 1M only on Allegretto and higher plans. Tools may also default to a smaller window unless configured explicitly.
Kimi K3's native vision capability means it can inspect screenshots and other images while reasoning about code or documents. It does not generate images or video as its model output; Artificial Analysis lists text and image as inputs and text as the output modality.
Is Kimi K3 Actually Open Source Yet?
This is the first important correction to the three WeChat headlines.
Moonshot calls Kimi K3 the world's first “open 3T-class model.” However, the same official announcement says the full weights will be released by July 27, 2026. As of July 17, the Moonshot AI Hugging Face organization listed K2-series models but no Kimi K3 checkpoint. Artificial Analysis therefore classified the currently accessible K3 service as proprietary and explicitly said the weights were unavailable.
The most accurate description today is:
Kimi K3 is a hosted model with a stated commitment to release its full weights by July 27. It should not yet be treated as a downloadable open-weight model, and its practical license terms cannot be evaluated until the release appears.
“Open source” also has several layers. Public weights permit local inference and research; open training code, reproducible data, a permissive license, and complete technical documentation are separate questions. Moonshot says a technical report and more architecture details will arrive with the weights. Until then, teams should avoid making compliance or self-hosting plans based only on the word “open.”
Inside the 2.8-Trillion-Parameter Architecture
The 2.8T headline is a total-parameter count, not the amount of computation applied densely to every token. Kimi K3 uses a very sparse MoE design: its Stable LatentMoE layer routes work to 16 of 896 experts. Sparsity is what makes an architecture at this scale remotely serviceable, although it introduces hard routing, memory, and communication problems.
Four pieces are particularly important:
- Kimi Delta Attention (KDA) is the efficient-attention foundation. Moonshot positions it as a way to scale long-sequence processing without carrying the full cost profile of ordinary attention.
- Attention Residuals (AttnRes) let a layer retrieve representations from earlier depths selectively instead of accumulating every previous state in the same way.
- Stable LatentMoE and Gated MLA manage sparse expert computation and attention selectivity. The architecture includes shared experts as well as routed experts.
- Quantile Balancing and Per-Head Muon address training stability. The former derives expert allocation from router-score quantiles; the latter optimizes attention heads independently.
Moonshot also says quantization-aware training starts at the supervised-fine-tuning stage, using MXFP4 weights and MXFP8 activations. Those choices show that training and inference constraints shaped the model from the beginning rather than being treated only as post-release compression.
The company reports about 2.5× better scaling efficiency than Kimi K2 after combining the architecture with refined training and data recipes. That is a vendor result, not an independently reproduced measurement, and “scaling efficiency” should not be confused with 2.5× cheaper inference for every workload.
How Strong Are the Kimi K3 Benchmarks?
Kimi K3's launch table is strong, especially in coding and agents, but it does not show one model winning everything.
In Moonshot's table, Kimi K3 scores 67.5 on DeepSWE, 88.3 on Terminal-Bench 2.1, 81.2 on FrontierSWE, 77.8 on Program Bench, and 42.0 on SWE Marathon. The pattern supports a “broadly competitive” conclusion: K3 trails GPT 5.6 Sol and Claude Fable 5 on some precise-execution tasks, leads or nearly leads several other tests, and places between those systems on FrontierSWE.
The footnotes matter as much as the bars. Different models sometimes use different agent harnesses—Kimi Code, Claude Code, or Codex. Some Claude results include fallback behavior. Several results are taken from public leaderboards, others are rerun by Moonshot, and Kimi Code Bench is internal. All K3 launch results use max reasoning effort. These choices do not invalidate the table, but they prevent a clean conclusion that score differences measure the model alone.
The strongest independent early signal is front-end development. On July 16, the live Arena WebDev leaderboard placed kimi-k3 first at 1,679, based on 1,757 votes. The result was marked preliminary and carried a ±17 interval, so the rank can change as votes accumulate.
Artificial Analysis supplies a different perspective. Its Kimi K3 page reports an Intelligence Index score of 57, output speed of 62 tokens per second, and roughly 130 million output tokens consumed across the index—more than twice the 63M comparison average shown on the page. It also calculated a total evaluation cost of $2,690.80. In other words, K3 is intelligent but relatively verbose, slower than the comparison average, and not cheap at uncached API rates.
One useful narrow result is CritPt, a difficult physics-reasoning evaluation. The preserved chart places Kimi K3 at 23%, behind several leading systems but above many others. That is a healthier way to read benchmarks: identify task-specific evidence rather than turn one rank into a universal model hierarchy.
Coding Proof Points: Impressive, but Mostly Vendor-Reported
The most ambitious Kimi K3 examples are not leaderboard rows. They are long-horizon projects described in Moonshot's launch post and summarized extensively by Jingguan Home.
The clearest is MiniTriton. Moonshot says K3 built a Triton-like GPU programming system with a tile-level intermediate representation over MLIR, optimization passes, a PTX code-generation pipeline, and a runtime. On supported roofline tests, the company reports performance comparable to or better than Triton and torch.compile for some workloads. The system also ran end-to-end nanoGPT training with a loss curve close to the reference.
Moonshot also describes 24-hour kernel-optimization trials in identical sandboxes. An early K3 version reportedly handled most of the team's own kernel optimization during late development. Other cases include:
- a 48-hour autonomous run that designed and verified a small chip using open-source EDA tools and a 45nm library;
- a computational-astrophysics workflow that reviewed more than 20 papers, evaluated over 300 equations of state, and produced more than 3,000 lines of Python;
- screenshot-driven game and front-end work in which the model iterated on visual output;
- research and presentation projects using many searches, documents, terminal actions, and subagents.
These examples are valuable because they show what Moonshot optimized the product to do. They are not equivalent to reproducible public benchmarks. The prompts, agent scaffolding, retries, human interventions, intermediate failures, and artifact repositories are not all available. Treat them as demonstrations worth testing, not guaranteed outcomes.
What the WeChat Hands-On Test Adds
The most informative original material in the three-source set comes from the Digital Life Kha'Zix author, who ran Kimi K3 through Kimi Code against a live AI news product called AIHOT.
The positive result was substantial. According to the first-person account, K3 read operational documentation, reviewed a batch of user feedback, separated worthwhile requests from rejected ones, opened several agent workspaces, implemented seven changes, ran CI, merged successful work, and sent expected emails. The author found its front-end output especially strong and considered its planning competitive with another frontier model across several trials.
But the same test produced the best warning in the source set. For a trend-ranking feature, K3 followed an existing backfill pattern and loaded roughly 9,000 items into a pipeline that could process only six concurrently. Normal incoming stories queued behind the backfill, leaving the site without fresh content for nearly an hour. CI passed because the failure was architectural and workload-dependent, not a simple syntax or unit-test error.
That incident is more useful than another success screenshot. It reveals a recurring agent limitation: a system can execute a local pattern correctly while missing a global capacity constraint. Long context and multiple agents do not automatically supply unstated operational invariants. Production tasks still need explicit budgets, rate limits, queue policies, rollout stages, observability, and rollback conditions.
The WeChat authors' enthusiastic front-end judgments align with Arena's early result, which gives that impression more weight. Their broader claims about writing quality, aesthetics, or which model is “best” remain personal observations. A team should run its own representative tasks and score correctness, latency, token use, review effort, and regressions—not only visual appeal.
Price, Context Limits, and the Real Cost of Scale
Kimi K3's official API price is straightforward per token:
| Token type | Price per 1M tokens |
|---|---|
| Cache-hit input | $0.30 |
| Uncached input | $3.00 |
| Output | $15.00 |
Moonshot says its infrastructure sees a cache-hit rate above 90% in coding workloads. That does not mean every customer will pay the $0.30 rate for 90% of all input. Cache reuse depends on stable prefixes, session behavior, tool integration, cache policy, and whether switching models or reasoning effort invalidates prior context. Kimi Code's documentation specifically warns that changing models or effort can force context to be prefetched again.
Output is the expensive part, and independent testing suggests K3 can be verbose. A nominally low cache-hit input price can therefore coexist with a high task cost when the model reasons for a long time or emits large outputs. Budget against completed tasks, not only the price of one million input tokens.
The maximum context window carries similar nuance. One million tokens may be useful for large repositories and document collections, but access is plan-dependent, and filling the window increases prefill, cache, retrieval, and review costs. More context can also bury the instructions or evidence that matters. Curated context and explicit constraints remain important.
Self-hosting is an even larger qualification. Moonshot recommends supernode configurations with 64 or more accelerators for efficient K3 deployment. Sparse activation reduces compute per token, but all 2.8T weights still create major memory, expert-parallel communication, and operational requirements. Even after weights arrive, “open” will not mean “runs on a workstation.” Most users will initially consume K3 through hosted services or specialized inference partners.
Who Should Use Kimi K3 Now?
Kimi K3 is worth a serious trial for teams doing:
- long-horizon coding with terminal tools and repository-scale context;
- front-end or 3D work that benefits from image feedback;
- agentic research that combines browsing, documents, code, and presentation;
- large-context knowledge work where a hosted one-million-token window is practical;
- evaluation of future open-weight infrastructure at extreme MoE scale.
It is not yet a safe default for every workload. Wait for the weights, license, and technical report if self-hosting or compliance is the primary requirement. Compare task-level cost if output verbosity matters. Use staged rollouts and hard operational constraints for production agents. And keep vendor demonstrations, blind preference arenas, independent benchmarks, and personal field reports in separate evidence buckets.
A sensible evaluation plan is small:
- Choose five to ten representative tasks, including at least one failure-prone production scenario.
- Use the same tool permissions, repository state, time limit, and acceptance tests for each model.
- Record token use, wall-clock time, API cost, human review time, and regression count.
- Test context-window claims at the plan tier and integration you will actually buy.
- Recheck open-weight availability and license terms after July 27 rather than assuming the announced release occurred exactly as planned.
Kimi K3 FAQ
How many parameters does Kimi K3 have?
Moonshot reports 2.8 trillion total parameters. Kimi K3 is a sparse mixture-of-experts model, so it routes each token through a small subset—16 of 896 routed experts—rather than using all parameters densely for every token.
Does Kimi K3 really support one million tokens?
The model supports up to 1M, but product access varies. Kimi Code documentation currently gives Moderato accounts up to 256K and Allegretto or higher accounts up to 1M. Third-party tools may need an explicit 1048576 context setting.
Is Kimi K3 open source?
Not in a practically downloadable sense as of July 17, 2026. Moonshot says full weights will be released by July 27. The license, repository contents, and technical report should be reviewed when they appear.
How much does the Kimi K3 API cost?
The official rates are $0.30 per million cache-hit input tokens, $3 per million uncached input tokens, and $15 per million output tokens. Actual task cost depends heavily on cache reuse and output-token consumption.
Is Kimi K3 the best coding model?
There is no single defensible answer. K3 leads the preliminary Arena WebDev ranking and performs strongly across Moonshot's coding suite, but other models lead individual benchmarks. Harness choice, reasoning settings, cost, speed, and the team's real tasks can change the ranking.
Sources
WeChat source articles
- Digital Life Kha'Zix: Kimi K3 launch, benchmark interpretation, and AIHOT hands-on test
- Jingguan Home: Kimi K3 architecture, coding cases, and pricing summary
- AI Cambrian: Kimi K3 arena, Artificial Analysis, pricing, and multimodal summary
Leave a Reply