Kimi API 定价：缓存命中、缓存未命中、输出与速度

每个 Kimi 请求都按这三项计费

Kimi 不公布单一的输入价格。每个请求都按缓存命中输入、缓存未命中输入和输出三项计量，每一项都有各自官方的每百万 token 费率——缓存命中远低于未命中，输出最贵。apiToken.sale 按官方费率表逐项结算这些用量，然后在扣动你的预付费余额之前减去固定的 50% 折扣。

缓存本身由提供商侧自动完成；不需要你主动开启、标记断点或管理缓存条目。当请求重复了提供商已经见过的上下文时，匹配的前缀直接从缓存提供并按命中费率计量，其余都算未命中。由于提供商没有公布单独的缓存写入价格，所以不存在隐藏的第四项：新写入缓存的 token 在引入它的那次请求上按未命中计费，之后的请求则享受便宜的命中费率。

实际影响是：两次看起来完全相同的调用，费用可能相差很大，取决于提示词有多少命中缓存。每轮都重发一大段稳定系统提示词和文件上下文的 agent 循环，正是能吃满命中费率的流量——第一轮付未命中的钱，后面都搭缓存的便车。

推理 token 是输出的子集，不是独立的 token 类别。Kimi for Coding 和 High Speed 默认开启思考，模型推理过程产生的一切都按输出费率计费——绝不会在输出之上再叠加一次。

另见： Kimi K3 对比 Kimi for Coding：什么负载选哪个模型

每个公开别名背后的官方费率

以上数字均为每 1M token，从左到右依次是缓存命中输入、缓存未命中输入、输出。从表中能直接看出两个结构性事实。第一，Kimi for Coding 是 Kimi 已公布产品线中最低的通用编程费率。第二，High Speed 在每一项上都恰好是基础 Kimi for Coding 的两倍——你买的是延迟，不是另一个模型。

K3 一行覆盖了同一张费率表的三种写法。k3-256k 选择 K3 的 256K 上下文模式；k3 和 k3[1m] 选择 1M 模式，方括号写法是兼容拼写，路由器会将其归一化为提供商真实的 K3 线路模型。三种写法的每 token 费率完全相同，所以选择关乎上下文行为，而不是价格。千万不要发送 kimi-k2.7-code 这类开放平台内部资费 ID——路由器只接受 GET /v1/models 返回的公开订阅别名。

实战演算：一次编程会话，逐项拆解

以 kimi/kimi-for-coding 上一次典型的 agent 会话为例：稳定的系统提示词和仓库上下文在第一轮后进入缓存，每轮有少量新输入，回复保持精简。假设这次会话最终结算为 400,000 缓存命中 token、100,000 缓存未命中 token 和 20,000 输出 token：

这笔账里有两点值得记住。尽管输出 token 数量最少，却占了费用大头——输出 token 比缓存命中少二十倍，花费仍超过整个命中项。其次是缓存承担了大部分工作：同样 500,000 输入 token 若全部按未命中计费，官方费用将是 $0.475 而不是 $0.171。让昂贵的上下文在各轮之间保持稳定，是压低 Kimi 账单唯一最大的杠杆。

为任务选最便宜的别名

• 默认把编程和 agent 循环指向 kimi/kimi-for-coding——已公布产品线中最低的通用编程费率。
• 只有当延迟收益值得每一项都恰好两倍于基础费率时，才用 kimi/kimi-for-coding-highspeed；对时间不敏感的批量任务永远不值得。
• 任务不需要大上下文模式时用 kimi/k3-256k 而不是 1M 写法——每 token 价格相同，你选的是行为，不是折扣。
• 只有在 Kimi for Coding 确实搞不定的工作上才升级到 K3（官方 $0.30 / $3 / $15）：硬推理、长文档和长代码库任务。
• 给密钥设置终身消费上限，在仪表板查看已结算用量，而不是轻信月底估算。

结算、充值与余额如何运转

apiToken.sale 不改变上述任何计量方式。你的请求按 Kimi 自己的用量核算运行，每一项换算成官方提供商费用，然后才减去固定的 B2C 五折。净额从同一个预付费余额中扣除，该余额也按各自的官方费率表覆盖受支持的 Claude、GPT 和 Gemini 模型。没有订阅、没有按请求收取的费用，也没有最低消费。

你可以用银行卡或加密货币充值任意整数美元，余额永不过期。每个请求都会带着模型和 token 级明细出现在仪表板中，因此你可以把本指南里的算术逐行与自己的真实流量对账。余额归零时，请求会以余额不足的错误失败，直到你再次充值——密钥本身仍然有效。

在响应的 usage 对象中对账各项用量

这些数字完全不需要靠字符数估算。终态 usage 对象会报告每次调用实际消耗了多少，而且 Kimi 遵循 Anthropic Messages 的响应结构——缓存输入、新鲜输入和输出落在互不相交的桶里，可以直接乘上费率表：

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.

由于从提供商核算到你的仪表板账本，各项全程保持互斥，成本异常总有迹可循：缓存未命中突然上升，说明有人改动了原本稳定的前缀的中间部分；输出突然上升，说明模型开始更长时间地推理或回复。OpenAI 兼容客户端通过通用 /v1 通道访问同样的别名，结算方式完全相同。

各模型费率、缓存计费项与上下文窗口 →

常见问题

相关指南