TL;DR — Kimi K3 ships with a 1,048,576-token context window and pricing of $2.648/$13.283 per million tokens, and its weights are openly downloadable as moonshotai/Kimi-K3. Probe results show correct code, correct math, and valid JSON extraction, at throughput ranging from 13.7 to 36.9 tokens/sec depending on task. This is the class of open model where 'open-weight' and 'self-hostable' have quietly split apart.
Somewhere along the way, "open-weight" stopped meaning "something you can run." Kimi K3 is a good place to notice that split. The weights sit on Hugging Face under moonshotai/Kimi-K3, free for anyone to download. The context window is 1,048,576 tokens. And unless your organization already operates a GPU fleet built for models at this scale, the only sane way to touch it is through an API meter ticking at $2.648 per million input tokens and $13.283 per million output tokens.
What K3 is built for
The metadata is blunt about the intent: a full 1,048,576-token context and pricing structured for high-value completions rather than casual chat. That combination — huge context, premium output pricing — points at agentic workloads: long tool-use loops, multi-step research, code-repository-scale reasoning, where the model reads a lot and writes selectively. It's not priced or shaped like a model meant to answer one-line questions all day.
Moonshot AI positions this as part of a heavyweight, agent-oriented model family — that framing is a vendor claim, not a measured benchmark, but it's consistent with what the context window and pricing imply about the target workload.
What the probes actually showed
I ran three small, verifiable tasks against it rather than trusting a spec sheet.
The code probe asked for an interval-merging function. The output sorted intervals, merged overlaps with a single pass, and correctly stated O(n log n) complexity dominated by the sort — that's the right answer, and the example trace it included checks out. It took 30.7 seconds to produce 619 completion tokens, which works out to 20.1 tokens/sec — not fast, but the code was clean and idiomatic, not padded filler.
The reasoning probe was a two-phase tank-filling problem. It correctly computed the net fill rate during the overlap phase (30 L/min, 600 L after 20 minutes), then correctly solved for the remaining 1,800 L at 90 L/min for a final answer of 20 more minutes. The arithmetic is right at every step, and it showed its work rather than just asserting a number. This one ran at 13.7 tokens/sec — the slowest of the three, despite being the shortest output, which suggests reasoning-heavy generation costs more per token here than pattern-completion tasks do.
The structured-output probe asked for strict JSON extraction from an invoice string. It returned exactly {"vendor":"Meridian Office Supply","date":"03 March 2026","total":445.50} — valid JSON, correct field mapping, and it correctly picked the amount due as "total" rather than the subtotal, which is the trap most extraction prompts fail on. This ran fastest at 36.9 tokens/sec.
Across all three, the model got the substance right. The spread in throughput — 13.7 to 36.9 tokens/sec across tasks — is worth remembering: latency here isn't a single number, it's task-dependent, and reasoning-style generation on this model runs meaningfully slower than pattern extraction.
Where this actually earns its keep
This is the section that matters more than any spec: who should reach for a model like this, and for what.
Whole-repository code agents. A 1,048,576-token context can hold an entire mid-sized codebase plus its test suite plus a design doc, without chunking or retrieval tricks. If your agent needs to reason across files rather than snippets, this is the class of model that makes that tractable in one pass.
Long-document contract or compliance review. Feeding an entire contract set, a full regulatory filing, or a multi-hundred-page technical spec into one context window avoids the lossy summarization-of-summaries problem that chunked RAG pipelines run into.
Multi-step agentic tool use. The pricing and context shape suggest a model meant to sit in a loop — read state, call a tool, read the result, decide the next step, repeat — over long sessions without losing track of earlier context. The correct multi-step math in the reasoning probe is a decent proxy for this kind of chained logic holding up.
Structured extraction at the far end of a long pipeline. The clean JSON output, with the correct field picked out of ambiguous invoice text, is exactly the kind of task you'd chain after a long-context retrieval step — pull the needle out of the haystack, then hand back a typed object.
What it's not a good fit for: quick, cheap, high-volume chat traffic. At $13.283 per million completion tokens, a chatty back-and-forth app would burn budget fast, and the 13.7–20.1 tokens/sec range on substantive tasks means users waiting on a live response will feel it. This is a model for jobs where correctness and context depth matter more than latency and unit cost.
What self-hosting this would actually take
Here's the part the "open-weight" label glosses over. A model at this scale needs a serving stack most teams don't have lying around: multiple high-memory GPU nodes running tensor and pipeline parallelism just to hold the weights in memory, let alone serve concurrent requests with a million-token context — KV cache alone at that context length is enormous per active session. That's before you account for the engineering time to get a distributed inference stack tuned, monitored, and kept online.
Run the arithmetic on a single full-context call: 1,048,576 input tokens at $2.648/M is roughly $2.78 just to fill the window once, before a single output token is generated. That's the API's price for convenience. The self-hosted price is a capital outlay for GPU capacity that sits mostly idle unless your usage is sustained and heavy enough to amortize it — which, for most teams, it isn't. Renting via API isn't the fallback option here; for the vast majority of use cases, it's the only economically sane one.
Why "downloadable" still matters
So why does it matter that moonshotai/Kimi-K3 sits openly on Hugging Face if almost nobody will actually pull those weights and run them? Because open weights aren't only about who runs the model today — they're about who's allowed to inspect it, fine-tune it, or run it air-gapped tomorrow if they have the hardware and the reason. A government lab, a well-funded research group, or a company with existing GPU infrastructure can do things with an open trillion-parameter-class model that they simply cannot do with a closed one, regardless of API price. Most of us will never touch the raw weights. The fact that we're allowed to is the whole point.
Tomorrow closes out the heavyweight run with a model that takes the mixture-of-experts idea even further: Qwen3.8-2.4T (A95B MoE), and what it takes to activate just a sliver of a very large model at a time.
The numbers (measured, not quoted)
I ran three quick probes against Kimi K3 via a hosted API today before writing this. Small sample, one snapshot in time, routed hardware I don't control — treat these as a smell test, not a benchmark:
| Probe | Wall-clock | Output tokens | Tokens/sec (effective) | Result |
|---|---|---|---|---|
| Code | 30.7s | 619 | 20.1 | completed |
| Reasoning | 13.3s | 183 | 13.7 | completed |
| Structured output | 12.2s | 449 | 36.9 | completed |
Effective tokens/sec includes queueing and time-to-first-token — it's what you actually experience, not peak decode speed.
Model card: context window 1,048,576 tokens · hosted pricing $2.648/M input · $13.283/M output · weights: moonshotai/Kimi-K3 on Hugging Face
Credits — where it's due
- Moonshot AI — for training Kimi K3 and releasing the weights openly: moonshotai/Kimi-K3. Open releases like this are why a series like this can exist at all.
- OpenRouter — the hosted API used for today's live probes and the pricing/context figures.
- The quantizers and runtime maintainers — the mostly-unpaid people who turn every open release into something that runs on real hardware within days.
Top comments (0)