Kimi K3 API pricing: open weights that now cost more than Sonnet 5

By Wallace Gomes de Souza (LW Forge) — about the author · Updated August 12, 2026

Open-weights models are supposed to be the cheap option. Kimi K3 isn't. Moonshot AI released it on July 16, 2026 as the first open model at 2.8 trillion parameters, and priced the hosted API at $3.00 per million input tokens and $15.00 per million output — at the time, the exact list rate of Claude Sonnet 5. That coincidence didn't survive the month: Anthropic has since made Sonnet 5's $2/$10 launch price permanent instead of letting it expire, so K3 now costs 50% more than Sonnet on both input and output. K3 was never competing on price with the open-weights field — it's competing on capability with the closed flagships — but the flagship it matched most closely on price just got cheaper without it.

The rates, as of August 4, 2026

K3's cache rate is $0.30 — a flat 90% off its own input price, the same discount structure Anthropic uses (Sonnet's cache rate is $0.20, 90% off its now-permanent $2 input price). And unlike Gemini, K3 charges the same rate across the full million-token window; there is no long-context surcharge waiting at the 200k mark.

What the price difference actually buys

Same workload for both posts in this pair: 300M input tokens and 40M output tokens a month, roughly a mid-sized agentic assistant.

Two things fall out of that table. Against Opus 4.8, K3 still saves $1,000 a month — 40%, a real number if K3 clears your quality bar. Against Sonnet 5, the comparison flipped: what was an exact tie at list price in July is now Sonnet permanently cheaper, by $500 a month — 33% less than K3 on identical traffic — because Anthropic made the launch rate standard instead of letting it expire on schedule. K3 no longer has a cost argument against Sonnet 5, only capability and portability ones. Price your own volumes in the Claude cost calculator; see Sonnet 5's launch price is now permanent for the announcement.

Is the 1M window worth paying for?

Claude tops out at 200k tokens; K3 takes 1M. The instinct is that this saves money on long documents. It mostly doesn't, and it's worth seeing why.

Say you need to reason over a 900k-token corpus. On K3 that's one call: 900k × $3/M = $2.70 of input. On Claude you chunk it — five passes of 180k, each carrying the same 30k instruction and schema prefix. That's 900k of document plus 150k of repeated prefix, then a reduce pass over the five summaries. Call it 1.06M input tokens, about $2.12 on Sonnet at its current $2 rate. The chunked version is now the cheaper one, by about 20% — a reversal from when Sonnet was priced at $3/M — even before counting that prompt caching on the repeated prefix would push the gap further in Sonnet's favor. K3's single call still wins on simplicity, just not on price.

The real argument for 1M isn't the invoice, it's what the chunked version can't do: notice that a clause on page 40 contradicts a table on page 380. Map-reduce loses cross-references by construction, and no amount of prompt engineering puts them back. If your task genuinely needs whole-corpus reasoning, the window is worth paying for; if it's "summarise each section," it isn't. Check what your documents actually measure in the context window calculator before assuming you need the extra room — most workloads that feel enormous land under 200k.

Where K3 earns the premium, and where it doesn't

The honest case for K3 over Sonnet 5, now that Sonnet is the cheaper of the two, is portability, not price. The weights are public under a modified MIT licence, so the hosted API is a convenience rather than a dependency. You can move to a different host, run your own inference for a workload that can't leave your infrastructure, or keep serving a frozen version after the vendor deprecates it. None of that is available on Claude at any price. If a data-residency clause or a vendor-risk review is what's blocking your project, that is worth $0 of price difference and a lot of unblocked work.

The case against is the usual open-weights tax: SDK maturity, structured-output edge cases, observability integrations, and the fact that on aggregators the host serving your request may run a different quantisation than the one you benchmarked. Moonshot's hosted API also runs under Chinese jurisdiction, which is a governance question the open weights answer only if you actually self-host.

Against Opus 4.8 the calculus is different: you're paying 40% less for a model that trades Opus's peak reasoning for a 5× larger window and open weights. Whether that's a good trade depends entirely on how often your traffic hits the hardest 10% of tasks, where flagship reasoning still wins measurable head-to-heads. Opus vs Sonnet vs Haiku covers how to classify that traffic; the same routing logic in Sonnet 5 vs Haiku 4.5 applies here — run the cheap tier first, escalate what fails a self-check.

How to decide in an afternoon

Pull 200 real requests. Run them through K3, Sonnet 5 and Opus 4.8 with identical instructions and output caps. Score correctness the way you already do, then compute cost per successful task, charging retries to whichever model caused them. If K3 matches Sonnet, the deciding factor is portability, not price — and you should make that call deliberately rather than by default. If K3 matches Opus, you've found your $1,000 a month.

Two levers to apply before you conclude anything: cache the stable prefix at 10% of input on all three models (prompt caching), and check whether K3's always-on reasoning is inflating your output token counts, since output bills at 5× input on every model in this table. If $3/$15 turns out to be more than your task needs, GLM-5.2 at $1.40/$4.40 is the same open-weights bet at less than half the price.