The Kimi K3 context window

What filling it costs

Two things to take from this table. First, a single full-window call costs about the same as 1,000 short chat turns — the window changes the unit of cost, not just the amount. Second, the "cached rerun" column is the only thing that makes repeated long-context work affordable: a 10× cut on the biggest line item on your bill. That column is why how you order your prompt matters more at 500k tokens than anywhere else.

The bottom row is extrapolation and we've labelled it as such. We measured ~5× the wall clock for ~5× the tokens between our two long runs, which is roughly linear, but two points don't establish a curve and we haven't tested the full window. Treat ~110s as an order of magnitude, not a number.

The ceiling is not a length control

The window and max_completion_tokens get conflated constantly, and on K3 the confusion is expensive.

• The 1,048,576 context window is how much K3 can read — your prompt.
• max_completion_tokens (default 131,072) is how much it may write — including its reasoning.

That second point is the trap. Reasoning draws from the completion budget, so capping max_completion_tokens to get "shorter answers" instead caps how long K3 is allowed to think. Below about 2,048 we measured it returning nothing at all, billed in full. If you want short answers, ask for them in the prompt. The six runs →

Also worth knowing: max_completion_tokens: 2000000 — nearly double the window — returns HTTP 200 rather than an error. The API will not tell you the number is nonsense. More silent failures →

When the window is worth it

It pays when the same large context is reused. A codebase, a contract, a document set that you ask twenty questions about: the first call pays $1.49, and the next nineteen pay $0.15 each because the prefix stays warm. That is the shape the window is built for, and it is genuinely hard to do any other way.

It does not pay for one-shot retrieval. If you're pushing 500k tokens through once to answer one question, you're spending $1.49 and 52 seconds where a retrieval step and a 5k-token prompt would cost a fraction of a cent and return in seconds. The million-token window is not a substitute for RAG — it is a different tool, and using it as one is the most expensive mistake available here.

Latency is the constraint people underestimate. Cost you can optimise with caching. Wall clock you cannot: caching did not make warm calls faster in any of our tests. A 52-second call is 52 seconds whether or not you paid full price for it. If a human is waiting, that number decides your architecture.

Practical notes

• Stream at long context. Non-streaming means a minute of silence with no signal that anything is working.
• Set client timeouts in minutes. Default SDK timeouts will kill a legitimate 52-second call.
• Watch prompt_tokens in production. At $3.00/1M, prompt bloat is the line item that runs away. One accidental full-window call is $3.15.
• Order the prompt for caching from day one. Stable bytes first, varying turn last. At this scale the discount is the difference between viable and not.

Context window FAQ

How big is the Kimi K3 context window?

1,048,576 tokens — 2²⁰, a full binary million — per the official pricing page read on 2026-07-16.

What does it cost to use the full Kimi K3 context window?

About $3.15 of input for one call at the $3.00/1M cache-miss rate, or roughly $0.31 if the prefix is already warm. We measured a 497,718-token call at $1.49 and 52 seconds; the full-window figure is arithmetic and extrapolation from that.

Is max_completion_tokens the same as the context window?

No. The context window is what K3 can read; max_completion_tokens is what it may write, including its reasoning, and defaults to 131,072. Setting it low does not shorten answers — it truncates thinking, and below ~2,048 we measured empty responses billed in full.