Kimi K3 Is Cheap to Call, but the Weights Are Not Here

Kimi K3’s least intimidating number is not 2.8 trillion parameters. It is the $0.30 that Moonshot AI charges for one million cached input tokens. The more sobering number sits deeper in the launch material: Moonshot recommends a supernode with at least 64 accelerators for teams that eventually want to host the model themselves.

That mismatch defines K3 more usefully than another model leaderboard. Moonshot announced Kimi K3 on July 16 at 2:58 p.m. EDT, and the hosted model is already available through Kimi’s products and API. Full weights, however, are only promised by July 27. The license, downloadable checkpoint, complete technical report, mature serving path and measured hardware bill are not yet public.

K3 is therefore cheap to call before it is cheap—or even fully possible—to own. Developers can start measuring API task economics now. They cannot yet treat “open” as proof of provider independence, local deployment or control over the model stack.

The launch contains two different products

The first product is available today. K3 can be called as kimi-k3 through Moonshot’s API and used inside Kimi, Kimi Work and Kimi Code. Moonshot’s launch specification describes a native multimodal model with a one-million-token context window, 2.8 trillion total parameters and 16 active experts out of a pool of 896.

The second product is an ownership proposition that has not arrived. Moonshot says it will publish the full weights by July 27 and that a technical report will follow. Until those artifacts appear, prospective self-hosters cannot inspect the final license, calculate storage and memory requirements from the actual checkpoint, reproduce the serving configuration or test whether third-party runtimes preserve the behavior seen on Moonshot’s infrastructure.

This is a new lifecycle stage rather than a rewrite of TECHi’s earlier Kimi K2.5 multimodal launch coverage. K2.5 centered on multimodality, agent clusters and Alibaba’s strategic exposure. K3 changes the buyer question: which parts of the new scale-efficiency claim are usable now, and which remain promises about a later checkpoint?

“Open weight” also needs to stay separate from “open source.” Weights can make inspection and self-hosting possible, but the license determines what users may modify, redistribute or commercialize. A model page cannot settle those rights before the license and files exist.

Sparse activation trims work, not the whole machine

K3 routes each token through 16 of its 896 experts. That is the main reason a 2.8-trillion-parameter model can have a plausible hosted-inference story: only a small fraction of the expert pool performs the dense computation for a given token. Moonshot combines that sparse mixture with Kimi Delta Attention, Attention Residuals and what it calls Stable LatentMoE.

The company has already published research code for Kimi Delta Attention and Attention Residuals. That work makes two architectural components less opaque without supplying the K3 checkpoint or proving that an independent operator can reproduce Moonshot’s production latency, throughput or quality.

Sparse activation does not erase the inactive experts. Their weights still need storage, placement and access across the serving system. Routing adds communication, expert balancing and cache-management work. Moonshot says K3 uses MXFP4 weights and MXFP8 activations after quantization-aware training, yet still recommends a supernode with 64 or more accelerators. That is a data-center deployment boundary, not a local-model recipe.

TECHi has seen this distinction before in Nvidia’s 72-GPU deployment claims for Moonshot models: a model-level efficiency claim can improve throughput while leaving interconnect, memory capacity and orchestration as the economic constraint. The same applies to the wider AI memory-equipment bottleneck. K3’s sparse route reduces active calculation per token; it does not make 2.8 trillion stored parameters disappear.

The price card rewards repeated context

Moonshot’s current K3 pricing is $0.30 per million cache-hit input tokens, $3 per million cache-miss input tokens and $15 per million output tokens, excluding tax. The tenfold gap between hit and miss pricing matters more than the cheapest headline number.

A workload that sends one million cached input tokens and receives 250,000 output tokens would cost $4.05 at the listed rates: $0.30 for input and $3.75 for output. The same volume with an input-cache miss would cost $6.75. Output remains the larger component in both cases. A long-running coding agent that generates extensive reasoning and tool-call text can therefore spend more on completion than the cache discount saves.

Moonshot says coding workloads can exceed a 90% cache-hit rate. That is a vendor observation, not a portable guarantee. Real hit rates depend on whether the application preserves prefixes, avoids model switches, reuses long context and keeps tool history in the format K3 expects. A small change in orchestration can move a request from the $0.30 tier to the $3 tier.

The defensible comparison is cost per completed task under the same tools, stopping rules and retry policy. K3 could still be cheaper than a rival with a lower per-token price if it reaches a correct result with fewer retries. It could be more expensive if always-on reasoning produces long outputs or unstable tool loops. Token rates alone cannot decide that.

A million-token window comes with a state contract

K3’s one-million-token context window sounds like storage capacity, but agent developers also have to preserve state correctly. The official API quickstart says multi-turn and tool-calling applications must return the complete assistant response, including thinking history. K3 was trained with preserved thinking history; switching models mid-session or dropping that history can make generation quality unstable.

The API currently exposes K3 with maximum reasoning effort. Moonshot fixes several sampling settings and allows very large completion limits. Kimi Code, meanwhile, documents different context entitlements by subscription tier and presents low, high and maximum reasoning modes on its own surface. Those descriptions may reflect product-specific wrappers, but they are not interchangeable API guarantees.

Other current limits narrow the “available now” claim. The API does not accept public image URLs for vision inputs, and Moonshot warns that its official web-search integration is being updated and is not recommended in the near term. Its launch notes also say K3 may act too proactively when instructions are ambiguous and recommend stricter behavioral constraints.

That last warning is commercially important. Long-horizon agents need control surfaces, not only stronger task completion. TECHi’s recent analysis of execution hooks inside CrewAI agents showed why interception, policy and call-level measurement belong inside the loop. K3 buyers should test permission boundaries, rollback behavior and human approval points before rewarding a model for doing more work autonomously.

The benchmark chart mixes the machinery

Moonshot’s launch table reports competitive numbers: 88.3 on Terminal-Bench 2.1 against 88.8 for GPT-5.6 Sol, 77.8 on Program Bench against 77.6 for GPT-5.6 Sol, and 42 on SWE Marathon against 40 for Claude Opus 4.8. Those figures are useful evidence that K3 deserves evaluation. They are not a controlled verdict across models.

The footnotes show why. K3 is tested with KimiCode on some benchmarks and Claude Code on others. Rival results may use Claude Code, Codex, Terminus, official leaderboards or each model’s best harness. One comparison allows Claude Fable 5 refusals to fall back to Claude Opus 4.8. Some results come from in-house tests. The DeepSWE chart and footnote even report slightly different K3 scores, 67.5 and 67.3.

None of that proves the results are invalid. It proves the harness is part of the product. Tool definitions, context compaction, retry behavior, refusal handling and reasoning budgets can change an agent score. A buyer comparing K3 with another frontier model should run the same repository snapshot, harness, tool permissions, token budget and judge, then measure success rate, latency and total cost together.

The strongest independent validation will arrive after the weights and technical report. Reproduction on a second serving stack would show whether K3’s quality travels with the checkpoint or depends materially on Moonshot’s own routing, cache and product layers.

July 27 is a proof date, not a finish line

The promised weight release can close several gaps, but only if the surrounding artifacts are complete. A usable release needs a clear commercial license, checkpoint hashes, tokenizer and configuration files, memory and storage guidance, reference serving code, supported quantization paths and enough evaluation detail to reproduce the central claims.

Infrastructure teams will also need measured throughput on named hardware. “At least 64 accelerators” leaves a wide cost range across accelerator models, memory capacities, interconnects and utilization. A 64-device cluster that serves many concurrent workloads efficiently can make economic sense for a provider. The same topology may be wasteful for an enterprise with bursty internal demand.

API-first teams do not need to wait. Start with a fixed task set, then record cache-hit rates, complete tool traces, approval points and the cost of every retry. A useful result is a distribution of completed-task cost and operator intervention—not one benchmark score.

Teams that require data residency, provider independence or weight-level inspection should wait for the checkpoint and license. Until Moonshot ships them, research groups can draft a reproduction plan, but the central self-hosting assumptions cannot be tested.

Kimi K3 may prove that frontier-level sparse models can reset hosted inference prices without giving up long-context agent performance. The launch evidence is strong enough to justify testing that thesis. It is not yet strong enough to price ownership. For the next ten days, K3 is an API product with an open-weight deadline—not an open deployment stack.

Article Brief

Deployment checklist

3 Points18s Read

1. 01Usable now–Kimi K3 is live through Moonshot AI’s hosted products and API, with cache-sensitive token pricing.
2. 02Not shipped yet–The downloadable checkpoint, final license, technical report and independent serving proof remain pending.
3. 03Measure the task–Compare completed-task cost, cache-hit rate, latency, retries and operator interventions under one controlled harness.