Kimi API uses usage-based billing and does not offer a subscription plan. Comparing providers only on "price per million tokens" is an easy way to choose wrong: what actually determines the bill is the model, the context length, the cache hit rate, and the output length. The K2 series offers a 262,144-token context, and K3 extends that to 1,048,576. That long-context capability is impressive, but it also means input-side costs can accumulate quickly.

This article breaks down the K2 series billing structure, where long-context costs come from, a reproducible way to measure them, and the order in which to reduce costs. It deliberately avoids fixed unit prices. For actual prices, refer to the official documentation and the model pricing page.

Note: Moonshot and Kimi are trademarks of their respective owners. Model names, context lengths, and billing rules may change. This article reflects common conditions as of October 2026; verify the official pages before purchasing.

1. How the K2 Series Divides the Work

Model Role Context Best for Cost focus
kimi-k2.6 General purpose 262,144 Chat, extraction, customer support, document processing Cache hit rate
kimi-k2.7-code Code 262,144 Code generation, repository Q&A, agents Long inputs, many tool results
kimi-k2.7-code-highspeed High-speed code 262,144 Low-latency completion, interactive coding Balance between unit price and throughput
kimi-k3 New generation 1,048,576 Very long documents, complex multi-step tasks Long context and cache writes

Models iterate, and new versions may be added to the K2 series. Use the official model list and the model pricing page when purchasing, and do not treat the model names here as a permanent commitment.

There is no need to default to the largest context for general tasks. Stuffing an entire corpus into a 1M-token context makes input costs accumulate rapidly with every turn; narrowing the scope with retrieval first and letting the model read the key passages is usually more economical. Code tasks are the opposite: repository structure and tool returns often must be preserved, so the priority is a stable prefix and a higher cache hit rate.

2. Three Components Make Up the Bill

K2 series billing has three line items: cache-miss input, cache-hit input, and output. K3 also prices cache writes separately across 5-minute and 1-hour TTL tiers, so you cannot simply multiply total tokens by one average rate.

Billing item When it occurs Cost impact Control
Cache-miss input Prompts, documents, and tool results seen for the first time Grows linearly with context Retrieval, summaries, trimming history
Cache-hit input Repeated system prompts and fixed prefixes Usually well below the miss rate Stable prefixes, fixed tool ordering
Output tokens Content and reasoning generated by the model Long outputs amplify the bill Cap max_completion_tokens
Cache writes (K3) Writing a prefix into the cache Priced by TTL tier Cache only stable, reused content

Breaking a single request apart, the cost formula is:

Cost per request =
  cache-miss input tokens × miss rate
+ cache-hit input tokens × hit rate
+ output tokens × output rate

K3 adds a cache-write line. The usage object in the response reports prompt_tokens, completion_tokens, and prompt_tokens_details; cache hits and cache writes are both counted inside prompt_tokens, so the uncached portion is the total minus those two.

3. Why Long Context Gets Expensive

Scenario Typical token structure Main cost driver Optimization direction
Long-document Q&A Large input, moderate output The document resent on every call Retrieval plus caching
Code repository agent Large input and output Tool results and history Summaries, trimming, caching
Multi-turn support Input grows with each turn Repeated message history Rolling summaries
Batch extraction Moderate input, short output Repeated document reads Batch processing plus smaller models

The differences usually come from five places:

  1. Input accumulates with each turn. Resending the full text every turn roughly multiplies the bill by the number of turns.
  2. Cache hit rate. A stable prefix can be reused; timestamps, random IDs, and dynamic ordering that change on every request invalidate the cache.
  3. Tool output. A single search or code execution can return a long log, and carrying it back verbatim in the next turn compounds the cost.
  4. Output length. Open-ended requests for "detailed analysis" tend to produce long outputs, and output usually costs more than cache-hit input.
  5. Model mismatch. Using a large model for simple classification, or repeatedly retrying an unsuitable model for a complex task, both inflate cost.

4. Run a Reproducible Measurement

  1. Select 20–50 real tasks spanning simple, medium, and complex cases, and write down the acceptance criteria.
  2. Quantify input with a token-counting endpoint; do not guess from character counts.
  3. Run the same batch through kimi-k2.6 and the code models, recording quality, latency, and rework count.
  4. Read input, output, cache hits, and cache writes from the response usage.
  5. Compare cost per completed, acceptable task rather than the list price per million tokens.
  6. Include retries, failed requests, and cache writes in the per-task cost.
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MOONSHOT_API_KEY"],
    base_url="https://api.moonshot.cn/v1",
)

resp = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[{"role": "user", "content": "Extract this contract into JSON: ..."}],
    max_completion_tokens=1024,
)

u = resp.usage
print("input", u.prompt_tokens, "output", u.completion_tokens)
print("cache details", getattr(u, "prompt_tokens_details", None))

Streaming calls need stream_options={"include_usage": True}; the complete usage is returned only in the final chunk. Multiply by the actual rates from your contract or the pricing page, and do not reuse a screenshot from several months ago.

5. The Order for Cutting Costs

  1. Start with caching. Fix the system prompt, tool definitions, and knowledge-base prefix, and use cached_tokens to verify that hits are actually happening.
  2. Then reduce input. Retrieve only the relevant passages, summarize history, and stop stuffing an entire corpus into the context.
  3. Cap output. Set a reasonable max_completion_tokens, and require JSON or fixed fields to cut filler.
  4. Route by model. Use kimi-k2.6 for general tasks, a K2.7 code model for code tasks, and consider K3 only for very long material.
  5. Move long requests to streaming. Streaming does not change the unit price directly, but it reduces retries caused by timeouts and dropped connections.
  6. Monitor and alert. Track usage by project, model, and scenario, set budget caps, and review the top spenders weekly.

Do not reverse the order. Fix caching and input governance first, then consider switching to a cheaper model; otherwise you are only making wrong answers cheaper.

6. Managing Budgets and Bills

  • One key per project, with a daily budget per project, so a single workload cannot consume the entire allowance.
  • Reconcile monthly across three dimensions — project, model, and scenario — and identify the fastest-growing calls.
  • Record cache hit rate, retry count, and average output length separately; otherwise you cannot prove that an optimization worked.
  • Teams that need RMB payment and invoices can consolidate multi-model billing through a domestic AI gateway; for specific prices and invoice rules, see model pricing.

FAQ

Is K2 or K3 more cost-effective?

It depends on the task. The K2 series offers a 262,144-token context, which covers most document and code scenarios; K3 has a larger context and suits very long material. Compare total cost per completed, acceptable task rather than unit price alone.

How much can caching save?

It depends on prefix reuse and hit rate. Cache-hit input is usually well below cache-miss input, and a hit also extends the cache's lifetime; but if the prefix changes every time, or the prefix is too short, there will be no hit.

Does streaming make output cheaper?

It does not change the unit price directly. Its value is reducing the hidden cost of timeouts, dropped connections, and retries on long requests.

Why is the bill higher than my estimate?

Common omissions include message history, tool returns, full document text, retries, long outputs, and cache misses. Reconcile request logs against usage to locate the difference.

How can teams in China settle in RMB?

You can call Kimi through an AI gateway that offers RMB top-ups and invoices, consolidating multi-model billing. Available models, prices, and invoice rules follow the model pricing page.

Next Steps

Start by creating a test key on the ZSQH AI Gateway, run one batch of real tasks through kimi-k2.6 and a code model, and record tokens, cache hits, and quality before choosing a primary model. Model availability and prices follow the model pricing page.

Related reading: