Kimi K2.6 API Key 与价格：已补充 K2.7 Code

Kimi K2.6 API Key 与价格：官方费用、速率限制与 K2.7 Code

如果你正准备注册一个 Kimi API Key 来运行 K2.6，那么 token 单价只是成本的一部分。缓存、速率限制等级、工具费用，以及 agent 式重试，都会悄悄决定你每个月的账单。这篇指南会逐项拆开说明，并使用 Kimi 当前在平台页面上公开的数字。

2026 年 6 月更新： Kimi 平台现在已列出 K2.7 Code，并将其定位为更强的代码模型。K2.6 对既有集成和通用多模态 agent 仍有价值，但新的 coding-agent 评估应该把 K2.7 Code 纳入。

Kimi K2.6 API 定价面板插图，展示 token 价格档位、速率限制仪表以及 Moonshot 风格开发者控制台视觉

快速结论

Kimi K2.6 使用 Moonshot 的 OpenAI 兼容 API，地址为 https://api.moonshot.ai/v1，任何 OpenAI SDK 都可以直接替换使用。
Kimi 平台页当前展示的全球价格：
- K2.6： cache hit $0.16 / MTok，input $0.95 / MTok，output $4.00 / MTok
- K2.7 Code： cache hit $0.19 / MTok，input $0.95 / MTok，output $4.00 / MTok
- K2.6 上下文窗口：262,144 tokens
你可以在 platform.moonshot.ai 注册账号后，在控制台中创建 API Key。
网页搜索等工具费用可能单独计费；生产预算前请核对当前 tools pricing 页面。
速率限制按 tier 和账号状态变化，具体 RPM/并发/TPM 请以控制台当前限额页为准。

下面我们会逐项展开，并说明这些数字背后的坑点。

如何创建 Kimi API Key

流程和大多数 LLM 提供商差不多：

打开 platform.moonshot.ai 并登录或注册。
如果系统要求，先完成账号验证。
打开控制台中的 API keys 页面，点击 Create API key。
立刻复制这个 key，它只会显示一次。
可选但强烈建议：在跑任何 workload 之前，就设置预算上限和余额不足提醒。

把这个 key 当作密码来对待：应该放进环境变量或 secret manager，而不是写进源码文件里。如果泄露了，就在同一个控制台页面里立刻轮换。

对于新账号，有一点非常值得注意：Moonshot 采用 tier 式速率限制，具体额度会受账号状态、充值历史和当前平台政策影响。一个全新账号通常限制较紧，只适合少量测试请求，不适合常驻的 coding agent。在你开始做 benchmark 之前，最好先看完下面的速率限制部分。

Kimi K2.6 官方价格

Kimi 全球价格页当前公布的数字如下：

Model	Cache hit	Input	Output	说明
Kimi K2.6	$0.16 / MTok	$0.95 / MTok	$4.00 / MTok	Kimi 当前展示的 K2.6 价格
Kimi K2.7 Code	$0.19 / MTok	$0.95 / MTok	$4.00 / MTok	更新的代码模型选项

这里有两点特别重要。第一，Kimi 全球平台现在以 美元 / 百万 token（MTok） 展示这些价格；如果你的账号走中国区/人民币控制台，请以本地账单页为准。第二，cache hit 输入明显低于普通输入。这一项几乎决定了长上下文和 agent 工作负载的经济性。

“cached input” 和 “uncached input” 是什么意思

Moonshot 和大多数前沿模型厂商一样，提供了 上下文缓存（context caching）：当你 prompt 中的一部分在近期已经出现过时，服务器可以跳过前缀的重复计算，并以更低的价格收费。

具体来说：

缓存命中（cached input）：你之前已经发送过的前缀（system prompt、历史对话、大段文档上下文）与服务端缓存中的内容匹配，此时按缓存价收费。
缓存未命中（uncached input）：新的 prompt 内容、顺序发生变化，或原本的前缀已从缓存中失效，这时按完整未缓存价格收费。

为什么这在真实工作流里很关键：

长上下文 RAG：如果你把 100K token 的知识库塞进 system prompt 并反复复用，缓存会把原本很痛的账单压到可接受范围。
Agent 循环：每一步工具调用型 agent 通常都会重新发送 system prompt、工具 schema 和对话历史。没有缓存时，每一步都按 uncached 计费；有缓存时，只有新追加的工具结果和 assistant 回复按高价计费。
相同 prompt、不同用户：如果两个用户命中了同一套 system prompt，第二个用户会吃到缓存收益。

实用建议是：把 稳定、可复用 的部分（指令、长文档、工具定义）放在前面，把用户特定、会变化的部分放在后面。这样能最大化缓存命中率，并把输入成本压低 5 倍甚至更多。

OpenAI 兼容请求格式

Moonshot 的 API 与 OpenAI 兼容，这意味着任何 OpenAI SDK 都可以通过更换 base URL 和 API key 来使用。

curl

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k2.6",
    "messages": [
      {"role": "user", "content": "Explain caching in one paragraph."}
    ]
  }'

Python（OpenAI SDK）

from openai import OpenAI

client = OpenAI(
    api_key="your-moonshot-api-key",
    base_url="https://api.moonshot.ai/v1",
)

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[
        {"role": "user", "content": "Write a Python function to debounce calls."}
    ],
)
print(response.choices[0].message.content)

Thinking 模式与 Instant 模式

K2.6 默认启用 Thinking 模式。如果你想强制使用 Instant 模式（不生成 reasoning tokens），可以这样传：

response = client.chat.completions.create(
    model="kimi-k2.6",
    messages=[...],
    extra_body={"thinking": {"type": "disabled"}},
)

Thinking 模式会生成需要按输出收费的 reasoning tokens。如果任务不需要它，关闭就是最直接的省钱方式。

多模态输入

K2.6 是原生多模态模型，支持文本、图像和视频输入。图像可以直接通过标准 OpenAI image_url 内容块传入。视频输入在官方 API 上可用，但 Moonshot 把第三方部署中的视频支持标记为实验性功能。如果你的产品依赖它，请务必做完整链路测试。

速率限制与账号层级

Moonshot 对账号应用按层级区分的速率限制。层级与账号状态、充值历史和当前平台政策有关，具体数字会随时间变化。

在估算 workload 之前，请先去平台限额页面确认。几个实际建议：

免费或入门层适合验证。 你可以完成集成、跑几次测试调用、确认 OpenAI SDK 正常工作。
入门限额不适合 coding agent。 真正的 agent loop 需要足够的 RPM、并发和 token 吞吐，否则会不断 backoff。
尽早匹配需要的吞吐。 对于真实 workload，最便宜的解法通常是升到 benchmark 需要的 tier，而不是硬着头皮围绕最低限额做规避优化。

最容易被忽略的额外成本

按 token 的价格表并不是全部。生产环境里通常会悄悄冒出三类额外成本。

内置网页搜索和其他工具。 Moonshot 提供了 $web_search 等工具，模型可以在生成过程中调用。工具价格可能独立于模型 token 价格变化，而且搜索结果内容随后会被插入到下一次 /chat/completions 请求里，作为额外输入 token 计费。一个爱搜索的 agent，如果每个用户回合搜十次，可能同时付工具费用和搜索结果带来的额外输入 token 成本。

Reasoning tokens。 在 Thinking 模式下，模型会生成内部 reasoning tokens，它们按输出计费。简单问答时问题不大；但在工具循环型 agent 中，50 次工具调用累计出来的 reasoning 成本，很可能成为最大的费用项。如果任务不需要，关掉就对了。

Agent 重试与长时间循环。 Moonshot 自家的材料强调 K2.6 能在 12 小时里执行 4,000+ 次工具调用。这是很强的能力，也是一张很真实的账单。长时 agent 演示确实有价值，但也是最容易在不知不觉间烧掉一大笔预算的方式。运行 agent 工作流时，一定要限制最大步数和最大 token 数。

缓存未命中的模式。 调整 prompt 顺序、频繁修改 system message，或者面对大量上下文彼此差异很大的用户，都会降低缓存命中率。如果你发现 “input” 成本比预期大，通常问题就在这里。

Kimi K2.6 免费吗？

关于“免费”，其实有三种不同的问题，也有三种不同的答案：

在 kimi.com 浏览器端使用 Kimi。 Moonshot 的消费级产品通常带有一个按天限额的免费层。这不是 API，那里的对话不会消耗 API credits。

不付费使用 Kimi K2.6 API。 入门或促销额度可能允许你在不充值的情况下发送少量请求。它足够做集成测试，但不足以支撑持续负载。生产 API 使用应按付费来规划。

通过 Ollama Cloud、OpenRouter 等渠道使用 Kimi K2.6。 这些都是独立计费系统，拥有自己的免费额度和价格，不等同于“官方 Kimi API”，即使底层路由到了同一个模型。

所以结论是：免费试用是有路子的，但通过官方 API 免费运行 K2.6 生产负载并不存在。

如何控制 Kimi API 成本

扩量前的简要清单：

在控制台设置硬预算上限。
开启余额不足提醒。
始终传入 max_tokens，尤其是在 agent loop 中。
稳定上下文放前面，用户特定内容放后面，以提高缓存命中。
对不需要的任务关闭 Thinking 模式。
给 $web_search 加显式开关，不要让每个 prompt 都触发。
给 agent loop 设置最大步数与超时。
记录每次请求的 input、output 和 cached-input token 数，这样你才能真正看清成本来自哪里。

最后建议

如果你在评估 Kimi 是否适合 coding agent 或长上下文工作流，它的成本结构是可行的，但不是天然便宜。headline token 价格有竞争力，cache hit 的价格也有价值——但前提是你真的把 prompt 设计成容易命中缓存。对于新的 coding-agent 工作，不应默认 K2.6 仍是首选，而应该把 K2.7 Code 一并比较。

对大多数团队来说，更合理的起点是：搭好集成，测量你在生产中的真实 cache-hit 率和 token 分布，确认账号当前速率限制，然后再决定 K2.6、K2.7 Code 或其他模型哪个更适合你的真实 cost-per-task。

FAQ

如何获取 Kimi API Key？
登录 platform.moonshot.ai，打开 API keys 页面并创建一个新 key。它只会显示一次，所以请立刻复制。同时建议一并设置预算上限。

Kimi K2.6 多少钱？
全球价格页显示，K2.6 为 cache hit $0.16 / MTok、input $0.95 / MTok、output $4.00 / MTok；K2.7 Code 为 cache hit $0.19 / MTok、input $0.95 / MTok、output $4.00 / MTok。如果你的账号按人民币账单，请以本地控制台为准。

Kimi K2.6 可以免费使用吗？
kimi.com 上的消费级免费层与 API 计费是分开的。API 账号也可能有入门或促销额度，但生产 API workload 应按付费使用来做预算。

Kimi API 支持 OpenAI SDK 吗？
支持。Kimi API 与 OpenAI 兼容。只需把任意 OpenAI SDK 指向 https://api.moonshot.ai/v1，使用你的 Moonshot key，并将 model 设置为 kimi-k2.6。

Kimi API 的速率限制是什么？
速率限制按 tier、账号状态、充值历史和当前平台政策变化。生产估算请使用实时控制台限额页，不要复制过期的 RPM 表。

Kimi 网页搜索多少钱？
请查看当前 tools pricing 页面。网页搜索或类似工具可能独立于模型 token 计费，返回内容还会增加下一次请求的输入 token 成本。

我可以把 Kimi K2.6 用在工具调用和 function calling 场景吗？
可以。K2.6 支持与 OpenAI 风格一致的工具调用和 function calling。不过 Moonshot 文档提到一个约束：在开启 Thinking 模式时，tool_choice 应设置为 auto 或 none，并且你必须在多轮工具调用之间保留 assistant 消息中的 reasoning_content。