Kimi K3 Context Caching: How the Discount Actually Works

In one line: Kimi K3 supports prompt (context) caching — repeated input prefixes are billed at a discounted rate instead of the full $3 per million input tokens. Moonshot hasn't published the exact K3 cached price yet; the OpenRouter listing reports 60–80% cheaper effective input on cache-heavy workloads. For agentic loops that resend a large stable context every step, no other setting moves the bill as much — not even switching providers within the same tier. Capturing it takes some discipline; here's what actually works.

What caching does, mechanically

LLM APIs bill every input token on every request — even the 40K tokens of repository context you already sent thirty times this session. Context caching fixes the economics: the provider stores the processed prefix, and when your next request starts with the identical token sequence, the overlap bills at the cached rate and only the new suffix pays full price. That mechanism has two unforgiving implications:

1. Only prefixes cache. The match runs from token zero until the first difference. A timestamp or request ID at the top of your prompt destroys every cache hit; the same variable data at the bottom costs you nothing.
2. Verbatim means verbatim. Reordered tool definitions, a re-serialized JSON with different key order, or a trimmed whitespace all break the match. Serialize your stable context once and reuse the exact bytes.

Worked example: the coding-agent loop

Take our cost calculator's coding-agent preset — 40K input / 2.5K output per step, 300 steps a day, 22 working days, 5% retry overhead. At list price with zero caching that's about $1,091/month: roughly $832 of input and $260 of output. Now suppose 70% of the input is a stable repo-context prefix that hits cache, at an estimated 75%-off cached rate: the input bill drops to about $395 and the total to roughly $655/month — a 40% cut from one engineering decision. The output bill didn't move — caching never touches the $15/M side. If the official cached rate comes in cheaper (K2-era Moonshot caching was aggressive), the savings improve further; the cost calculator recomputes this live as you drag the cache-hit slider, and flags its cache math as estimated until Moonshot publishes the K3 number.

Structuring prompts for cache hits

The pattern that works: [system prompt] → [tool definitions] → [long stable context] → [conversation history] → [current turn]. Everything left of the history should be byte-stable across the session. Practical checklist:

• Pin your system prompt and tool schemas in code; never regenerate them per request.
• Append new conversation turns; don't rewrite or re-summarize earlier history mid-session (re-summarizing resets the prefix).
• Keep dynamic values — dates, user names, request IDs — in the final user message.
• Log prompt_tokens from responses and watch for cache-hit fields in the usage object; a hit rate under 50% on an agent loop usually means something upstream is mutating your prefix.

The one thing caching can't fix

At $15/M, one output token costs five input tokens — and output never gets discounted. A model that answers in 800 tokens instead of 1,300 saves you more per request than most caching setups. This is where K3's reported 21% output-token efficiency gain over K2.6 earns real money: fewer output tokens × the expensive meter × every single request. Measure your own prompts with the token calculator, then check the full rate table on the pricing page — we update it the day Moonshot publishes the official cached rate.