The combination that makes K3 interesting for document work is not the window size on its own — plenty of models advertise a million tokens. It is the window plus the cached-input price. Loading a 500,000-token corpus costs $1.50 the first time and $0.15 on every question after that, which changes the shape of what is worth building.
This page is written for analysts, researchers, and legal or finance teams working with large document sets. If you want the model overview first, start with the complete Kimi K3 guide.
| Best effort level | max (the API default is max) |
| Context available | 1M tokens — enough for real working material, not just snippets |
| Cost | $3.00 per million input tokens, $15.00 per million output, $0.30 cached input |
Why Kimi K3 suits long-document analysis
- 1,048,576 tokens of context — roughly 750,000 words, or a few thousand pages depending on layout.
- Cached reads at $0.30 per million tokens, a tenth of the standard input rate. Asking twenty questions of the same corpus is not twenty times the cost.
- Native vision means scanned pages, charts, and diagrams go in alongside the text rather than through a separate OCR step.
- Always-on reasoning suits the actual task: finding a contradiction between page 30 and page 600 is a reasoning problem, not a retrieval one.
- Output up to 1,048,576 tokens if configured, so a full summary of a very large corpus does not have to be assembled across turns.
A workflow that works
- Load the corpus once, then cache it. Send the documents as a stable prefix and vary only your question at the end. This is the whole economic argument for using a big window instead of retrieval.
- Ask for exact quotations with locations. The cheapest possible hallucination check: if the quoted text is not in the document, you will see it immediately.
- Ask one question per call. Bundling ten questions into one prompt produces shallower answers on each. Calls against a cached corpus are cheap — use more of them.
- Feed scans as images, not OCR text. The vision encoder is native, and a bad OCR pass upstream is a common source of errors that look like model failures.
- Keep a page-number map. Long-context answers are only auditable if you can get back to the source, and models are not reliable narrators of their own pagination.
Settings to start from
Set reasoning_effort to max. Cross-document reasoning is where depth pays. When the task is "find every clause that conflicts with section 4", the reasoning pass is the work, and it is a small fraction of the cost next to the input tokens you have already paid for. Drop to high for straightforward extraction and low for pure lookup.
Remember that reasoning cannot be turned off on this model, and that the API default is max — the most expensive of the three levels. Setting it explicitly is the single highest-value line of configuration you will write. See reasoning effort explained if you want to tune it properly.
What to watch out for
- A full window is a real bill. At $3.00 per million, a 1M-token prompt costs $3.00 before the model writes a word. Cache, or send less.
- Cache misses are silent. If your prefix changes by one byte — a timestamp, a reordered document — you pay full rate. Verify cache-hit behaviour in your usage figures rather than assuming.
- Long-context quality claims are hard to verify independently. Moonshot publishes strong long-context results, but there is no substitute for a needle test on your own corpus.
- Retrieval still wins at genuine scale. For corpora that change constantly or run to tens of millions of tokens, a pipeline beats a big window. The window is a better answer for the mid-size case, which is most cases.
The verdict
For a document set in the tens or hundreds of thousands of tokens that you query repeatedly, this is close to the ideal shape: load once, cache, and ask freely. Build retrieval when your corpus outgrows the window — not before, because the pipeline you skip is real engineering you do not have to maintain.
If cost is the constraint, read how to cut Kimi K3 costs before downgrading — caching and effort levels usually beat switching models.
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
How many pages can Kimi K3 read at once?
Its 1,048,576-token window holds roughly 750,000 words — a few thousand pages of plain text, or fewer for image-heavy PDFs where layout and figures consume additional tokens. Output is capped at 131,072 tokens by default and can be configured up to the full 1M.
Is it cheaper to use the context window or build a retrieval system?
For a mid-size corpus you query repeatedly, the window plus caching is usually cheaper in total cost of ownership, because cached input costs $0.30 per million and you skip building and maintaining a pipeline. For very large or rapidly-changing corpora, retrieval still wins.
Can Kimi K3 read scanned PDFs?
Yes — vision is native rather than adapter-based, so scanned pages, charts, and diagrams can go in as images. Note that the API does not accept public image URLs: you must supply base64 or a `ms://<file-id>` reference to an uploaded file.


