迁移到 Kimi K3.1 Pro：修复 400 错误，注意默认的 max 推理强度，别把 Highspeed 拼错

Kimi K3.1 Pro 已在 Kimi Code 上线，在 Moonshot 的 API 上的 ID 为 kimi-k3.1-pro，在 AIHubMix 上也使用同一 ID。Moonshot 为它设定了与 Kimi K3 相同的参数限制，因此已能在 K3 上运行的代码只需更改模型 ID 并开启新会话即可迁移。对于 K2.x 编写的代码，Moonshot 平台已设定截止日期：Moonshot 将于 2026 年 10 月 31 日起不再向新注册用户开放 K2 系列，并计划在 12 月底前将其退役。这类代码也最容易出问题，因为它往往会传入 temperature，或关闭思考模式，而这两种做法在 K3.1 Pro 上都行不通。另外，从未设置推理强度的代码会以 max 运行，消耗的 token 可能比你预期的更多；在 Kimi Code 中，消耗的配额也会比 K3 更多。

本文将介绍哪些问题会直接报错（400 错误，另加一个 404 错误），哪些问题不易察觉（账单、缓存、Highspeed ID），以及如何通过 AIHubMix 为 K3.1 Pro 配置 Claude Code 和 Codex。K3.1 Pro 的规则来自 Moonshot 的Kimi Code 模型文档和模型参数参考，其中说明，两个 K3.1 Pro ID 都“采用与 kimi-k3 相同的参数限制”。标注为 K3 的规则来自 Moonshot 的 K3 指南，尚未在 K3.1 Pro 上重新核实。错误文本引自文档、公开报告、AIHubMix 7 月对 K3 的测试，以及 AIHubMix 于 2026 年 10 月 24 日对 K3.1 Pro 的检查。这些检查涵盖了主要 ID，以及编程通道 ID coding-kimi-k3.1-pro 和 coding-kimi-k3.1-pro-highspeed。每项说法都会注明来源。

你使用的是哪种方式？

在 Moonshot 的 API 和 AIHubMix 上，ID 分别为 kimi-k3.1-pro 和 kimi-k3.1-pro-highspeed。在 Kimi Code 中，它们分别是 k3.1-pro 和 k3.1-pro-highspeed。10 月 21 日发现的一份客户端配置将 k3 和 kimi-for-coding映射到了 k3.1 模型，但 Kimi Code 文档现在将 k3 列为 K3，将 kimi-for-coding 列为 K2.8 Preview，因此请明确选择 K3.1 Pro。你的套餐也很重要：在 Kimi Code 中，K3.1 Pro 需要 Plus 或更高等级（1M 上下文需要 Pro），Highspeed 则需要 Pro 或更高等级。旧版套餐需要 Moderato 或更高等级；1M 上下文和 Highspeed 则需要 Allegretto。

K2 的日期安排由 Moonshot 公布。自 2026 年 10 月 31 日起，K2 系列模型将不再向新注册用户开放，并且都将在 2026 年 12 月底前退役。Moonshot 尚未公布 K3 的退役日期。截至 10 月 24 日，AIHubMix 仍列有 K2.6 和 K2.7 Code，且未注明退役日期。

会直接报错的问题

关闭思考模式：HTTP 400，或完全不进行推理

你会看到：Kimi Code 返回 HTTP 400。Moonshot 的 Kimi Code 文档称，K3.1 Pro 模型“仅支持思考模式。关闭思考模式的请求会被拒绝。”文档没有引用具体的错误响应内容。在 Moonshot 的 API 上，K3.1 Pro 沿用 K3 的参数限制，而 K3 始终会进行推理。通过 AIHubMix 调用时不会出现 400 错误：10 月 24 日，thinking: {"type": "disabled"} 在两个主要 ID 上通过 Chat Completions 和 Messages 均返回 200，但响应中没有推理内容。这属于不易察觉的失败，因此请检查响应中是否缺少推理内容。

问题来源：关闭思考模式以加快响应速度的 K2.x 代码，例如使用 extra_body={"thinking": {"type": "disabled"}}；以及发送 off、none 或 disabled 推理强度的工具（见下一节）。

修复方法：移除这个开关。若想缩短思考过程，请改为发送 reasoning_effort: "low"。

遗留的 "enabled" 参数块是另一种情况。AIHubMix 在 10 月 24 日进行的检查中，将 K2.x 的 thinking: {"type": "enabled"} 发送给 K3.1 Pro，主要 ID 和编程通道 ID 均返回了 200。Moonshot 的文档称 thinking 是“仅适用于 K2.x 的请求参数”，而一份第三方故障排查指南则指出，从 K2.x 切换到 K3 后，遗留参数块会导致 400 错误，因此还是应该将其删除。

如果你会在 K2.7 Code 退役前保留它作为备用层级，请确保开启思考模式。Moonshot 的 Claude Code 指南记录了 K2.7 Code 关闭思考模式时会返回的错误：400 invalid thinking: only type=enabled is allowed for this model。

推理强度的取值：off、none 和未知值会返回 400

你会看到：推理强度为 off、none、disabled，或 Kimi Code 无法识别的值时，会返回 HTTP 400。K3.1 Pro 有三个等级：low、high 和 max。Moonshot 的 Kimi Code 文档说明了第三方工具发送的值会如何映射到这些等级：

Moonshot 的 API 文档对 K3.1 Pro 仅列出了 low、high 和 max，默认值为 max，但没有说明映射规则。在 AIHubMix 上，10 月 24 日对全部四个 K3.1 Pro ID 的测试中，low、medium、high、max 和 xhigh 均返回了 200。在 kimi-k3.1-pro 上，off 和未知值也返回了 200，并包含推理内容；而 none 返回 200，却完全没有推理内容。在 AIHubMix 上，这些问题不会明确报错，而是悄然发生。

不易察觉的问题：没有 medium 等级。设置为 medium 的工具会得到 high；设置为 xhigh 的工具则会得到 max，也就是成本最高的等级。

修复方法：明确发送 low、high 或 max，并检查工具实际发送的请求内容。

“无效的 temperature：此模型仅允许使用 1”

你会看到：400 invalid temperature: only 1 is allowed for this model。AIHubMix 在 10 月 24 日的检查中，向 kimi-k3.1-pro 和 kimi-k3.1-pro-highspeed 发送 temperature: 0.2 时，恰好收到了这条错误。2026 年 10 月 3 日，有人在 Moonshot 的 API 上针对 K3 报告过相同文本；10 月 21 日，也有人在 Kimi Code 端点对 k3 进行调用时报告过同样的错误。

原因：Moonshot 的参数参考为 K3.1 Pro 列出了 K3 的参数限制：temperature 固定为 1.0，top_p 为 0.95，n 为 1，两个 penalty 均为 0；其他取值都会报错。K2.6 也有固定值：关闭思考模式时为 0.6，因此仍在发送 0.6 的代码通常最有可能是问题所在。

容易掩盖问题的例外情况：在同一次检查中，AIHubMix 的编程通道接受了 temperature: 0.2。如果代码只在该通道测试过，切换到主要 ID 或 Moonshot 的 API 时仍可能出错。

让问题更难察觉的陷阱：许多框架通过 kimi- 前缀识别 Kimi 模型，并为其移除 temperature。Kimi Code 的 k3.1-pro 和 k3.1-pro-highspeed 不带这个前缀，AIHubMix 编程通道的 ID 也不带，它们以 coding- 开头。一个 Hermes Agent 问题报告在 K3 上发现了完全相同的情况。主要聊天路径没有传入 temperature，但对 k3 的辅助调用仍然发送了该参数，因此每次都返回 400。

修复方法：不要发送 temperature、top_p、n、presence_penalty 或 frequency_penalty。应根据模型系列进行判断，而不是根据名称前缀。

要检查某个路由，请发送一个带 temperature 的请求：

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

10 月 24 日，这条请求返回了上述 400 错误。请对代码使用的每个模型 ID 都运行此测试：编程通道对相同请求返回了 200。

通过 AIHubMix 使用 Codex：Responses API 返回 404

你会看到：HTTP 404，错误信息为 The model kimi-k3.1-pro is not available on this endpoint.。AIHubMix 在 10 月 24 日的检查中发现，两个主要 ID 通过 Responses API 调用时都会返回此错误，而 Chat Completions 和 Messages 则正常响应。

修复方法：Codex 只支持 Responses API，因此请将其指向 coding-kimi-k3.1-pro；同一项检查中，该 ID 能正常响应 Responses 请求。AIHubMix 将编程通道标注为评估预览版，不建议用于生产环境；其部分请求还会短暂返回 404，错误信息为“The requested resource was not found”，因此开始排查前请先重试一次。在 AIHubMix 为主要 ID 添加 Responses API 支持之前，请使用编程通道。Claude Code 使用 Messages，因此可在主要 ID 上正常工作。

stop 限制

你会看到：AIHubMix 在 7 月对 K3 进行的测试中返回了以下两条消息：

• Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

原因：K3 最多接受五个 stop 序列，每个序列最长为 32 字节；Messages API 对 stop_sequences 也会应用相同的检查。Moonshot 为 K3.1 Pro 设定了相同的参数限制，因此可以预期它也有相同限制。

修复方法：缩短列表。请注意，32 个字节所能容纳的中文或日文字符不到 32 个。

在 Moonshot 的 API 上使用 Codex：“不支持 web_search.search_context_size”（K3 指南）

你会看到：400 web_search.search_context_size is not supported。这段错误信息引自 Moonshot 的 Codex 指南，该指南是针对 K3 编写的。10 月 24 日，通过 AIHubMix 的编程通道发送包含该字段的 Responses 请求时，返回了 200，因此此错误来自 Moonshot 自己的端点。

修复方法：从 Codex 配置或工具定义中删除 search_context_size。Codex 默认不会发送此字段。

不易察觉的问题

这些问题不会返回错误。它们会在之后体现在账单、套餐配额或输出质量上。

推理强度与会话

• 默认值是 max，而且这是 Kimi Code 新出现的情况。K3.1 Pro 的默认值为 max。在 Kimi Code 中，K3 的默认值是 high，因此从未设置推理强度的会话如今会进行更深入的思考、使用更多 token，并更快消耗配额。在 Moonshot 的 API 上，K3 和 K3.1 Pro 的默认值均为 max。思考过程会计入输出 token 费用：在 AIHubMix 7 月对 K3 进行的单提示词游戏构建测试中，74,994 个 completion token 里有 73% 用于思考。
• 低推理强度仍可能产生数千个思考 token。在 10 月 24 日的一次 AIHubMix 抽查中，对于一个要求撰写 600 词解释的提示词，K3.1 Pro 在low下先进行了 5,561 到 7,356 个 token 的推理才作答，其中一次运行触及了 8,192 个 token 的上限。同一提示词下，K3 推理了 3,013 到 7,051 个 token，因此这并不是 K3.1 Pro 才有的新情况；但两者的low模式都不省 token，务必为max_completion_tokens留出充足额度。这只是每个模型在 AIHubMix 主 ID 上使用一个提示词进行的三次运行，请根据自己的工作负载进行测试。
• 在旧会话中切换到 K3.1 Pro 会降低质量。Moonshot 的 Kimi Code 文档建议不要“在现有的 K3 系列、K2.8 Preview 或 K2.7 Code Highspeed 会话中”切换到新模型，因为这会降低输出质量并减少缓存命中。请新建会话。
• 更改模型或推理强度会使缓存失效。Moonshot 的 Kimi Code 文档明确指出，两种更改都会导致这一情况；K3 文档也提到，切换推理强度“会使前缀缓存命中失效”。请在会话开始时选定模型和推理强度。

Highspeed

• Highspeed ID 拼错，会让你用上更慢的模型。在 Kimi Code 中，错误的 Highspeed ID“会静默回退到 K2.8 Preview，且不启用思考模式——不会提速。”请准确复制 ID，并检查日志中显示的是哪个模型。
• Highspeed 只会加快模型输出。Moonshot 表示，K3.1 Pro Highspeed 的速度约为 K3.1 Pro 的 2–3 倍，能力则完全相同。在 AIHubMix 的抽查中，其输出速度约为 Pro 的 1.6–1.8 倍。工具调用和脚本的速度完全不会提升，因此，如果一个回合的主要耗时在读取文件和运行测试上，提速幅度就很小；而 Kimi Code 计划的额度消耗约为两倍。

协议

• 代理可能会改变模型行为。Moonshot 的 Kimi Code 文档警告：“通过代理工具进行协议转换可能导致模型行为发生变化。”请为每种工具使用它支持的协议：Claude Code 使用 Messages，Codex 使用 Responses。10 月 24 日，AIHubMix 上的 Chat Completions 和 Messages 在全部四个 K3.1 Pro ID 上都返回了推理内容，分别以reasoning_content和thinking区块的形式呈现。Responses 在 coding channel 上可用，并返回了一个reasoning条目；而在主 ID 上则返回了前文所述的 404。
• Messages API 的结构化输出功能有所改进。在 AIHubMix 7 月对 K3 的测试中，/v1/messages忽略了 schema，返回了自由文本。10 月 24 日，对 K3.1 Pro 发出同类请求时，在output_config.format中提供 JSON schema，且提示词未要求返回 JSON，结果全部四个 ID 都返回了{"city":"Paris"}。这只是一个单字段 schema，因此在将 JSON 工作流迁回 Messages 前，请先验证输出。7 月测试中 Messages 的另一个异常——命中停止序列时返回end_turn且stop_sequence: null——此次没有重新测试。

长请求

• 超时设置过短，连中等长度的请求也会失败。在抽查中，K3.1 Pro 在low下生成完整回答耗时 80 到 99 秒。超时设为 60 秒的非流式客户端每次运行都会失败，而重试又会再次为相同的思考过程付费。在 Moonshot API 上，K3.1 Pro 的默认输出上限为 131,072 个 token，最高可达 1,048,576 个；AIHubMix 7 月在 K3 上构建游戏的一次请求则运行了 2,541 秒。请使用流式传输，并将超时设为数分钟。

沿用自 K3 指南的注意事项

以下注意事项来自 K3 指南：

• 丢弃reasoning_content会降低多轮对话质量。必须原样传回完整的 assistant 消息，包括reasoning_content和tool_calls。只保留content的代码仍然能运行，但 Moonshot 警告说，输出质量会不稳定。
• 丢弃动态工具消息会导致工具消失。K3 支持通过不含内容的 system 消息在对话中途加载工具。服务器不会保留这条消息，因此每次请求都必须重新发送。在 AIHubMix 上，这种方式可通过 Chat Completions 使用：10 月 24 日，kimi-k3.1-pro调用了通过这种方式注入的工具。在 AIHubMix 7 月对 K3 的测试中，Messages API 则忽略了注入的工具。

容易忽略的计费规则

以下价格来自 AIHubMix 的模型页面，按每百万个 token 计费：

在 AIHubMix 上，K3.1 Pro 的输入和缓存输入价格比 K3 低 30%，输出价格低 26%。Highspeed 的输入和输出价格是 Pro 的两倍，缓存价格则相同。coding channel ID 单独定价：输入 $0.88、输出 $3.23、缓存 $0.132。

费率更低，不代表账单更少。以 AIHubMix 7 月使用 K3 构建游戏的单提示词测试为例：输出 74,994 个 token，假设输入为 5,000 个 token。如果 token 数量相同，K3 费用约为 $1.08，K3.1 Pro 约为 $0.80（5,000 × $2.00 + 74,994 × $10.50，按每百万个 token 计费），Highspeed 则约为 $1.59。token 数量会随提示词而变化（抽查中，K3.1 Pro 和 K3 在low下的 token 数量范围相近），因此请先测试，再做预算。

Moonshot 的 API 文档规定，K3.1 Pro 的缓存写入按 TTL 计费，可设为 5 分钟或 1 小时，与 K3 相同。Moonshot 的上下文缓存指南公布的 K3 费率展示了其计费结构：

Moonshot 表示，将缓存写入费用单独列出并未提高 K3 的总费用：写入成本原本就包含在输入价格中，因此使用默认的 5 分钟 TTL 时，请求费用与之前相同。

以上是 Moonshot 的直连费率。AIHubMix 的模型页面只列出输入、输出和缓存输入价格，没有单独列出缓存写入费率，也没有说明 1 小时写入如何计费。不过，AIHubMix 会传递 TTL 设置：10 月 24 日，一条顶层cache_control TTL 设为1h的 Messages 请求，其写入被报告为 1 小时缓存 token；带有prompt_cache_options的 Chat Completions 请求也成功受理。

• 缓存会自动启用。K3 的默认 TTL 为 5 分钟。在 AIHubMix 10 月 24 日的测试中，同一个 93-token 提示词重复请求后，在 coding channel 上完全命中缓存，但在主 ID 上没有命中。对于一个 7,658-token 的提示词，第二次调用kimi-k3.1-pro时，在 Chat Completions 和 Messages 上都返回了 7,424 个缓存 token。
• Moonshot API 上的1 小时 TTL，按 K3 费率计算，每百万个 token 的写入成本多 $3.00。每次缓存命中可节省 $2.70，因此按照 Moonshot 自己的算法，从第二次命中开始就能回本。
• TTL 在首次写入时锁定（K3）。你无法将条目的 TTL 从 5 分钟升级为 1 小时，必须等它过期后才行。
• 成本仪表板需要新增一个字段（K3）。缓存写入会分别显示为 Chat Completions 中的prompt_tokens_details.cache_write_tokens、Responses 中的input_tokens_details.cache_write_tokens，以及 Messages 中的cache_creation_input_tokens。
• 推理属于输出。K3 的所有推理强度级别都会按输出费率对思考 token 计费。AIHubMix 没有单独列出 K3.1 Pro 的推理价格。

降低账单的做法：

1. 根据工作负载设置reasoning_effort，而不是沿用max。查找和分类任务可尝试low，常规编码则可尝试high。
2. 在每个会话中固定模型和推理强度；更改其中任一项时，都新建会话。
3. 将稳定内容放在前面：系统提示词、工具定义、代码库上下文；再放会变化的对话内容。
4. 只有在等待模型输出是瓶颈时才使用 Highspeed，不要用于主要耗时在工具调用上的循环。
5. 留意思考 token 在 completion token 中所占的比例。如果简单任务中的这一比例持续超过一半，就降低推理强度。

拥有实际权限的智能体

Hermes Agent 的问题展示了迁移错误如何演变成安全问题。其“智能审批”分类器调用k3时设置了 temperature，结果每次调用都返回 400。用报告者的话说，这个分类器“每次调用都会升级处理（故障时默认放行）”：安全检查不再发挥作用，而主聊天界面看起来一切正常。

K3.1 Pro 保留了这一触发问题，还增加了一个。分类器调用正是团队常通过设置较低的 temperature 或关闭思考模式来追求快速、低成本的调用；但在 K3.1 Pro 上，这两种做法都行不通：设置 temperature 可能导致每次调用都返回 400；在 AIHubMix 上，关闭思考模式的请求返回时则没有推理内容。如果安全检查运行在 K3.1 Pro 上，请使用reasoning_effort: "low"来提升速度，明确规定 API 错误时如何处理，并确保系统在故障时默认拒绝。

对于能够自主执行操作的智能体，还有几件事需要注意：

• 强制工具调用可用。K3.1 Pro 支持tool_choice: "required"，而 K2.x 不支持，因此可以移除 K2.x 中为强制工具调用而采用的变通方案。
• 内置网页搜索尚未达到生产环境可用状态（K3）。Moonshot 的 K3 指南称，其网页搜索“正在更新，目前不建议用于近期的生产工作流”。除非 Moonshot 另有说明，否则在 K3.1 Pro 上也应如此处理。通过 AIHubMix 使用时，10 月 24 日 K3.1 Pro 的搜索循环未能完成：模型请求调用$web_search，但将结果发回后返回了400 Invalid request: tokenization failed。
• 图像输入必须使用 base64。K3 不会抓取公开图片 URL；10 月 24 日，AIHubMix 上的kimi-k3.1-pro也拒绝了一个图片 URL，并返回400 Invalid request: unsupported image url，因此传递截图链接的智能体会报错。Moonshot 提供的另一种方式是使用其文件上传功能返回的文件 ID，但 AIHubMix 不支持这种方式：一个ms://引用返回了 404。base64 图像则可以正常使用。K3.1 Pro 也可在 Kimi Code 中接收视频输入。

编码工具：Claude Code 和 Codex

Claude Code 使用 Anthropic Messages API，10 月 24 日 AIHubMix 的主 ID 能够响应此 API。Codex 使用 Responses API，只有 coding channel 能够响应。安装和基本配置请参阅 AIHubMix 的常青指南。以下仅介绍 K3.1 Pro 的相关变化。

Codex 列使用 coding 通道的 ID，直到主 ID 能在 Responses API 上正常响应为止。工具发送的任何超出这三个值的 effort 都会按照上文的 effort 表进行映射。

Claude Code

按照Claude Code settings.json 指南操作。然后设置每个模型层级，而不只是主层级：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

根据 Moonshot 的 Kimi Code 文档、其 Claude Code 指南（针对 K3 编写）以及 AIHubMix 的测试，已知问题如下：

• 开始新会话。不要把正在运行的 K3 会话切换到 K3.1 Pro。请新开一个会话，让缓存和输出质量都从干净状态开始。
• 未设置的层级会静默失败。Claude Code 会为主聊天、摘要和子智能体使用不同的层级。Moonshot 提醒，只配置其中一部分会导致其余层级“静默失败”。你可以将 Haiku 层级指向更便宜的模型，用于后台任务。
• 旧设置会优先生效。env 块中的旧值会覆盖在 shell 中导出的变量，位置在 ~/.claude/settings.json。
• 1M 上下文。Moonshot 的 K3 指南使用kimi-k3[1m]，让 Claude Code 将上下文窗口识别为 1M。通过 AIHubMix 使用kimi-k3.1-pro[1m]也同样有效：Claude Code 会在发送前去掉后缀，而 AIHubMix 于 10 月 24 日成功响应了生成的请求，其中包括 1M 上下文标头。只有 Claude Code 能识别这个后缀。如果其他客户端将kimi-k3.1-pro[1m]作为模型 ID 发送，会返回 400 错误。
• 推理强度。K3.1 Pro 的默认值已经是max，Moonshot 的 K3 指南也建议搭配CLAUDE_CODE_EFFORT_LEVEL=max使用。日常任务使用high可以减少 token 消耗。Claude Code 发送的任何等级都会按照推理强度表进行映射，AIHubMix 接受了测试的全部五种值。
• Highspeed 层级。如果将某个层级指向kimi-k3.1-pro-highspeed，请准确复制 ID。在 Kimi Code 中，拼写错误会静默回退；在 AIHubMix 中，ID 拼错会返回 400 错误。

Codex

Codex 只支持 Responses API，因此必须设置wire_api = "responses"。其余设置请参阅Codex config.toml 指南。对于 K3.1 Pro：

# At launch (24 October 2026), the main ID kimi-k3.1-pro returned 404 on the Responses API.
# Use the coding-channel ID until AIHubMix adds it. AIHubMix labels the
# coding channel an evaluation preview, not for production.
model = "coding-kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

• 声明上下文窗口。如果没有设置model_context_window，Codex 就会回退到它不认识的模型的默认元数据。Moonshot 的 Codex 指南针对 K3 编写，其中说明，由此产生的Model metadata for kimi-k3 not found警告是预期行为，可以忽略。
• 推理强度。Codex 自带的等级包括medium和xhigh。按照 Kimi Code 的映射，它们分别按high和max运行，AIHubMix 于 10 月 24 日确认两者均可用。请设置为low、high或max，以明确自己为哪个等级付费。
• 通道有所不同。coding 通道接受了主 ID 拒绝的 temperature。等主 ID 能在 Responses 上正常响应后，请先重新运行冒烟测试，再进行切换。
• 不要设置search_context_size。如果配置中设置了它，请将其移除（参见会导致明显错误的设置）。
• 编辑后重启。Codex 只会在启动时读取 config.toml。如果 CC Switch 管理你的 Codex 配置，它可能会覆盖你的修改。

15 分钟冒烟测试

在一个带有测试套件的小型代码仓库中，对每个工具各运行一次：

1. 在 K3.1 Pro 上开始一个全新会话。不要继续使用之前运行 K3 或其他模型的会话。
2. 提出请求：“为此仓库中的一个函数添加单元测试，运行测试，并修复所有失败项。”
3. 成功时应是这样：模型读取文件并运行测试（工具调用正常）。看到测试结果后，它会继续操作，这说明推理内容和工具结果都传回了模型。最终测试全部通过，而且整个会话中没有出现 400 或 404 错误。
4. 在 AIHubMix 使用记录中，检查模型 ID 是否与你设置的一致，并确认后续请求的稳定前缀显示了缓存输入 token。如果一直没有显示，说明你的前缀中有内容每轮都会变化。
5. 记录每轮耗时和生成的 token 数量。它们是你选择推理强度，以及判断 Highspeed 是否值得使用的基准。

迁移检查清单

• 使用 K3.1 Pro 的 ID：在 Moonshot API 和 AIHubMix 上使用 kimi-k3.1-pro，在 Kimi Code 中使用 k3.1-pro；通过 AIHubMix 在 Codex 中使用 coding-kimi-k3.1-pro（暂时如此）。
• 在 Moonshot 于 2026 年 12 月底停用 K2 系列之前迁移 K2.x 代码；自 10 月 31 日起，新注册的 Moonshot 账号将无法使用 K2。
• 为 K3.1 Pro 开始新会话，不要切换旧会话。
• 从所有调用路径中移除 temperature、top_p、n 和两个 penalty 参数，包括辅助调用。
• 移除所有关闭思考模式的开关，包括 off、none 和 disabled 等推理强度值，并删除遗留的 K2.x 思考模块。
• 将推理强度设为 low、high 或 max；medium 按 high 运行，xhigh 按 max 运行。
• 在同一会话中保持模型和推理强度不变。
• 准确复制 Highspeed ID，并在使用记录中检查模型。
• 停止序列最多保留五项，每项不超过 32 bytes。
• 完整传回 assistant 消息，包括 reasoning_content 和 tool_calls，并重新发送动态工具消息。
• 对长请求启用流式传输，并将超时设置为分钟级。
• 将 JSON 转回 Messages API 之前，先验证结构化输出。
• 更新成本跟踪逻辑，以单独处理缓存写入字段。
• 安全检查遇到 API 错误时应默认拒绝。
• 在每个编码工具中运行冒烟测试。

常见问题

为什么 K3.1 Pro 会返回 HTTP 400？
常见原因包括 temperature 不等于 1、关闭思考模式，或推理强度设为 off、none、disabled 或未知值。第一种情况源于 K3 固定的采样规则，K3.1 Pro 也沿用了该规则；其余问题则见于 Moonshot 的 Kimi Code 文档。10 月 24 日，在 AIHubMix 的主 ID 上，只有 temperature 会返回 400；其他情况返回 200，而关闭思考模式或设为 none 时不会返回推理内容。

可以关闭思考模式吗？
不可以。K3.1 Pro 只能在思考模式下运行。将 reasoning_effort 设为 low，以缩短思考时间。

temperature 仍会被拒绝吗？
会。在 Moonshot API 和 AIHubMix 的主 ID 上仍会被拒绝；2026 年 10 月 24 日返回的错误为“invalid temperature: only 1 is allowed for this model”。在同一次检查中，AIHubMix 的 coding 通道接受了 0.2 的 temperature。所有调用路径都不要传入 temperature。

K2 模型什么时候停用？
自 2026 年 10 月 31 日起，新注册的 Moonshot 用户将无法使用 K2 系列模型，Moonshot 计划在 2026 年 12 月底前停用所有 K2 模型。10 月 24 日，AIHubMix 仍列有 K2.6 和 K2.7 Code，且未公布停用日期。

为什么我的 Kimi Code 配额消耗得更快？
K3.1 Pro 默认使用 max 推理强度，而 Kimi Code 中的 K3 默认使用 high；此外，Highspeed 消耗的配额约为常规模型的两倍。日常任务可以设置较低的推理强度，并在同一会话中保持不变。

为什么 Highspeed 没有更快？
可能是 ID 拼错了，在 Kimi Code 中会静默回退到不启用思考模式的 K2.8 Preview；也可能是工具调用占用了大部分轮次时间。Highspeed 只能加快模型输出。

Codex 应该使用哪个 AIHubMix 模型 ID？
暂时使用 coding-kimi-k3.1-pro，通过 aihubmix.com/v1 上的 Responses API 调用，并将 wire_api 设为 responses。10 月 24 日，主 ID 在 Responses API 上返回 404。AIHubMix 将 coding 通道标为评估预览版，不适用于生产环境。

继续阅读：Kimi K3.1 Pro 系列

• 迁移之前，先了解升级是否值得：从有哪些变化，到实际任务的成本是多少：Kimi K3.1 Pro 对比 K3：有哪些变化、成本如何、哪些人应该切换
• 如果迁移让你开始考虑其他选择，这篇文章将对比 K3.1 Pro、Qwen 4 和 Claude Fable 5.5，并列出每个模型完成一次前端构建的成本：Kimi K3.1 Pro 对比 Qwen 4 对比 Claude Fable 5.5：前端质量、单任务成本，以及炒作是否属实
• 如果 Highspeed 的配额和价格让你想知道快速版本是否划算，这篇文章专门探讨速度与价格之间的取舍：Kimi K3.1 Pro 对比 K3.1 Pro Highspeed：2–3× 的速度是否值得 2× 的价格？

来源

• Kimi Code：模型配置
• Moonshot AI：模型参数参考
• AIHubMix：Kimi K3.1 Pro 模型页面
• AIHubMix：Kimi K3 实操指南
• Hermes Agent issue #142365：Kimi Code 端点配置文件漂移