GPT-6.1 Sol 评测

如果你已经用 GPT-6 Sol 处理复杂编程和需要反复修改的任务，GPT-6.1 Sol 值得优先试用，并与旧版对照。 标准输入、输出单价维持不变，缓存读取费用减半，官方公布的多项评测也显示出能力提升。对于需求含糊、调查链路很长或返工代价很高的工作，我仍会保留 Astra 作为对照。

这个判断来自两个方向的证据：OpenAI 模型文档（英文）给出了可核对的规格和价格，官方发布公告（英文）报告了能力变化。前者可以用来算预算，后者可以帮助选择值得测试的任务。

GPT-6.1 Sol 是什么？

GPT-6.1 Sol 是 GPT-6 Sol 的升级版本，面向复杂编程、电脑操作和专业工作。OpenAI 的 API 更新记录（英文）将发布时间列为 2026 年 9 月 29 日，API 模型 ID 为 gpt-6.1-sol。

官方的核心定位是：以较低费用提供接近 GPT-6 Astra 的能力。是否适合替换现有模型，需要把这个定位落到具体任务上。

规格来自官方模型页（英文）。它与 GPT-6 Sol、GPT-6 Astra的上下文窗口和最大输出相同。这次升级的重点是能力与费用结构，上下文容量并未扩大。

百万级上下文也不等于每次都能有效理解整座代码仓库。模型还需要在窗口中容纳输出和推理；具体任务是否遗漏约束，仍要通过验收判断。它可以接收图片，但原生音频、视频输入输出不在该模型的支持范围内。

编程能力提升多少？先比较相同推理档位

我们在 OpenAI 官方公告（英文）的交互图表中核对了 DeepSWE v1.1 的原始数值。它评估真实代码库中的复杂软件工程任务。下表三款模型均为 medium；费用是发布方记录的基准平均单任务费用，不是本站账单或后文的假设算例。

这个结果让 6.1 Sol 很值得进入编程选型对照：得分接近 Astra，单任务费用低得多。但 0.2 个百分点的差距不能证明它全面优于 Astra，本文也没有据此宣称统计显著。

与旧 Sol 比，另一点更值得注意：虽然标准输入、输出单价没变，单任务费用却从 $0.38 上升到 $0.42，同时得分明显提高。单价不能替代任务用量，选型也不能只比较一张价目表。

更多推理同样不保证更好：6.1 Sol 在 high 为 75.2%／$0.65，在 max 为 71.9%／$1.57。公告提到的 6.4 个百分点提升，比较的是新 Sol 的 high 与旧 Sol 最好成绩 68.8% 的 max，并非两个 medium 的差值。

其他官方结果也指向智能体任务的改善：AutomationBench 1.0.6 中，medium 比旧 Sol 同档高 4.8 个百分点；OSWorld 2.0 的 v2026.08.08 离线集上，max 部分奖励得分比旧 Sol 高 7 个百分点，距 Astra 同档 2.1 个百分点。部分奖励不能当作所有电脑任务的完整成功率。

英语公告还报告，在有意挑选的困难事实性对话中，low 档包含至少一个事实错误的回答占比从 11.4% 降到 7.7%。这不是日常总体错误率。同一公告的 Terminal-Bench Science 0.1 对照里，Astra 在 max 仍以 68.1% 取得该轮最高成绩。现有证据支持试用新 Sol，尚不足以让所有工作流都移除 Astra。

API 价格：哪些便宜了，哪些没变

下面统一采用 OpenAI 直连 API 的 Standard 价格，单位为美元 / 百万 token，输入不超过 272K。这些数字不代表第三方网关报价，也不代表 ChatGPT 套餐额度。

来源：OpenAI API 定价（英文），并与三款模型页交叉核对。

从旧 Sol 升级，变化最明确的是缓存读取单价减半。输入、输出和首次缓存写入的单价都相同。如果一个工作流很少命中缓存，它能节省多少费用，就更依赖实际消耗的 token 和重试次数。

与 Astra 比较，6.1 Sol 的标准输入、输出单价都是其五分之一，缓存读取则是其十分之一。“价格只有五分之一”描述的是指定计费项目；一次任务的账单还取决于各类 token 的数量。

用四个场景算清楚

以下是固定 token 数量的合成算例，不是运行账单。K 表示 1,000 token；“输出”包含适用的计费推理 token。缓存读取行假设已经命中有效缓存，先前的写入费另计；暂不计工具、运行环境、税费和网关费用。

这些算例保持三款模型的 token 数相同。真实任务中，推理长度、工具往返和重试次数都可能不同，需要根据完整使用记录比较。

第三行最能说明“缓存半价”的实际影响。以 6.1 Sol 为例：

0.20 × $0.10 + 0.02 × $2 + 0.01 × $10 = $0.16。

旧 Sol 在同样假设下是 $0.18。缓存读取降价 50%，这个请求的总 token 费用只下降约 11.1%。 输出与新增输入没有降价，所以整单节省比例会小得多。

如果把首次写入也算进去，第二行发生一次，第三行发生十次，6.1 Sol 总费用为 $2.24，旧 Sol 为 $2.44，节省约 8.2%。这是同一缓存前缀保持有效且十次全部命中的假设；实际效果要看使用记录。

缓存文档（英文）还明确指出：缓存写入费率是该部分输入的计费方式，不能再给同一批 token 叠加普通输入费。输入应按未缓存、读取、写入分类计算，避免重复计费。

长上下文和推理也会改变账单

6.1 Sol 的输入超过 272K token 时，整个请求的输入与缓存费率变为 2 倍，输出费率变为 1.5 倍。加价覆盖整个请求，并非只对超出部分生效。

因此，300K 未缓存输入加 10K 输出，要按 0.30 × $4 + 0.01 × $15 = $1.35 计算。缓存输入也属于请求输入，不能只拿新增的那一小段判断是否跨过阈值。

此外，推理 token 按输出计费（英文）。更高推理档位的收益需要与实际使用量一起看。Fast 模式的单价为 Standard 的 2 倍，Batch、Flex 为其一半；这些是价格规则，不能据此推导完成速度。

真正适合团队比较的指标，是“所有尝试的费用 ÷ 最终通过验收的任务数”，并另行记录工具费用和人工返工时间。一个单次请求便宜但经常需要重做的方案，未必更省预算。

从 GPT-6 Sol 升级，先检查三个兼容性变化

这部分直接影响现有编程 Agent 能否运行。官方 GPT-6 使用指南（英文）列出了推理与接口要求。

第一，检查 none 推理档位。 旧 Sol 支持 none，6.1 Sol 不支持 none 或 minimal。原先显式关闭推理的请求，需要改用受支持的档位，并重新检查延迟与用量。API 默认是 medium，具体客户端默认设置还应在客户端确认。

第二，检查工具调用走哪个接口。 旧 Sol 在 reasoning_effort: "none" 时，可以通过 Chat Completions 调用函数；6.1 Sol 的工具调用需要使用 Responses API。它仍支持无工具的 Chat Completions 请求。现有 Agent 如果依赖前一种组合，升级范围就不只是改模型 ID。

第三，检查旧的采样参数。 官方指南要求在非 none 推理下移除 temperature、top_p 等不受支持的参数。确认 SDK、请求模板或网关没有继续默认注入这些字段，再测试完整工具流程。

对直接使用 Codex CLI 的读者，官方给出的选择方式是：

codex --model gpt-6.1-sol

已有交互会话也可以通过 /model 切换。该命令来自官方模型文档（英文），本次未执行账号调用；是否可选取决于账号、客户端及工作区设置。

现在能在哪里使用？

根据首发开放说明（英文），GPT-6.1 Sol 的开放范围包含 Plus、Pro、Business、Enterprise 和 Edu 的指定 Work / Codex 入口。Enterprise、Edu 默认关闭，需要管理员启用；Free、Go 不在首发范围内。

在 ChatGPT 产品中，它进入的是 Work 和 Codex，首发时尚未进入普通 Chat。具体可选速度模式以账号、客户端和工作区配置为准。

使用费用还要看登录方式。官方定价说明（英文）将 API 计费与订阅使用量分开，Codex credits 也没有单独的缓存写入收费。前面的 API 算例适合估算 API 调用，不能拿来换算一个订阅能完成多少任务。

如何判断它是否值得成为你的默认模型

我会先用一组小规模、可验收的任务对照。下面是建议的验证方法，本轮未执行：

1. 选六个任务。 两个已有失败测试的 Bug、两个有明确验收条件的跨文件修改、两个需要引用证据的文档分析。冻结代码版本和材料，预先写好验收标准。
2. 先统一条件。 三个模型都从 medium 开始，使用相同提示、工具权限、环境和重试预算；每个任务重置工作区并独立运行三次，避免仅凭一次表现判断。
3. 分别记录结果与代价。 检查验收是否通过、是否遗漏约束，同时记录输入、缓存、计费输出、全部尝试耗时和人工修改。失败运行也计入费用；如果没有一次通过，就记录“无通过结果”，不能记成成功成本为零。
4. 再调档位。 在第二轮中，为各模型寻找达到质量要求的较低成本设置。把这一轮与“相同档位”的结果分别记录，避免比较口径混淆。

这个规模适合作为升级试跑，不能推导通用成功率。只有当 6.1 Sol 在你的任务上达到质量要求、总费用也更合适时，才有充分理由将它设为默认。

对旧 Sol 用户，我会优先验证 6.1 Sol。 它保留相同标准输入、输出单价，同时带来更低的缓存读取费和官方报告的能力提升，升级试跑的理由很充分。

对 Astra 用户，我会按任务决定是否迁移。 频繁执行、可以明确验收的工作值得做成本对照；要求苛刻、失败代价高的工作，则继续比较最终质量和人工返工。能稳定完成多少有用的工作，才决定省下的 token 费用是否真正有价值。

如果还需要旧版本背景，可以阅读 旧版 GPT-6 Sol 评测和 旧版 Sol 与 Astra 的比较。这两篇讨论的是旧 Sol，不能将其中的成绩直接当作 6.1 Sol 的表现。

OmniaKey 当前显示的路线和报价见模型目录。官方发布状态不代表每条网关线路都已提供该模型；本文引用的 OpenAI 原始资料均为英文。