GPT-6.1 Sol 面向编程智能体：基准、定价与适用场景

GPT-6.1 Sol 是 2026 年 9 月 29 日对 GPT-6 Sol 的升级，而 OpenAI 给出的卖点是一次明确的取舍，而非新的性能天花板：在智能体编程、计算机操作和专业工作上接近 GPT-6 Astra 的表现，标准输入与输出 token 价格却只有 Astra 的五分之一，缓存输入则为每百万 token 0.10 美元。标准 API 定价为每百万输入 token 2 美元、每百万输出 token 10 美元。该模型已上线 ChatGPT Work、Codex 和 API，模型标识为 gpt-6.1-sol，但尚未进入 Chat。

对智能体开发者而言，真正有用的问题比「它是不是更好」要具体得多：在哪些负载上，一个更便宜的准前沿模型确实能带来改善；又有哪些负载，缓存对成本的影响超过标价本身的降幅？ 本文会逐条梳理已公布的数字、它们的确切配置，以及决定结论的那套算术。下文所有性能数字均来自 OpenAI 的自报数据；截至 2026 年 9 月 29 日，资料来源中不存在任何针对 GPT-6.1 Sol 的独立复现，我们如实说明这一点，而不含糊带过。

究竟改变了什么

这里涉及三个模型，它们处在价格-性能曲线的不同位置：

GPT-6 Astra 是前沿模型。OpenAI 自己的建议是：在「质量最重要」时选择 Astra。

GPT-6.1 Sol 是 GPT-6 Sol 的升级。OpenAI 将其定位为「五分之一价格的准 Astra 智能」，并明确指出它在智能体编程、计算机操作和专业工作三条轴上缩小了差距。按其官方建议，它是用于「你希望更频繁运行的复杂工作」的模型。

GPT-6 Luna 仍是用于高并发简单任务的低价、高速之选。

OpenAI 还表示，GPT-6.1 Sol 在对齐评估上相较 GPT-6 Sol 有所升级、更接近 Astra，并且没有观察到它试图绕过自动安全审查——这与 Astra 和 GPT-6 Sol 一致。这些说法均为厂商自报，并附有明确的前提说明：这些评估刻意设计了具有挑战性的情境，并不测量常规使用下的失败率。

对任何运行长时间智能体循环的人来说，影响最大的变化不是分数的提升，而是缓存输入费率。OpenAI 称每百万缓存输入 token 0.10 美元，比标准输入定价低 95%，比 GPT-6 Sol 的缓存输入定价低 50%。从后一个说法反推，GPT-6 Sol 的缓存输入为每百万 token 0.20 美元。这个推导是基于 OpenAI 所给百分比算出来的，并非单独公布的数字。

决定负载归属的定价表

OpenAI 随发布一并公布的三模型价格卡给出了全貌。价格均为每百万 token。

把这张卡当作一个整体来读，它说出了单一头条数字掩盖的东西。Sol 的输入价是 Astra 的五分之一，输出价也是 Astra 的五分之一，这正是 OpenAI 点名的两个费率下「五分之一价格」的含义。但它的缓存输入价是 Astra 的十分之一，而不是五分之一。缓存侧的折扣比两个标准费率更陡，而这正是一个拥有稳定前缀的智能体循环收益最大的地方。

基准与它们的确切配置

基准表通常会抹掉那个决定数字是否可比的细节。下表把配置和前提说明放在同一行，因为其中若干结果取决于被比较模型之间不同的推理强度设置。

有两行需要展开，因为随手一读最容易在这里读错。

DeepSWE 的比较是把处于高推理强度的 Sol 与处于最高强度的 GPT-6 Sol 放在一起。6.4 分的差距（75.2% 对 68.8%）是真实的，但它并不能说明两个模型在同一强度下会如何。OpenAI 的措辞——Sol「以更低的推理强度和成本」超越了 GPT-6 Sol 的最好成绩——才是这个说法的准确版本。

AutomationBench 这一行带有一条对成本比较很关键的脚注。OpenAI 报告称，该图表上 Claude Fable 5.1 的数据点低估了竞争对手的实际成本，因为它省略了 fallback 的成本，而 fallback 在约 40% 的任务上发生。这条披露的方向不利于 OpenAI 自身，因而值得照单全收：已公布图表上的 Fable 5.1 数据点并不是公平的同等成本对比。

缓存输入在哪里改变了算术

这是发布材料中任何基准表都没有捕捉到的部分，而对智能体来说，正是它决定了账单。

取一个有代表性的长时间智能体循环。它会在 40 次模型调用中的每一次都重发 50,000 token 的稳定前缀——系统提示、工具 schema、仓库上下文、风格规则——并每次产出 1,500 个输出 token。这样每次运行是 2,000,000 输入 token 和 60,000 输出 token。

仅使用上文公布的每百万 token 费率，总计为：

这套算术是我的，不是 OpenAI 的，它依赖两个值得明说的假设：前缀确实可缓存且在多次调用间保持稳定；该负载由这个前缀主导，而不是由新增输入主导。改动其中任一假设，差距都会向 5 倍标准费率比收窄。这里没有任何基准结果，它只是一个基于公布价格构建的成本模型。

对齐与部署说明

OpenAI 的部署部分简短而具体，值得与能力声明对照阅读，因为两者使用的度量基准不同。

透明性评估测试的是智能体在搜索工具损坏时，是告诉用户实情，还是凭空猜测。GPT-6.1 Sol 在 2.1% 的情况下未披露，相比 GPT-6 Sol 的 4.9% 和 Astra 的 1.5%。该评估设定为最高推理强度，且任务被特意挑选以诱发失败，因此这个数字是压力测试结果，而非预期错误率。

计算机操作安全压力测试记录的不当结果率为：Astra 2.4%、GPT-6.1 Sol 4.3%、GPT-6 Sol 17.4%、GPT-6 Luna 13.7%。在该图表上越低越好，而排序才是有用的部分：在一项 OpenAI 称之为刻意具有挑战性的评估中，Sol 明显优于它所取代的模型，仅略落后于前沿模型。

OpenAI 还表示，没有观察到 GPT-6.1 Sol 试图绕过自动安全审查，与 Astra 和 GPT-6 Sol 一致。完整细节见 GPT-6.1 Sol 系统卡附录，发布页给出了链接。

这一切都没有经过独立验证。它是厂商对自家模型的评估，按这类部署的要求予以公布，也应按这个定位来阅读。

哪些智能体技能负载适合

从这些数字可以推出三种负载形态，每一种都能对应到注册表中已有的条目。

拥有稳定前缀的长上下文编程循环。 这是证据最充分的场景。DeepSWE 衡量的是真实代码库中的软件工程，缓存输入费率是表中最陡的折扣，而更便宜模型的失败模式会表现为重试，而非悄无声息的错误输出。为这种形态打造的注册表条目包括 codex（Codex 侧的工作流）和 coding-agent（通用的「委派并复核」模式）。

错误动作可回滚的多步骤工具工作流。 AutomationBench 衡量的正是这一点，而中等强度下 31.7% 的得分，并不足以支撑在不可逆步骤上进行无人值守执行。对应到「人在回路」那一半的注册表条目是 code-review，因为正是复核这一步在合并之前抓住智能体那种自信但错误的改动。

计算机操作与桌面自动化。 这里的基准是 OSWorld 2.0 的离线集，Sol 在最高强度下的 71.4% 对 Astra 的 73.5%，是表中最窄的差距。如果你的负载是在应用程序间点击操作，那么在 OpenAI 的测量中，Sol 以约为 Astra 七分之一的单任务成本接近前沿水平。computer-use-agents 覆盖了这种控制模式。

有两种负载形态并不适合。已经在 Luna 上足够便宜的工作应当留在 Luna；没有理由把一次分类任务往上抬一个价格档。而单个错误答案代价高昂的工作——也就是 OpenAI 自己在 Terminal-Bench Science 上会交给 Astra 的那类任务——应当保留前沿模型。

要衡量你自己的负载而不是信任发布表格，benchmark-harness 和 evaluating-llms-harness 是用于构建可复现比较的注册表条目，而 ai-cost-optimizer 则是把结果转化为预算的那一个。

在你自己的仓库上测试 Sol

厂商基准告诉你哪个模型在别人的任务集上胜出。它不会告诉你 Sol 是否能以更低的单次完成成本完成你的重构——而那才是唯一能改变预算的数字。下面的测试设计为在一个下午内完成，无需搭建新的基础设施。

挑选十个你已完成的任务。 使用真实已合并的改动，而非合成提示，因为这里最重要的基准——真实代码库中的软件工程——恰恰是仓库特定上下文主导模型质量的那类工作。十个足以看出方向，但不足以公布一个百分比，也不该被描述成百分比。

用固定配置把每个任务跑两遍。 一次用 GPT-6.1 Sol，一次用你当前使用的模型。保持测试框架不变：相同的提示、相同的工具集、每个模型相同的推理强度设置、相同的仓库版本。唯一值得刻意变动的因素是前缀布局，因为缓存输入费率就藏在那里。

每个任务记录四个数字，而不是一个。 任务是否完成、实际耗时、拆分为缓存输入／未缓存输入／输出的总 token 数，以及复核结果所花的人工分钟数。单次完成成本 = token 成本 + 按你自己的费率折算的复核时间；一个每 token 更便宜、却产出你需要重写改动的模型，在实践中反而更贵。

确认缓存真的生效了。 这是最常被跳过的一步。如果你的账单显示输入 token 按标准费率而非缓存费率计费，那么前缀在多次调用间发生了变化，折扣没有生效。在连续轮次记录请求体的哈希：如果它变了，说明前缀里有东西在被重新生成，而这是技能里可修复的 bug，不是模型的固有属性。

保留一组你预期 Sol 会失败的任务。 其中包含两三个需要前沿模型的任务——那种 OpenAI 自己会交给 Astra 的困难单次推理或科学工作流。如果对比里只有便宜模型能解的任务，得到的结果经受不住与生产环境的接触。

在改动技能时重复运行，而不是在改动模型时。 智能体技术栈里有意思的变量通常是模型周围的提示与工具设计，所以固定模型、针对技能迭代，直到完成率稳定，然后再换一次模型。这个顺序能把模型选择从你自己的结果中排除为混杂因素。

对一个已有的智能体技能安装来说，迁移很小。把技能的模型标识指向 gpt-6.1-sol，把前沿模型保留为技能标记为高风险的任务的升级目标，并重新建立你的 token 记账基线，让缓存与非缓存输入分开记录。如果你的技能有固定的系统提示和工具列表，可以预期这是一次直接的成本下降；如果它在每轮都重建上下文，那么在修好前缀之前，价格会一直贴近 2 美元的标准费率。

发布材料没有说明的内容

有四个空白值得点出，因为每一个都会改变规划决策。

没有上下文窗口或知识截止日期。 GPT-6 Astra 的发布同时公布了这两项。GPT-6.1 Sol 的发布页两者都没有说明，因此任何引用 Sol 上下文窗口的摘要都是在编造。

没有独立复现。 上文每个数字都来自 OpenAI 的发布页或 OpenAI 自己的账号。截至访问日期，资料来源中不存在针对 GPT-6.1 Sol 的 DeepSWE v1.1、AutomationBench 或 OSWorld 2.0 第三方测试框架运行。在通常会放独立数字的地方，本文说明并不存在这样的数字。

没有 GPT-6.1 Sol Ultrafast 的日期。 发布页称 Sol 的 Ultrafast 将在「未来几天」到来，在 Codex 中 token 生成速度相比标准速度最多快 8 倍。没有给出日期。

没有绝对额度的 Pro 档位。 Pro 500 被描述为 ChatGPT Plus 额度的 25 倍，这是一个相对数字。如果你要按绝对 token 数做预算，发布材料并未提供一个。

还有一个发布材料没有回答的成本侧问题：缓存费率究竟适用于整个智能体轨迹，还是只适用于一个已声明的前缀。OpenAI 的表述是关于缓存输入的总体说法，实际答案取决于请求如何组织，因此值得在你自己的流量上测量，而不是假设最好的情况。

成本规划小结

如果你只从这个发布里带走一件事，请带走这个折扣的形态，而不是任何单一分数。GPT-6.1 Sol 在标准输入与输出上是 Astra 的五分之一，在缓存输入上是十分之一。在每一个已公布的轴上，它都严格优于 GPT-6 Sol。在错误答案代价高昂的任务上，它不是 Astra 的替代品，OpenAI 自己在 Terminal-Bench Science 的建议里也是这么说的。

务实的顺序是：把 Astra 留给最困难的单次决策，把拥有稳定前缀的高并发编程与工具循环迁到 Sol，把琐碎的分类留在 Luna，并在承诺预算之前测量你自己的完成率。缓存输入这个杠杆值得刻意去工程化，因为在任何前缀不变的负载上，它的价值都超过标价上的降幅。

Sol 并非孤立存在，同一次发布中还有两项内容与这个决策直接相关。面向智能体开发者的 DevDay 2026 回顾 介绍了 Agents API 的计算机操作新增能力，它让技能可以把任务委派给托管智能体；Ultrafast 与 Pro 档位成本规划 介绍的则是改变「每墙钟分钟成本」而非「每 token 成本」的速度档位。如果你还不熟悉这些智能体工作流是如何打包和安装的，请从什么是智能体技能？开始。

常见问题

GPT-6.1 Sol 多少钱？ 每百万输入 token 2 美元、每百万缓存输入 token 0.10 美元、每百万输出 token 10 美元。缓存费率被表述为比标准输入定价低 95%、比 GPT-6 Sol 的缓存输入定价低 50%。

GPT-6.1 Sol 比 GPT-6 Astra 更好吗？ 不是。OpenAI 把它定位为接近 Astra，而非高于 Astra，并建议在最困难的工作上使用 Astra——包括 Terminal-Bench Science 0.1 上的科学研究任务，Astra 在其中以 68.1% 保持受测模型中的最高分。

GPT-6.1 Sol 比 GPT-6 Sol 更好吗？ 在每一个已公布的轴上都是：更高的 DeepSWE 得分、更高的 AutomationBench 得分、更高的 OSWorld 2.0 结果、更低的事实错误率，以及更好的对齐评估。在每一个已公布的费率上，它也都比 Sol 和 Astra 更便宜。

GPT-6.1 Sol 在哪里可用？ 在 Plus、Pro、Business、Enterprise 和 Edu 用户的 ChatGPT Work 和 Codex 中，以及通过 API，标识为 gpt-6.1-sol。它尚未在 Chat 中提供。

这些基准经过独立验证了吗？ 没有。本文的每个结果都是 OpenAI 自报的。截至 2026 年 9 月 29 日，资料来源中不存在针对 GPT-6.1 Sol 的 DeepSWE v1.1、AutomationBench 1.0.6、OSWorld 2.0 或 Terminal-Bench Science 0.1 第三方测试框架运行。

缓存输入价格会自动适用吗？ OpenAI 把 0.10 美元的费率描述为缓存输入定价，并说明了它相对标准输入的折扣。某个具体请求是否符合条件取决于前缀如何组织，因此本文的成本模型是在既定假设下、根据公布费率作出的计算，而不是保证。

GPT-6.1 Sol 的 Ultrafast 是什么？ 该模型的一个更快服务档位，据称将在未来几天到来，在 Codex 中 token 生成速度相比标准速度最多快 8 倍。未公布日期。

资料来源

核对于 2026 年 9 月 29 日。

OpenAI —— 一手来源

• Introducing GPT-6.1 Sol —— 能力声明、基准名称、定价、可用性、对齐摘要
• DevDay 2026 Recap —— Sol 定位与官方发布素材
• GPT-6.1 Sol system card addendum (PDF) —— 由发布页链接
• @OpenAI on X —— 发布推文串、价格卡图片、计算机操作安全压力测试图表
• @OpenAIDevs on X —— DeepSWE v1.1、AutomationBench 与 OSWorld 2.0 数据、事实性图表
• Codex speed documentation —— 定义 Ultrafast 速度比较所衡量的内容

基准所有方（由 OpenAI 引用，并非为本文运行）

• Surge HQ — GDP.pdf
• Zapier — AutomationBench
• OSWorld 2.0