Kimi K3’s 1M context window, without the misleading shortcut

Moonshot AI and OpenRouter publish Kimi K3 with a 1,000,000-token context window. Context includes the system instruction, conversation messages, document or code content, image-related input representation, tool messages, and the tokens reserved for the answer. A request cannot use the entire headline number for source material and still expect an unbounded output.

Tokens are not characters or words. English prose often uses more than one token per word, source code tokenizes differently, and non-English text can have a different ratio. The reliable way to size a request is to use the tokenizer or usage fields from the provider path you will deploy, then leave margin for instructions and output.

Specifications can change. This page was reviewed July 17, 2026; confirm the current limit in the official Kimi documentation and on the OpenRouter model card.

The hosted K3 Kimi interface intentionally does not expose a one-million-token upload box. It sends up to the recent eight messages, allows at most 6,000 characters in each message, accepts one supported image up to 4 MB for signed-in users, and bounds the output. These are product-level controls for predictable latency, abuse resistance, and fixed per-response credits.

This distinction prevents a common marketing error: describing the model’s maximum capacity as if every hosted chat request included it. The web interface is suitable for focused conversations and selected excerpts. It is not a full-corpus ingestion system. If you need hundreds of thousands of tokens in one request, build directly against the API and measure the result with your own data.

For direct API access, start from the official Kimi K3 quickstart. Provider limits and account spending controls still apply even when the model accepts the payload size.

A large context can reduce manual splitting, preserve distant dependencies, and let the model compare evidence that would not fit in a small window. It can also increase input cost, time to first token, and the amount of irrelevant material competing for attention. Duplicated files and stale documents can make an answer worse while making the request more expensive.

Long-context recall is not uniform. A model may miss one exception buried among thousands of similar passages or overweight a clear summary placed near the end. Benchmark scores such as long-context retrieval tests are useful signals, but your own document structure, query, and evidence density determine the production outcome.

Start with the smallest complete evidence set. Add material only when it resolves a known uncertainty. This makes it easier to audit which source changed the answer and prevents a giant prompt from becoming an unreviewable substitute for retrieval design.

1. 01Define the question and the evidence required to answer it.
2. 02Remove duplicate versions, boilerplate, navigation, and irrelevant appendices.
3. 03Chunk by semantic boundaries such as sections, cases, functions, or modules.
4. 04Retrieve a small candidate set, preserving source names and stable locations.
5. 05Ask for claims linked to the supplied source locations and explicit uncertainty.
6. 06Verify decisive claims against the original document before acting.

For recurring analysis, store source metadata alongside each chunk and make the model quote a short identifying fragment rather than inventing a citation. Re-run retrieval when the question changes; the chunks that answer a contract-risk question may not answer a product-requirements question.

Begin with repository structure, build files, public interfaces, and the exact failing path. Ask the model to identify which files it still needs before pasting whole directories. Include tests and runtime errors because they reveal contracts that comments may not capture. Generated code should follow the repository’s existing style rather than creating a new abstraction for every change.

For a cross-cutting change, supply a dependency map and then the relevant entities in batches. Keep a verified working summary of decisions, invariants, and open questions. If that summary changes, replace it rather than appending contradictory versions. The model can then reason across the selected system without repeatedly reading unrelated assets and generated files.

Always run the code. A large context may help Kimi K3 see an interface mismatch, but only the actual compiler, test suite, and deployed runtime can validate the behavior.

OpenRouter charges input and output tokens according to its current model pricing. Large prompts therefore increase cost even when the answer is short, and cached-input discounts should not be assumed until your measured provider response confirms them. Set spending limits, cap output, record usage fields, and test timeouts at the largest size you intend to support.

More context also means more data leaves your system. Remove secrets, personal data, unrelated customer records, and material you are not authorized to process. Review the retention and privacy terms of every provider in the request path. K3 Kimi’s Privacy Policy explains its hosted path; your direct API implementation needs its own disclosure and controls.

For everyday prompting, follow the Kimi K3 usage guide. For workload ideas, review the practical use-case guide.