Kimi K3 is already inexpensive for its capability at $3.00 / $15.00 per million tokens. Bills still get away from people, and almost always for the same reasons: the default effort level is the most expensive one, and repeated context is being paid for at full rate. Here are the four levers, ranked by how much they actually save.
1. Cache your stable prefix (up to 90% of input cost)
The largest lever by a wide margin. Cached input is $0.30 per million against $3.00 — put your system prompt, tool definitions, and documents at the front, keep them byte-identical, and vary only the tail.
Most cache failures are accidental: a timestamp near the top, documents assembled in a different order, or a per-user block above the shared context. See prompt caching for the full list and the fixes.
2. Set reasoning_effort explicitly (often 30–60%)
The default is max — the highest of the three levels. If you deployed without setting this parameter, you have been paying top rate on every request including the trivial ones.
Reasoning tokens bill as output at $15.00 per million, so this compounds. Set low for extraction and formatting, high for most real work, and reserve max for genuinely hard reasoning. See reasoning effort.
One caveat: on multi-step agent runs, higher effort sometimes lowers total cost by reducing turns and rework. Measure cost per completed task, not per request.
3. Constrain output (5x leverage per token)
Output bills at five times input on this model, and the default max_completion_tokens is a generous 131,072 tokens. Two fixes:
- Set an explicit ceiling that matches what your use case actually needs.
- Ask for concision. A word limit, or "return only the diff", is a direct discount. Long output is the most common avoidable cost in code-generation workloads.
4. Route by difficulty
Reasoning cannot be disabled on K3, which means there is a floor cost per request. For genuinely trivial high-volume work — short classifications, boilerplate transforms — a smaller non-reasoning model beats K3 on cost regardless of headline rates.
The pattern that works: cheap model by default, K3 on escalation, and an evaluation set deciding where the boundary sits. Most teams that get this right do not pick one model.
What not to do
- Don't trim context reflexively. Sending less material to save input tokens often costs more in extra turns and worse answers. Cache instead.
- Don't drop to
loweverywhere. On agentic work it can raise total cost by causing rework. - Don't self-host to save money unless you have modelled it honestly. At these rates the break-even volume is high.
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 do I reduce my Kimi K3 bill?
In order of impact: cache your stable prompt prefix for a 10x input discount, set `reasoning_effort` explicitly rather than inheriting the expensive `max` default, constrain output tokens since they bill at 5x input, and route trivial high-volume work to a cheaper model entirely.
What is the most expensive mistake with Kimi K3?
Leaving `reasoning_effort` unset. It defaults to `max`, the highest of three levels, and reasoning tokens bill as output at $15 per million. A workload that is mostly extraction and formatting can run at `low` for a fraction of the cost with no measurable quality change.
Is it cheaper to self-host Kimi K3 than use the API?
Only at high sustained volume. The weights carry no licence fee, but running 2.8 trillion parameters means ~1.4 TB of memory across a multi-node GPU cluster plus power and staff. Against $3/$15 per million tokens, the break-even volume is high enough that most teams should stay on the API.
