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

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

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:

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.

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

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 documents these launch constraints:

Here is the routing decision I would use during the first two weeks:

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 does. Disclosure: I work on the research side. The full data-cited breakdown is in the original Kimi K3 review.

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?