Kimi K3 Prompt Templates (Long Context)

TL;DR: Kimi K3 is Moonshot AI's current flagship, with a 1,048,576-token context window that input and output share rather than budget separately. Context caching is automatic and prefix-based, and switching reasoning effort mid-conversation throws it away. Twenty templates below are built around those three facts.

What are Kimi prompt templates, and why does K3 change them?

Kimi prompt templates are reusable skeletons written against what Moonshot AI actually documents about its API, not against generic chat advice. The reason they differ from a ChatGPT template is narrow but consequential: on Kimi K3 you cannot tune sampling, the model always reasons, and the cheapest thing you can do with a long document is decide once where it sits in the request and then never move it.

Everything below was checked against Moonshot's own documentation on August 27, 2026. Model IDs and platform surfaces in this corner of the market move on the order of weeks, so re-verify before you build anything expensive on it.

Which Kimi model should you actually be prompting?

One of four, and none of them is called K2. Moonshot's model list records the kimi-k2 series as officially discontinued on May 25, 2026, and notes that following the K3 launch kimi-k2.5 and the moonshot-v1 series are "no longer available to newly registered users", with a full platform sunset on August 31.

There is a second staleness trap that has nothing to do with model names. The documentation host moved: platform.moonshot.ai now redirects to platform.kimi.ai. The API base URL did not move and is still https://api.moonshot.ai/v1. If a guide tells you the docs live on the Moonshot domain, it is describing a redirect; if it tells you the API does, it is right.

K3 is also open-weight, which matters if your long-document work cannot leave your own hardware. Moonshot describes it as "the world's first open 3T-class model", and the weights are published on Hugging Face under a bespoke licence named for the model rather than under MIT or Apache. That licence permits use, modification, distribution and sale, but adds two conditions worth reading before you build a business on it: a separate agreement is required if you run a model-as-a-service business above a revenue threshold, and prominent attribution is required above a user or revenue threshold. Read the actual text rather than my summary of it.

How big is Kimi K3's context window, and is output budgeted separately?

The window is 1,048,576 tokens, and no, output is not budgeted separately. Input and output share the same pool.

That figure is unusually well corroborated. It appears on the K3 quickstart page, in the K3 pricing table, in the model card on Hugging Face, and in the released config.json, where max_position_embeddings is set to 1048576. Four sources, one number.

The sharing is what most long-context writing skips. Kimi's concepts page states that "the total length of Input and Output cannot exceed the selected model's maximum context length", and the troubleshooting page gives the K3 formula explicitly: the maximum output length is 1024 times 1024 minus your prompt tokens. So a 900,000-token document does not leave you a fresh million tokens of answer. It leaves you roughly 148,000, and max_completion_tokens cannot rescue you past that ceiling.

Two practical consequences for a template:

1. Cap the answer in the prompt, not just in the parameter. max_completion_tokens defaults to 131,072 on K3 and can be raised to 1,048,576, but raising it does not create budget that the document already spent.
2. Know the truncation signal. When generation hits the cap, Kimi returns finish_reason of length and discards the extra content. Moonshot's documented recovery is Partial Mode: append an assistant message carrying the truncated prefix with partial set to true, and the model continues from it. That is a different failure shape from a model that stops before finishing the task for reasons of its own.

One more parameter fact that quietly rewrites every generic template: on K3, temperature, top_p, n, presence_penalty and frequency_penalty are all fixed and cannot be modified. Passing them returns an error. Whatever temperature advice you inherited from a 2024 prompt guide is not merely unhelpful here; it breaks the call.

Does Kimi have context caching, and what invalidates it?

Yes, it is automatic, and the answer to what invalidates it is more specific than the usual advice about keeping your prefix static.

Moonshot's caching page is unambiguous that there is nothing to configure: "Context caching is automatic for regular model requests; no cache ID, TTL, or extra parameter is required." It matches on the leading prefix, and the dynamic-tools page spells out the mechanism: "any change within the prefix invalidates the cache from that point onward."

Three specifics that a template can actually be designed around:

The 256-token floor. "A new request can hit the prefix cache only when the previous request's prompt tokens exceed 256." Below that, the request is not cached at all. Long-document work clears this trivially. Short-prompt work never benefits.

Reasoning effort is part of what the cache keys on. The parameter reference is blunt: "Switching levels invalidates prefix-cache hits." It advises deciding "before the conversation starts and avoid switching it mid-session." This is the trap most people will hit, because dialling effort up for a hard question mid-session feels like the obvious move and silently costs you the entire cached document.

Appending is safe; inserting is not. The dynamic tool loading guide states the rule as "Append, never insert". Adding a tool declaration at the end of messages leaves the prefix intact. Editing or inserting anything earlier invalidates everything after the change. Changing tool_choice "does not invalidate the prefix cache", and top-level tool declarations do not affect hits either.

It is worth noting how differently this behaves from the other well-known Chinese lab's caching. DeepSeek's model, covered in our DeepSeek prompt templates post, requires a request to fully match a persisted prefix unit, which means asking two different questions about the same document can miss twice before it starts hitting. Kimi's is closer to conventional prefix matching. Do not carry advice between them.

Where does the instruction go: above the document or below it?

This is the one question in long-context prompting where the major vendors openly contradict each other, and any guide that gives you a single confident answer is hiding that from you.

Anthropic's prompting best practices page tells you to "Place your long documents and inputs near the top of your prompt, above your query, instructions, and examples", and adds that "Queries at the end can improve response quality by up to 30 percent in tests, especially with complex, multidocument inputs."

OpenAI's current prompt engineering guide says the opposite about context: "This content is usually best positioned near the end of your prompt, as you may include different context for different generation requests." The section order it recommends for a developer message runs Identity, Instructions, Examples, Context, which puts the supporting document dead last. Note the stated reason, too. OpenAI is optimising for the variable part of your prompt being cheap to change, which is a caching argument dressed as a placement argument.

Moonshot lands with Anthropic on placement, for OpenAI's reason. Its file Q and A guide instructs you to "keep the fixed parts (file content, system prompt, tool definitions) stable and at the front of the messages array", and its multi-file example carries the comment "We recommend placing the messages returned by upload_files at the head of the messages list."

There is one internal wrinkle worth flagging, because you will notice it if you read both pages. The caching guide says to place fixed large contexts before the system message. The single-file cookbook example puts the persona system message first and the document second. Both are Moonshot's own pages, both are live, and neither acknowledges the other. Pick one, keep it identical across every request, and let the cached-token ratio tell you whether it worked.

Should you chunk a long document or send it in one pass?

Send it in one pass when you need cross-document reasoning, and chunk when you need coverage. The interesting part is that the vendor selling you a million-token window still documents the chunked approach.

Kimi's own prompt best practices page carries a section headed "Chunk and Recursively Build a Complete Summary for Long Documents", describing summarising each chapter, aggregating partial summaries, and repeating recursively. It adds a caveat that most map-reduce implementations get wrong: "If understanding later parts requires reference to earlier chapters, then when summarizing a specific point in the book, include summaries of the chapters preceding that point."

A workable decision rule:

• One pass when the answer depends on relationships between distant parts of the source: contradictions, timelines, cross-references, "what changed between version 3 and version 9".
• Chunk when the task is uniform coverage: extract every obligation, tag every clause, list every function. Recall degrades faster than reasoning does, and a chunk that fits comfortably is easier to verify.
• Chunk with carried summaries when both apply, which is most real work.

There is also a cost asymmetry. One pass over a stable document is the case Kimi's automatic caching was built for, and the cache-hit input rate on K3 is one tenth of the cache-miss rate on Moonshot's published pricing table. Chunking splits your document into many prefixes, most of which are used once. If you are asking one question, chunk freely. If you are asking fifty, one stable prefix is dramatically cheaper.

How do you make Kimi cite back into a long source?

Ask for the quote before the claim, and constrain the shape of the output. Moonshot demonstrates this directly rather than leaving it to inference: its PDF cookbook adds a response rule requiring "One sentence per point, each with the corresponding quote from the document as evidence", runs the same question with and without it, and shows the constrained version producing a quote per bullet at roughly a third of the length.

Anthropic reaches the same place from the other direction, advising you to "ask Claude to quote relevant parts of the documents first before carrying out its task" so the model focuses on relevant content and ignores the rest. Two vendors, same craft move, and it survives being carried between them.

Three things make citations verifiable rather than decorative:

1. Require a verbatim span, not a paraphrase. A paraphrase you cannot grep is not a citation.
2. Require a locator — section heading, page marker, or the first six words of the paragraph. Kimi's file extraction returns the document with its structure intact, so headings are usually available.
3. Require an explicit not-found token. Moonshot's own reference-text example instructs the model to write that it cannot find the answer when the article does not contain it. Without that escape hatch, an absent fact becomes an invented one. Our post on summarising 50 papers without losing citations works the same pattern at corpus scale.

How do you test whether the model actually read the middle?

Put something in the middle that only reading it would reveal, then ask for it. This takes about ten minutes and is worth doing once per document class, not once per prompt.

The honest position is that Moonshot does not publish a needle-in-a-haystack curve for K3, or any documented statement about degradation at particular depths. What it does publish is suggestive: on the BrowseComp agentic benchmark, its own results note says the team used a context-compaction strategy triggered at 300,000 tokens, and reports a separate score for running with the full window and no context management. A lab that ships a million-token window still reached for compaction at 300K in its own evaluation. Treat that as a hint about where to start testing, not as a published limit.

The K3 launch post also lists two limitations that bear directly on long sessions. On thinking history: if a harness fails to pass back the historical thinking content, or a session started on another model is switched to K3, "generation quality may become highly unstable". On autonomy: because training emphasised long-horizon tasks, when the model meets ambiguity "it may make unexpected decisions on the user's behalf", and the recommended fix is more explicit behavioural constraints in the system prompt. Both are arguments for pinning your instruction text and never editing it mid-run.

20 Kimi K3 prompt templates for long-context work

Square-bracket slots are meant to be replaced. Every template assumes the document is already in the request as a system message at the head of messages, per the placement section above, and that the instruction and question follow it.

Document setup and framing

1. Long-document analyst frame

You are analysing a single source document supplied above. Work only from that
document. Every factual claim in your answer must be traceable to a verbatim
span in it. If the document does not contain the answer, write exactly:
NOT IN SOURCE.

Task: [WHAT YOU WANT]
Audience: [WHO READS THE ANSWER]
Length: at most [N] bullet points, one sentence each.

2. Multi-document frame with sources

You have been given [N] documents above, each in its own system message, in this
order: [DOC 1 NAME], [DOC 2 NAME], [DOC 3 NAME].

For every claim, name the document it came from before the claim, in the form
[DOC NAME]: claim. Do not merge facts from two documents into one sentence
without naming both.

Task: [WHAT YOU WANT]

3. Stable instruction block (cache-safe)

RESPONSE RULES (these do not change between questions):
1. Answer only from the supplied document.
2. Maximum [N] bullet points; one sentence per point.
3. Each point ends with a verbatim quote of 8-25 words as evidence.
4. Maximum [N] words total.
5. If the answer is absent, output NOT IN SOURCE and nothing else.

4. Structural map first

Before answering anything, produce a structural map of the document above:
every top-level heading, in order, with a one-line description and the
approximate percentage depth at which it starts. Output as a numbered list.
Do not summarise the content yet.

5. Scope fence for an ambiguous request

Scope: [EXPLICIT IN-SCOPE LIST].
Out of scope: [EXPLICIT OUT-OF-SCOPE LIST].
If a request appears to fall outside scope, stop and say which part is out of
scope rather than deciding on my behalf. Do not make substitutions, do not
expand the task, do not add sections I did not ask for.

Cache-friendly request shapes

6. Fixed prefix, varying tail

[SYSTEM 1: full document text — never edited]
[SYSTEM 2: response rules — never edited]
[USER: the only part that changes]

Question: [YOUR QUESTION]

7. Batched question list against one prefix

Answer each of the following questions independently against the document above.
Do not merge them. Number your answers to match.

1. [QUESTION]
2. [QUESTION]
3. [QUESTION]

For each: at most three sentences, plus one verbatim quote as evidence.

8. Cache-hit self-report

[Send an identical request twice. On the second, read
usage.prompt_tokens_details.cached_tokens from the response and divide by
usage.prompt_tokens. Below roughly 90 percent on an unchanged prefix, something
in your prefix is not byte-identical between the two calls.]

9. Session opening contract

Session settings, fixed for this entire conversation:
- Reasoning effort: [low | high | max] — will not change mid-session.
- Output ceiling: [N] words.
- Citation style: verbatim quote plus section heading.
- Absent-fact token: NOT IN SOURCE.
Confirm you have these, in one line, then wait for my first question.

Citation and grounding

10. Quote-then-claim

For each finding, output in this exact order:
QUOTE: "[verbatim span, 10-30 words, copied exactly from the document]"
LOCATION: [nearest heading, or first six words of the paragraph]
CLAIM: [one sentence of your own, supported by that quote]

Do not output a CLAIM without a QUOTE above it.

11. Evidence table

Produce a markdown table with these columns: Claim | Verbatim quote | Section |
Confidence (High/Medium/Low). One row per claim. Maximum [N] rows. Confidence
is Low if the quote only partially supports the claim; say so rather than
picking a stronger quote.

12. Contradiction hunt across sources

Compare [DOC A] and [DOC B] above. List only statements where the two documents
disagree on a checkable fact. For each disagreement, give the verbatim sentence
from each document and name which one is more recent if either is dated. Do not
resolve the disagreement. If there are none, say so.

Reading-depth tests

13. Sentinel recall probe

Three sentinel markers have been placed in the document above. Each begins with
the string SENTINEL-. Find all three, quote each verbatim, and state the
heading each one appears under. If you find fewer than three, say how many you
found rather than guessing at the rest.

14. Positional spread check

List the first substantive sentence of the document, the first substantive
sentence of the section closest to the halfway point, and the last substantive
sentence. Quote all three verbatim. Then state, in one line, how many
top-level sections lie between the first and second.

15. Cross-reference resolution

The document above refers to [TERM] in more than one place. Find every
occurrence, quote each in context, and state whether the meaning is consistent
across occurrences. If it is not, name the sections where it differs.

Chunking and map-reduce

16. Chunk summariser with carried context

You are summarising chunk [N] of [TOTAL] from a longer document.

Summary of all preceding chunks:
[ROLLING SUMMARY, OR "None — this is the first chunk."]

Chunk [N] text:
[CHUNK]

Output: at most [N] bullet points covering only new information in this chunk,
plus one line headed CARRY FORWARD listing anything a later chunk will need.

17. Reduce step

Below are [N] chunk summaries from one document, in order. Merge them into a
single summary of at most [N] words. Where two chunks make the same point, state
it once. Where they conflict, keep both and mark the conflict. Preserve the
original order of events.

18. Coverage audit after chunking

Here is the source document and here is a summary produced from it in chunks.
List anything present in the source and absent from the summary that a
[ROLE] would consider material. Output as a plain list of omissions with a
verbatim quote each. If nothing material is missing, say so in one line.

Codebase and agent runs

19. Whole-repository orientation

The files above are a complete [LANGUAGE] repository. Before changing anything:
1. Name the entry point and justify it with a quoted line.
2. List the top [N] modules by apparent responsibility, one line each.
3. Name every external dependency you can see and where it is used.
4. List the three things you are least sure about.
Do not propose changes yet.

20. Long-horizon run guardrails

Constraints for this task, which override any inference you make later:
- Do not modify files outside [PATHS].
- Do not add dependencies. If one seems required, stop and ask.
- If an instruction is ambiguous, stop and ask rather than choosing.
- Report after every [N] steps with: what changed, what is left, what surprised you.
Task: [TASK]

Where a template layer actually earns its keep

Long-context work is the case where reusable templates with variable slots pay for themselves fastest, and the reason is mechanical rather than aesthetic. Kimi's cache keys on your prefix being byte-identical between requests. A prompt you retype is a prompt you will accidentally reword, and a reworded prefix is a cache miss on a document that may be hundreds of thousands of tokens long.

That is what we build: Prompt Architects generates the prompt and stores it with named variable slots, so the fixed part stays fixed and only the tail changes. Kimi is one of the platforms our extension supports natively, with long-context optimization as its listed specialization, and the library and global variables are model-agnostic, so the same skeleton works when you move a job to Claude or ChatGPT. What we are not is the model, the API, or a caching layer. The window, the pricing and the cache behaviour are Moonshot's, and the templates above only help you use them deliberately.

Start with templates 1, 3 and 8. The first two fix your prefix; the third tells you whether it stayed fixed. Everything else in this post is downstream of that. And if you are still deciding how much structure a prompt needs before it stops being worth writing, our guide to how long a prompt should be is the right place to start, followed by using XML tags to delimit sections, which transfers to Kimi unchanged.