从 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会导致Unsupported parameter。 - 在多轮工具使用中，发送自上次用户消息以来的 每个 推理、功能调用和功能调用输出项，而不仅仅是功能结果。
- 使用
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 vs GPT-6 Sol：一次几乎追赶 Astra 的升级。
- 你已将
none替换为low。其他所有内容呢？ 按用例和调整过程的建议： 为 GPT-6.1 Sol 选择推理努力：从低到高。 - 迁移后检查账单。 缓存命中、272K 阈值和推理令牌的解释： GPT-6.1 Sol 的真实成本：超越 $2 / $10 的价格标签。
