Cached input on Kimi K3 costs $0.30 per million tokens against a standard rate of $3.00 — a 10x discount, applied automatically. Automatic does not mean effortless: you get it by structuring your prompt so the front stays identical between calls, and most people accidentally break that on the first attempt.
How it works
| Cache miss | $3.00 per 1M input tokens |
| Cache hit | $0.30 per 1M input tokens |
| Configuration | Automatic — no cache_control markers required |
| What gets cached | The matching prefix of your prompt |
The key word is prefix. Caching matches from the start of the prompt forward, and stops at the first byte that differs. Everything after that point bills at full rate.
The one structural rule
Stable content first, variable content last. That is the whole technique.
[ system prompt ] ← stable
[ tool definitions ] ← stable
[ documents / codebase ] ← stable
[ conversation history ] ← grows, but append-only
[ the current question ] ← varies
Append-only history caches well, because each new turn extends a prefix that already matched. History you rewrite or re-summarise does not.
Four ways people break the cache
Each of these silently costs you 10x on input:
- A timestamp in the system prompt. "Current time: 14:32:07" changes every call and invalidates everything after it. Put dynamic values at the end.
- Reordered content. Documents assembled from an unordered set, or tool definitions built from a dictionary, land in a different order each time. Sort them.
- Rewriting history. Summarising or editing earlier turns changes the prefix. Append instead.
- Per-user injection at the top. A user ID or personalisation block at the front gives every user their own cache. Move it below the shared material.
What this is worth
Concretely, for a 200,000-token codebase or corpus you query repeatedly:
| Requests | Uncached | Cached |
|---|---|---|
| 1 | $0.60 | $0.60 |
| 10 | $6.00 | $1.14 |
| 100 | $60.00 | $6.54 |
Input-side only, at published rates. This is why the caching discount, not the window size, is the thing that makes long-context work on K3 economically interesting — and why verifying your cache-hit rate in your usage figures is worth doing before you scale anything.
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
Does Kimi K3 support prompt caching?
Yes, and it is automatic — no `cache_control` markers to add. Cached input costs $0.30 per million tokens against a $3.00 standard rate, a 10x discount. Caching matches your prompt prefix and stops at the first byte that differs.
How do I make sure my Kimi K3 prompts hit cache?
Put stable content first and variable content last: system prompt, tool definitions, and documents at the front; the current question at the end. Avoid timestamps near the top, sort anything assembled from an unordered collection, and append to conversation history rather than rewriting it.
How much can prompt caching save?
Up to 90% of input cost on repeated context. For a 200,000-token corpus queried 100 times, input cost falls from roughly $60 to under $7 at published rates. It is the single largest cost lever on this model.
