Most models cap output well below their input window. Kimi K3 does not: max_completion_tokens defaults to 131,072 tokens and can be raised to 1,048,576 tokens — the entire context window, available as a single response. That is unusual enough to be worth understanding, including why you usually should not use it.
The numbers
| Default | 131,072 tokens |
| Ceiling | 1,048,576 tokens |
| Parameter | max_completion_tokens |
| Output price | $15.00 per million tokens |
For comparison, Claude Opus 5 and Claude Sonnet 5 both cap output at 128K tokens. K3's default is marginally above that, and its ceiling is eight times higher.
Note that third-party routers sometimes cap output lower than the model supports, so if you are going through an aggregator, check that route's published limit rather than this one.
What a million output tokens is for
Genuine use cases exist, and they are narrower than they sound:
- Whole-codebase transformations — a framework migration emitted as one coherent set of files rather than assembled across turns.
- Full document translation or rewriting where splitting the work would lose cross-references and consistency.
- Exhaustive structured extraction from a very large corpus, where the output is a large dataset rather than a summary.
The common thread is that chunking would genuinely damage the result. If chunking is merely inconvenient, chunk.
Why the default is a cost risk
131,072 tokens at $15.00 per million tokens is about $1.97 for a single maximally long response. The full 1M ceiling would be roughly $15.70.
Neither is a disaster in isolation. Both are a problem in a loop. A retry-on-failure agent that hits the default ceiling repeatedly can produce a bill that looks like a bug, because it is one.
Set max_completion_tokens to what your use case actually needs. It is a one-line change and the most effective guardrail available on this model.
Two practical warnings
- Stream anything large. A long non-streamed response will hit HTTP timeouts before it finishes. This is the most common cause of "the API is broken" reports on large generations.
- Reasoning shares the budget. Reasoning is always on and its tokens count against your output allowance. A limit sized precisely to your expected answer length can be consumed before the answer begins — always check
finish_reasonrather than assuming a response is complete.
More on Kimi K3
Start with the complete Kimi K3 guide for the overview, or go deeper:
Ready to go deeper?
Read the full Kimi K3 guideFrequently Asked Questions
What is Kimi K3's maximum output length?
`max_completion_tokens` defaults to 131,072 tokens and can be configured up to 1,048,576 — the full context window as a single response. Third-party routers sometimes cap this lower, so check the specific route if you are not calling Moonshot directly.
Should I set max_completion_tokens to the maximum?
No. Set it to what your use case needs. A maximally long response costs around $15.70 at $15 per million output tokens, and an agent loop that repeatedly hits a high ceiling produces a bill that looks like a bug. The generous default is itself worth overriding.
Why does my long Kimi K3 response fail?
Two likely causes. Long non-streamed responses hit HTTP timeouts — stream anything large. And reasoning tokens share the output budget, so a tightly-sized limit can be consumed before the answer starts. Check `finish_reason` on every response.
