I Did the Math on Kimi K3. The $15 Output Price Isn't the Whole Cost Story.

Moonshot AI launched Kimi K3, a 2.8-trillion-parameter Mixture-of-Experts model with a one-million-token context window, on July 16. However, claims that every token uses all 2.8T parameters and that weights are immediately downloadable are false; the model activates only 16 of 896 experts per token, and weights are promised by July 27 but not yet released. The API pricing shows $15 per million output tokens, but actual costs depend heavily on cache hits and output token ratios, which can significantly increase bills.

Kimi K3 launched on July 16, and three claims immediately started traveling together: Two are wrong. The third is incomplete. I spent the launch day reading Moonshot AI's release notes, API guide, pricing page, and the first independent measurements. The model is genuinely interesting. But the decision to migrate is much less obvious than the launch numbers make it look. Moonshot AI's official Kimi K3 announcement https://www.kimi.com/blog/kimi-k3 confirms a 2.8-trillion-parameter Mixture-of-Experts model, a one-million-token context window, native vision, tool use, and an API model named kimi-k3 . That is the confirmed layer. A few launch-day headlines quietly added claims that Moonshot did not make. | Claim | What I could verify | Status | |---|---|---| | Kimi K3 launched July 16, 2026 | Official announcement | Confirmed | | Total parameter count is 2.8T | Official announcement | Confirmed | | Every token uses 2.8T parameters | Not stated; MoE activates 16 of 896 experts | False framing | | Context window is 1M tokens | Official announcement and API docs | Confirmed | | Weights are downloadable now | No K3 checkpoint was listed when I checked | False as of launch day | | Weights will arrive by July 27 | Moonshot's stated plan | Confirmed commitment, not completed release | I care about that distinction because "2.8T open model" suggests two things at once: enormous active compute and immediate self-hosting. Neither follows from the information currently available. K3 uses a Mixture-of-Experts architecture. Moonshot says each token activates 16 experts from a pool of 896. It also describes Kimi Delta Attention, Attention Residuals, and a Stable LatentMoE design. What Moonshot has not disclosed is the active parameter count per token. That missing number matters more than the headline total if you're estimating inference cost, memory traffic, or local serving requirements. I would not invent it from the expert ratio because shared layers, expert sizes, routing details, and architectural overhead are not fully documented yet. There is still a useful lower-bound calculation. If all 2.8T parameters were stored at exactly four bits: 2.8 trillion parameters x 4 bits / 8 = 1.4 trillion bytes = about 1.4 TB of raw weight storage That is before metadata, scales, runtime buffers, KV cache, and replication. Moonshot recommends 64 or more accelerators for deployment. I'd treat desktop-class local inference claims as unproven until the checkpoint, quantizations, and real serving reports exist. The official international API price has three lines: | Token category | Kimi K3 price per 1M tokens | |---|---| | Cache-hit input | $0.30 | | Cache-miss input | $3.00 | | Output | $15.00 | Those rates put uncached input below many premium frontier APIs and output at the same list price as GPT-5.6 Terra. But price per token is only one side of the bill. I ran three basic workloads. | Monthly workload | No-cache K3 cost | With stated cache mix | |---|---|---| | 10M input + 2M output | $60 | Depends on cache hits | | 100M input + 20M output | $600 | $384 at 80% cached input | | 1B input + 200M output | $6,000 | $3,570 at 90% cached input | The first row is straightforward: 10M input x $3/M = $30 2M output x $15/M = $30 Total = $60/month For a team processing 100M input and 20M output tokens each month, automatic prefix caching changes the result: 20M uncached input x $3/M = $60 80M cached input x $0.30/M = $24 20M output x $15/M = $300 Total = $384/month That is useful. I would absolutely engineer stable prompt prefixes to capture it. But now add output behavior. Artificial Analysis https://artificialanalysis.ai/models/kimi-k3 reported that K3 generated about 130M output tokens across its evaluation, while the median among comparable models was 63M. That does not prove your workload will see the same ratio. It does prove that output volume deserves measurement. At K3's $15/M output rate: 63M output tokens x $15/M = $945 130M output tokens x $15/M = $1,950 Difference = $1,005 for the same evaluation-scale comparison This is why I don't call a model cheap until I have cost per completed task. A model that emits twice as many tokens can cost more even when its token rate looks competitive. Moonshot's launch table reports strong results in coding, terminal use, web browsing, science, and multimodal document understanding. These are vendor-reported scores, not one clean independent leaderboard. | Benchmark | Kimi K3 | Best comparison shown by Moonshot | Launch-table reading | |---|---|---|---| | DeepSWE | 67.5 | 73.0 | K3 does not lead | | Terminal-Bench 2.0 | 88.3 | 88.8 | Near the top | | BrowseComp | 91.2 | 90.4 | K3 leads this table | | GPQA Diamond | 93.5 | 94.1 | Competitive, not first | | MMMU-Pro | 81.6 | 83.0 | Competitive, not first | | OmniDocBench | 91.1 | 89.8 | K3 leads this table | I would not convert this into a universal ranking. Moonshot's own footnotes show that models were tested with different reasoning modes and tool configurations. A score produced with one harness is not automatically comparable to a score produced with another. The independent picture is more restrained. Artificial Analysis currently gives K3 an Intelligence Index of 57, reports about 62 output tokens per second, and measures a 1.99-second time to first token. Those numbers can change as providers optimize serving, so I see them as an early baseline, not a permanent verdict. K3 is available through an OpenAI-compatible API, but compatibility does not mean "change one model string and forget it." The official quickstart https://platform.kimi.com/docs/guide/kimi-k3-quickstart documents these launch constraints: | Migration issue | Kimi K3 behavior | What I'd change | |---|---|---| | Reasoning control | Top-level reasoning effort ; only max currently works | Remove K2-style thinking parameters | | Sampling | Fixed values such as temperature 1 and top p 0.95 | Do not send custom overrides | | Conversation history | Full assistant messages must be preserved | Store the complete assistant response | | Model switching | Not supported mid-conversation | Start a new conversation when changing models | | Web search | Being updated; official docs advise against it for now | Use your own search tool | | Image input | Public image URLs are not supported | Upload or encode images using a supported path | Here is the routing decision I would use during the first two weeks: python def choose kimi k3 workload : if workload "needs downloadable weights today" : return "Wait. Verify the July 27 checkpoint and license first." if workload "requires low reasoning effort" : return "Use another model until K3 exposes lower reasoning modes." if workload "depends on provider web search" : return "Use your own search tool or keep the current model." if workload "long context" or workload "multimodal documents" : return "A/B test K3 with output caps and cost-per-task logging." if workload "output cost sensitive" : return "Test verbosity before routing production traffic." return "Run a representative eval before changing the default route." I would also pin max completion tokens , log output tokens per successful task, and keep stable system/tool prefixes so automatic caching has a chance to work. For an agent or coding product: I would send 5% of representative traffic to K3, compare task success and retries, and record total input plus output tokens. Vendor benchmark wins are not enough to justify a migration. For a long-document workflow: I would test the full one-million-token path, but I would include retrieval baselines. A large context window is useful only if the model can retrieve the right evidence reliably and economically. For a self-hosted stack: I would wait for July 27, then inspect the actual license, checkpoint format, quantizations, and serving requirements. A promised weight release is not a deployable artifact. For a budget-sensitive API workload: I would use stable prompt prefixes, cap output, and compare cost per accepted answer. The $0.30 cache-hit price is attractive; the $15 output rate makes verbosity expensive. For an existing K2.6 deployment: I would not assume cost continuity. Moonshot's Chinese pricing page lists K3 at RMB 2/20/100 per million cache-hit input, uncached input, and output tokens, versus RMB 1.10/6.50/27 for K2.6. That is roughly 1.82x, 3.08x, and 3.70x across those categories. Kimi K3 is a serious attempt to compete at the frontier with scale, long context, multimodality, and an open-weight commitment. It is also a useful reminder that model launches now compress several different questions into one headline: K3 currently answers the first question. The next ten days should answer more of the second and third. Only your eval can answer the fourth and fifth. If you want to compare Kimi with OpenAI, Anthropic, and Google through one OpenAI-compatible endpoint, that's roughly what TokenMix https://tokenmix.ai does. Disclosure: I work on the research side. The full data-cited breakdown is in the original Kimi K3 review https://tokenmix.ai/blog/kimi-k3-release-preview-4t-parameters-2026 . Kimi K3 is real, the 2.8T total parameter count is official, and the $3/$15 API is live. The active parameter count is undisclosed, the weights are promised rather than available, and early independent testing says output volume can be unusually high. I'd test it now. I would not route production by headline. Which matters more in your workload: the one-million-token context window, the $0.30 cache-hit rate, or controlling output verbosity?