How to Use Kimi K3's 1M Context: Whole Repos & Docs

Kimi K3 supports a 1 million token context. This guide covers what fits in 1M, how to structure messages for repo-wide code and long-doc Q&A, how caching cuts long-prompt costs by 90%, and when to still reach for RAG.

Kimi K3 pushes the context window to 1,048,576 tokens, roughly four times the size of K2. A lot of work that used to require chunking, RAG, and endless stitching can now be fed in all at once. But 1M isn’t an invitation to stuff the window blindly. Used well, it saves both effort and money; used badly, it gets slow and expensive. Here’s how to actually put 1M of context to work.

What fits in 1M tokens

As a rough conversion (mixed English/CJK text, based on practical experience), 1M tokens is about:

  • A mid-sized code repository: the core of several hundred source files;
  • A whole book: a technical manual or long document running hundreds of pages;
  • Dozens of PDFs / contracts: an entire project’s document set read in one pass;
  • A very long conversation history: the full context of a long-running agent after many rounds of tool calls.

In other words, tasks that previously had to be split up because they “wouldn’t fit” can now mostly be handled by K3 within the full context of a single request. The model sees the whole picture, and the biggest payoff is coherent answers with far less lost information.

Structuring repo-wide code analysis

When you feed code to K3, structure matters more than sheer volume. Here’s the recommended way to organize your messages:

system_prompt = "You are a senior engineer. Below is a complete repository. Cite specific files and line numbers in your answers."

repo_dump = "\n\n".join(
    f"### FILE: {path}\n```\n{code}\n```"
    for path, code in files
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": repo_dump + "\n\nQuestion: Which files hold the login/auth logic? Is there any duplicated code that could be merged?"},
    ],
)

A few key points:

  • Give every file a clear path marker (### FILE: path) so the model can cite it accurately;
  • Put the unchanging part (the repo contents) first and the per-request question last, so the fixed prefix can hit the cache;
  • Ask the model to cite files / line numbers so the output is verifiable rather than vague.

Long-document Q&A and caching

Long-document scenarios (legal contracts, papers, manuals) are the most effortless use of 1M context: drop the entire document into the system or first user message, then just keep asking, no manual chunking or retrieval needed.

The key money-saver: K3 has context caching on by default. When you ask different questions against the same long document repeatedly, that document prefix hits the cache, and the input price drops from ¥20/M to ¥2/M. So the order to organize things is:

[system: role + instructions]  ← fixed
[user: the full document]      ← fixed, hits cache
[user: this round's question]  ← changes each round

Putting fixed content first and variable content last is the first rule of saving money on long context. For the detailed pricing and caching math, see the Kimi K3 pricing breakdown.

When you should still use RAG

1M is big, but it’s not a silver bullet:

  • Knowledge base far larger than 1M (an entire company wiki, a million lines of code): you still need to retrieve before feeding, and RAG isn’t going away;
  • You only need a few relevant snippets: stuffing everything in is wasteful, you burn input tokens for nothing and latency goes up;
  • Heavy real-time / high concurrency: the longer the context, the slower and pricier each call, so trim it down for high-frequency scenarios.

Practical rule: if it fits in one pass and most of the content is relevant, just stuff it in; otherwise retrieve first, then hand the matched snippets to K3. The two approaches also stack, use RAG to narrow the scope to a few hundred thousand tokens, then let K3 answer in depth within that “large but relevant” context.

Things to watch out for

  • Longer means pricier and slower: 1M is a ceiling, not a target, use only what you need;
  • Exploit the cache: put the fixed prefix first, and always hit the cache for long docs / multi-turn;
  • Vision counts as context too: image / video tokens also eat your budget, so mind the total on long multimodal tasks;
  • Don’t keep only the content: in multi-turn / tool-calling flows, pass the full assistant message back verbatim, don’t drop the state.

For full integration code and error troubleshooting, see the Kimi K3 API tutorial. If you want to call K3 and other providers’ models with a single key and route long and short tasks by workload, the easiest place to start is the GetModel dashboard.