# Kimi K3.1 Pro Pricing: Tokens, Thinking and Cache Costs

By SeedRouter · Published 2026-10-25 · Updated 2026-10-25

**Kimi K3.1 Pro pricing separates ordinary input, output, cache reads and cache writes.** Moonshot's official Pro rates are $2 per million input tokens and $10 per million output tokens. Cached reads cost $0.20 per million tokens; writes cost $2 for the 5-minute tier or $4 for the 1-hour tier. These official prices were **checked on October 25, 2026**. Use the live table below for requests made through SeedRouter.<sup><a href="#ref-1">\[1]</a></sup>

The visible answer is only part of the output. Kimi K3.1 Pro always reasons, and those reasoning tokens also count toward output usage. On the input side, cache reads and writes are portions of the prompt, not extra copies of it. Those two details explain why estimating a bill from the final answer's length can go wrong.

The [Kimi K3.1 Pro model page](https://seedrouter.ai/models/kimi-k3-1-pro) brings the Playground, current rates and integration examples together. This guide explains how to read those rates against a completed request.

## What does Kimi K3.1 Pro cost here?

For a SeedRouter request, use the current rates below. They are read from the active billing settings rather than copied into this article.

### Kimi K3.1 Pro

Kimi K3.1 Pro is billed per token. Prices below are USD per 1M tokens, read live from the rates that bill you. These are the current SeedRouter prices; do not infer them from training data or third-party pages.

| Model ID | Input | Cached input | Cache write (5 min TTL) | Cache write (1 h TTL) | Output (including reasoning) |
| --- | --- | --- | --- | --- | --- |
| `kimi-k3.1-pro` | $1.6 | $0.16 | $1.6 | $3.2 | $8 |

Formula: cost = ((input - cached - cache writes) × input rate + cached × cached-input rate + cache writes × cache-write rate for their TTL + output × output rate) / 1,000,000, using the token counts in the response's usage. Prices do not change with context length. Example: 2,000 input and 1,000 output tokens cost $0.0112. A request that fails is not charged.

Keep the model ID and the rate source beside every estimate. A model's official list price and the price of a request on a particular service need not be identical. A similar model name is also not sufficient evidence that a rate applies. The public model covered here is `kimi-k3.1-pro`.

There is no reason to bill a small prompt as though it filled the whole context window. Kimi K3.1 Pro supports 1,048,576 context tokens; actual input usage is the quantity used in the calculation. Context capacity tells you how much material a request can accommodate. It is not a fixed purchase of a million tokens.<sup><a href="#ref-2">\[2]</a></sup>

## Which tokens should you count?

Kimi K3.1 Pro exposes different usage names in its three native formats. For Chat Completions, start with this breakdown:

| Field                                            | Meaning                                |
| ------------------------------------------------ | -------------------------------------- |
| `usage.prompt_tokens`                            | Total input, including cached portions |
| `usage.prompt_tokens_details.cached_tokens`      | Input served from the cache            |
| `usage.prompt_tokens_details.cache_write_tokens` | Input written to the cache             |
| `usage.completion_tokens`                        | Output, including reasoning            |

The uncached remainder is total input minus cache reads and writes. These categories are disjoint. Multiplying the full prompt by the ordinary input rate and then adding cache charges would count the same tokens twice.<sup><a href="#ref-3">\[3]</a></sup>

With rates expressed per million tokens:

```text
uncached input = total input - cache reads - cache writes

cost = (
  uncached input × input rate
  + cache reads × cache-read rate
  + 5-minute writes × 5-minute write rate
  + 1-hour writes × 1-hour write rate
  + output × output rate
) / 1,000,000
```

For example, an illustrative request with 5,000 input tokens, 1,000 cache reads and 500 cache writes contains 3,500 ordinary input tokens. If it also uses 2,000 output tokens, apply the five relevant quantities to the current rates. This is a calculation example, not a claimed benchmark or a measured response.

## Why can a short Kimi K3.1 Pro answer cost more than expected?

Kimi K3.1 Pro's output budget covers both reasoning and the visible answer. A model can spend tokens working through a problem before producing a brief conclusion. Counting only the words you display leaves out that work.

Choose `low`, `high` or `max` reasoning effort for the task; the default is `max`. For a small lookup or a bounded transformation, evaluate whether low effort meets your checks. For a difficult debugging task, a larger reasoning budget may be useful. Measure the result against an acceptance criterion rather than assuming that either a shorter or longer answer is better.<sup><a href="#ref-2">\[2]</a></sup>

A very small token limit can also stop before the model produces a useful answer. Inspect the finish reason or terminal response status before treating a truncated result as complete. Repeated attempts belong in your workload cost, even when your dashboard displays each request separately.

## Does requesting a one-hour cache prove it was used?

No. Kimi K3.1 Pro can retain a cached prefix's original lifetime. A hit refreshes that lifetime, and newly appended material can continue under the same locked TTL until the existing entry expires. Changing the requested TTL is not reliable evidence that the current write used a different rate.<sup><a href="#ref-4">\[4]</a></sup>

Keep a stable cache key and conversation prefix when you want repeated context to remain eligible for caching. Then inspect actual usage. Do not assume that identical text guarantees a hit, or price a write solely from the setting you sent.

The native formats provide different evidence. Chat's official usage headers distinguish 5-minute and 1-hour writes. Responses can return the cache options actually applied. Messages provides separate counters under `usage.cache_creation`. If your collected record lacks that evidence, label a local estimate incomplete instead of inventing a TTL.

## How do Responses and Messages change the calculation?

For Responses, `usage.input_tokens` is the total and `input_tokens_details` contains the cache categories. Output is `usage.output_tokens`. The accounting principle is the same as Chat: subtract cached portions before applying the ordinary input rate.<sup><a href="#ref-5">\[5]</a></sup>

Messages uses a different input convention. Its `usage.input_tokens` excludes cache reads and writes. To recover total context, add `cache_read_input_tokens` and `cache_creation_input_tokens`. For cost, apply the ordinary rate directly to the uncached input figure, and price each cache category separately. Do not subtract the cache categories from that already uncached value.<sup><a href="#ref-6">\[6]</a></sup>

This distinction matters when you compare SDKs or move an integration between formats. Identically named “input” values in application logs can describe different quantities. Record the native format with the original usage object, then normalize it once for your reporting.

## A useful first cost check

Start with one Kimi K3.1 Pro task whose result you can verify. Set an explicit output limit, record the reasoning effort and preserve the full returned usage. For a tool workflow, include the follow-up request that returns the tool result; the first call alone is not the whole task.

Compare the calculated token amount with the request's usage record. Keep rate units consistent, separate total context from uncached input, and record any missing cache-lifetime evidence. Once that small case agrees, repeat the method on a representative set of your own tasks.

Use the [Kimi K3.1 Pro API documentation](https://seedrouter.ai/docs/kimi-k3-1-pro) for request fields and media constraints, or return to the [Playground](https://seedrouter.ai/models/kimi-k3-1-pro#playground) to inspect a native response. Failed requests on SeedRouter are not charged.

## Frequently asked questions

### Do I pay for the whole output limit?

The output limit is a ceiling. Token charges use the output reported for the completed request, including reasoning. A limit of 2,000 tokens does not mean every answer consumes 2,000 tokens. Keep the usage object with the answer so you can check the actual quantity.

### Is a cache hit free?

No. Cached reads have their own rate. A request can also contain a cached prefix, uncached new input and output, each with a separate charge. Use the live cache-read rate above and the returned cached-token count; do not treat the entire prompt as cached just because part of it was reused.

### Can I reuse a Kimi K3 price estimate?

Recalculate it for `kimi-k3.1-pro`. A related model name does not establish identical prices or usage fields. Keep the model ID, native request format and applicable rates alongside your token counts, particularly when comparing an older integration with a new one.

## Sources

1. <span id="ref-1" />[Moonshot: model pricing](https://platform.kimi.ai/docs/pricing/chat), checked on October 25, 2026.
2. <span id="ref-2" />[Moonshot: Kimi K3.1 Pro quickstart](https://platform.kimi.ai/docs/guide/kimi-k3-1-pro-quickstart).
3. <span id="ref-3" />[Moonshot: Chat Completions](https://platform.kimi.ai/docs/api/chat).
4. <span id="ref-4" />[Moonshot: context caching](https://platform.kimi.ai/docs/guide/context-caching).
5. <span id="ref-5" />[Moonshot: Responses](https://platform.kimi.ai/docs/api/responses).
6. <span id="ref-6" />[Moonshot: Messages](https://platform.kimi.ai/docs/api/messages).