Kimi API pricing: cache hits, misses, output and speed

The three legs every Kimi request is billed on

Kimi does not publish a single input price. Every request is metered as cache-hit input, cache-miss input and output, and each leg carries its own official rate per million tokens — cache hits cost a fraction of misses, and output costs the most. apiToken.sale settles those exact legs against the official rate card, then subtracts a flat 50% discount before the charge touches your prepaid balance.

Caching itself is automatic on the provider side; you do not opt in, mark breakpoints or manage cache entries. When a request repeats context the provider has already seen, the matching prefix is served from cache and metered at the hit rate. Everything else is a miss. Because the provider publishes no separate cache-write price, there is no hidden fourth leg: a newly cached token is simply billed as a cache miss on the request that introduced it, and later requests collect the cheap hit rate.

The practical consequence: two identical-looking calls can cost very different amounts depending on how much of the prompt hits cache. Agent loops that resend a large stable system prompt and file context every turn are exactly the traffic that harvests hit rates — the first turn pays misses, the rest ride the cache.

Reasoning tokens are a subset of output, not a separate token class. Kimi for Coding and High Speed run with thinking enabled, and everything the model reasons through bills at the output rate — it is never added again on top of output.

See also: Kimi K3 vs Kimi for Coding: which model for which workload

Official rates behind each public alias

All figures are per 1M tokens, read left to right as cache-hit input, cache-miss input, output. Two structural facts fall out of the table. First, Kimi for Coding is the lowest general coding rate in the published Kimi set. Second, High Speed is exactly double the base Kimi for Coding rates on every leg — you are buying latency, not a different model.

The K3 row covers three spellings of one rate card. k3-256k selects K3's 256K context mode; k3 and k3[1m] select the 1M mode, and the bracket form is a compatibility spelling the router normalizes to the provider's real K3 wire model. Per-token rates are identical across all three, so the choice is about context behavior, not price. What you must not send is an internal Open Platform tariff ID such as kimi-k2.7-code — the router accepts only the public subscription aliases returned by GET /v1/models.

Worked example: one coding session, leg by leg

Take a typical agent session on kimi/kimi-for-coding: a stable system prompt and repository context that cache after the first turn, some fresh input each turn, and compact replies. Assume the session settles at 400,000 cache-hit tokens, 100,000 cache-miss tokens and 20,000 output tokens:

Two things are worth internalizing from the arithmetic. Output dominates despite being the smallest token count — twenty times fewer output tokens than cache hits still cost more than the entire hit leg. And the cache did most of the work: the same 500,000 input tokens billed entirely as misses would have cost $0.475 officially instead of $0.171. Keeping the expensive context stable across turns is the single biggest lever on a Kimi bill.

Choosing the cheapest alias for the job

• Default coding and agent loops to kimi/kimi-for-coding — the lowest general coding rate in the published set.
• Reach for kimi/kimi-for-coding-highspeed only when latency is worth exactly double the base rates on every leg; an idle-time-insensitive batch job never is.
• Use kimi/k3-256k instead of the 1M spelling when the task does not need the larger context mode — the per-token price is the same, so you are picking behavior, not a discount.
• Escalate to K3 ($0.30 / $3 / $15 official) only for work Kimi for Coding actually fails: hard reasoning or long-document and long-codebase tasks.
• Set a lifetime spending limit on the key and inspect settled usage in the dashboard instead of trusting end-of-month estimates.

How settlement, top-ups and the balance work

apiToken.sale changes nothing about the metering above. Your request runs against Kimi's own usage accounting, each leg is converted to official provider spend, and only then is the flat 50% B2C discount subtracted. The net amount draws from one prepaid balance that also covers supported Claude, GPT and Gemini models against their own official rate cards. There is no subscription, no per-request fee and no minimum spend.

You top up any whole-dollar amount by bank card or cryptocurrency, and the balance never expires. Every request appears in the dashboard with its model and token-level breakdown, so you can reconcile the arithmetic in this guide line by line against your real traffic. When the balance reaches zero, requests fail with an insufficient-balance error until you top up again — the key itself stays valid.

Reconcile the legs in the response usage object

You never have to estimate any of this from character counts. The terminal usage object reports what each call actually consumed, and Kimi follows the Anthropic Messages response shape — cached input, fresh input and output land in disjoint buckets you can multiply by the rate card directly:

curl https://router.apitoken.sale/v1/messages \
  -H "x-api-key: $APITOKEN_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi/kimi-for-coding","max_tokens":512,"messages":[{"role":"user","content":"Summarize this diff"}]}'

# The response carries terminal usage in the Anthropic shape:
# "usage": {
#   "input_tokens": 8420,
#   "cache_read_input_tokens": 38400,
#   "output_tokens": 512
# }
# cache_read_input_tokens bills at the hit rate ($0.19/1M),
# input_tokens at the miss rate ($0.95/1M),
# output_tokens at the output rate ($4/1M) — then 50% off the total.

Because the legs stay disjoint all the way from the provider's accounting to your dashboard ledger, a cost anomaly always has an address: a jump in cache misses means someone edited the middle of a previously stable prefix, and a jump in output means the model started reasoning or replying longer. OpenAI-compatible clients reach the same aliases through the universal /v1 lane and settle identically.

Per-model rates, cache legs and context windows →

Frequently asked questions

Related guides