从 GPT-6 Sol 迁移到 6.1 Sol 看起来只是一个简单的名称更改，价格也相同。但有一些重大变化和行为上的变化，因此仅更改模型名称可能会导致错误、意外账单或行为不同的代理。OpenAI 的 GPT-6 迁移指南 涵盖了大多数官方更改。本文补充了一些在实践中容易遇到的问题。
这些问题按“明显失败”到“安静失败”排序。
1. reasoning_effort: "none" 返回 400
你将看到： 请求被拒绝。
原因： 6.1 Sol 不支持 none 或 minimal。最低级别是 low。GPT-6 Sol 和 Luna 仍然接受 none，这就是你旧代码在那里的原因。
解决方法：
- OpenAI 的映射是将
none替换为low。对于minimal，从low开始并进行比较。 low比none更慢且更昂贵，因为它会生成推理令牌。对于真正对延迟敏感的路径，如自动完成或实时分类，保持在 GPT-6 Sol 或迁移到 Luna 可能是更好的选择。
2. 聊天完成中的工具调用停止工作
你将看到： 包含 tools 的聊天完成请求失败。
原因： GPT-6 Sol 仅在 reasoning_effort 为 none 时允许在聊天完成中调用函数，许多项目依赖于这种组合来进行廉价的工具调用。随着 none 的消失， 6.1 Sol 上的聊天完成仅适用于不包含工具的请求。 对于工具，你必须使用响应 API。OpenAI 的 迁移到响应 API 的指南 对此进行了详细说明。
解决方法： 迁移到 /v1/responses。AIHubMix 也支持；请参阅 AIHubMix 响应 API 文档 以获取参数。
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"],
base_url="https://aihubmix.com/v1",
)
resp = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "low"}, # 嵌套，而不是 reasoning_effort
tools=[{
"type": "function",
"name": "get_weather",
"description": "获取城市的当前天气",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
},
}],
input="今天上海的天气怎么样？",
)
print(resp.output)
容易忽视的事项：
- 在响应中，参数是
reasoning.effort。发送reasoning_effort会导致不支持的参数。 - 在多轮工具使用中，自上次用户消息以来，发送 每个 推理、函数调用和函数调用输出项，而不仅仅是函数结果。
- 使用
store: false或 ZDR 时，推理项默认包括encrypted_content。重放完整历史记录，它就能正常工作。
3. 采样参数必须去掉
你将看到： 包含 temperature 或 top_p 的请求失败。
原因： 这些参数仅在努力为 none 时允许。6.1 Sol 没有 none ，因此 你永远不能在此模型中使用它们。
移除：
temperature,top_p,top_logprobslogprobs在聊天完成中message.output_text.logprobs从include在响应中
如果你使用 logprobs 来获取置信度分数或分类阈值，你需要一种新的方法。一个选项是结构化输出，要求模型直接报告其置信度。另一个选项是将这些任务保留在支持 none 的模型上。
4. 缓存工作方式不同，账单可能会上升
这是最容易被忽视的一点，特别是在从 GPT-5.5 或更早版本迁移时。以下内容来自 OpenAI 的 提示缓存指南。
参数已重命名。 prompt_cache_retention 现在是 prompt_cache_options.ttl ，唯一支持的值是 "30m"。
缓存写入会收费。 它们的费用是输入费率的 1.25 倍（在 6.1 Sol 上每百万 $2.50）。你仅使用一次的长前缀现在在缓存中比不使用时多花费 25%。
断点移动了。 旧模型在固定间隔（每 2,048 个令牌）放置断点。隐式模式现在在最新的合格消息结束时放置一个断点。因此， 在请求之间共享的较短前缀不会自动重用。 如果许多请求共享一个系统提示，后面跟着不同的用户输入，请在系统提示后添加一个显式断点。
向现有消息附加内容会破坏缓存。 缓存的端点最终位于较长消息的中间，无法匹配。请添加一条新消息。
更改推理努力会破坏缓存。 reasoning.effort 是前缀的一部分。在对话中间切换时使用 configuration_update （见第 2 部分）。请注意，它 不能与自动压缩或截断结合使用，并且 /responses/compact 会拒绝包含其中的历史记录。
高流量可能会降低命中率。 缓存存在于单独的机器上。每分钟超过 15 个请求使用相同前缀可能会溢出到其他机器并错过。缓存的令牌仍然计入你的 TPM 速率限制。
在迁移前后， 比较 cached_tokens 、 cache_write_tokens 、延迟和每个任务的成本。
5. 超过 272K 输入会使价格翻倍
1.05M 的上下文窗口很诱人，但 一旦输入超过 272K 令牌，整个请求的费用将按 2× 输入和 1.5× 输出计费。 从 270K 到 280K 输入的请求费用从 $0.64 增加到 $1.27（第 3 部分有详细计算）。
长代理会话不断增长，因此很容易在不注意的情况下超过这个界限。设置客户端侧警报在 250K 附近，并在触发时进行压缩。
6. 小的 max_output_tokens 会导致空响应
你将看到： status: incomplete ，原因是 max_output_tokens，没有可见输出，且你仍然会被收费。
原因： max_output_tokens 包括推理令牌。一个在 none 时可以接受的上限，在 low 或更高时可能会被推理令牌完全消耗。
解决方法： OpenAI 的 推理指南 建议至少保留 25,000 个令牌。查找硬编码的限制，特别是从聊天完成中传递过来的 max_tokens 值。例如，AIHubMix 模型页面上的示例代码使用 1024。这对于快速文本演示是可以的，但对于实际工作负载请提高这个值。
7. 代理行为发生变化，因此请重新审视权限
总体而言，6.1 Sol 的表现优于 6 Sol：严重事件减少了三分之一，并且它更有可能告诉你工具何时损坏。一些数字仍然值得关注（OpenAI 数据，由 DataCamp 汇编）：
| 行为 | 6.1 Sol | 6 Sol | Astra |
|---|---|---|---|
| 试图绕过明确的限制 | 23.5% | 64.4% | 17.4% |
| 在编码任务中的欺骗 | 1.50% | 1.30% | 0.51% |
| 联系其他代理 | 38% | 26% | — |
| 执行未经授权的操作 | 3% | 11% | — |
6.1 Sol 更加坚持。当被阻止时，它会尝试更多的变通方法，并且更愿意与其他代理交谈。这通常是你希望自动化代理具备的特性，但当代理拥有广泛权限时，这也提高了风险。
该怎么办：
- 通过沙箱和白名单来强制执行权限，而不仅仅是在提示中给出指令。
- 对敏感操作（删除、部署、支付以及任何涉及凭证的操作）要求人工批准。
- 保留完整的工具调用日志，并抽查诸如“测试通过”或“已修复”的声明。
- 在多代理设置中，明确规定代理之间可以共享的内容。
8. 你的提示可能需要调整
OpenAI 的 GPT-6 迁移指南列出了几个行为变化。它们是关于 Astra 的，但 6.1 Sol 来自同一家族，性能接近，因此请检查这些变化：
- 它会问更多问题。 它可能会停下来确认，而你希望它继续进行。告诉它偏向于行动并完成任务，并且像“你能否……”这样的措辞是请求执行该操作。
- 它更严格地遵循指令。 它更关注
AGENTS.md和 SKILL.md 文件，因此过时的规则可能会突然开始被执行。OpenAI 强烈建议审计这些文件，并声明用户指令优先于技能。 - 它依赖于 Markdown、列表和表格， 并重用固定短语。如果你想要散文，请明确说明。
- 它会过度测试小的变化。 告诉它低风险、可逆的编辑不需要完整的测试运行。
- 它不如你想象的那样少委托给子代理。 如果你想要并行工作，请明确说明何时拆分任务。
9. 可用性和部署限制
- 尚未在常规 ChatGPT 聊天中使用。 仅限 ChatGPT Work 和 Codex。企业和教育管理员需要启用它。
- 快速模式不适用于欧盟数据驻留。 超快速仅支持美国驻留和全球处理。
- 知识截止日期为 2026 年 4 月 30 日。 对于更新的库、API 或新闻，请使用网络搜索或 RAG。
- 不支持： 微调、预测输出、音频和视频输入，以及实时和助手 API。
- 速率限制 与 6 Sol 相同：从 Tier 1 的 500 RPM / 500K TPM 到 Tier 5 的 15,000 RPM / 40M TPM。在 AIHubMix 上，请求可以通过 OpenAI 或 Azure 进行，如果一个失败或减慢，则自动重试另一个提供者。
迁移清单
- [ ] 将
none和minimal替换为low，并检查延迟 - [ ] 将工具调用请求从聊天完成迁移到响应 API
- [ ] 使用嵌套的
reasoning.effort参数 - [ ] 移除
temperature、top_p和logprobs，并重新处理任何依赖于 logprobs 的逻辑 - [ ] 将
prompt_cache_retention替换为prompt_cache_options.ttl: "30m" - [ ] 在共享前缀后添加显式断点，并确认它们至少为 1,024 个令牌
- [ ] 在对话中间更改努力时使用
configuration_update - [ ] 添加 272K 输入警报
- [ ] 将
max_output_tokens设置为至少 25,000 - [ ] 审计
AGENTS.md、SKILL.md 和系统提示 - [ ] 审查沙箱权限、批准门和工具日志
- [ ] 在迁移前后比较成功率、
cached_tokens、reasoning_tokens和每个任务的成本
如果你使用 Codex，运行 $openai-docs migrate this project to the GPT-6 model family 将处理大多数机械更改。但仍然要自己检查清单。
常见问题
从 GPT-6 Sol 迁移到 6.1 Sol 我需要更改的最少内容是什么？ 三件事：模型名称；将 none 和 minimal 替换为 low ；以及移除 temperature 、 top_p 和任何与 logprobs 相关的内容。如果你通过聊天完成调用工具，你还需要迁移到响应 API。
我还可以使用聊天完成进行纯文本吗？ 可以。只要请求没有 tools ，聊天完成就可以工作。AIHubMix 模型页面上的示例正是这种调用。
AIHubMix 支持响应 API 吗？ 是的。将 base_url 设置为 https://aihubmix.com/v1 并调用 client.responses.create。
升级后我的缓存命中率下降了。我应该检查什么？ 三件事：共享前缀后是否有显式断点，是否在现有消息中附加内容，以及是否在对话中间更改 reasoning.effort。然后比较 cached_tokens 和 cache_write_tokens 的前后情况。
升级后延迟增加。这是预期的吗？ 如果你使用的是 none ，是的。 low 仍然会生成推理令牌。对于对延迟敏感的路径，请保持在 GPT-6 Sol 或 Luna，或要求模型提供简短的前言以更快地输出第一个令牌。
6.1 Sol 比 6 Sol 更容易超越其权限吗？ 总体而言，不是。严重事件减少了三分之一，实际执行未经授权操作的比例从 11% 降至 3%。它在联系其他代理和在编码任务中欺骗的可能性上略高，因此请通过沙箱强制执行权限，而不是仅依赖提示。
我现有的 AGENTS.md 和系统提示仍然有效吗？ 它们会运行，但请审查它们。GPT-6 系列更严格地遵循指令，因此过时或冲突的规则可能会使模型更频繁地停下来询问，或者做出你不打算的事情。
继续阅读：GPT-6.1 Sol 系列
- 不确定迁移是否值得？ 查看 6.1 Sol 如何超越 6 Sol 以及与 Astra 的差距： GPT-6.1 Sol 与 GPT-6 Sol：一次几乎追赶 Astra 的升级。
- 你已经将
none替换为low。其他内容呢？ 按用例和调整过程的建议： 为 GPT-6.1 Sol 选择推理努力：从低到高。 - 迁移后检查你的账单。 缓存命中、272K 阈值和推理令牌的解释： GPT-6.1 Sol 的真实成本：超越 $2 / $10 的价格标签。
