Michael Johnson针对同一个代码库的请求可能需要多次尝试：智能体提出补丁、运行测试，然后修复错误。令牌价格低，并不能单独回答最关键的问题：得到一项可接受的更改要花多少钱。
截至2026 年 10 月 2 日，答案是：GPT‑6.1 Sol 的输入和输出令牌标准 API 价格为 GPT‑6 Astra 的五分之一。OpenAI 还表示，Sol 在一项智能体编程基准测试中达到了 Astra 的水平。但这并不能证明两者在 Codex 中整体表现相当，也无法保证最终补丁的成本能降低五倍。
首先区分 API 与 Codex 订阅
API 按实际使用的令牌计费。通过 ChatGPT 使用 Codex 时，适用的是工作计划包含的额度，因此不能直接套用 API 价格。OpenAI 说明，额度消耗取决于模型、任务和设置，而 API 则单独计费；详情见Work 和 Codex 使用说明。
下表列出了输入上下文不超过 272,000 个令牌时，每百万令牌的标准 API 价格：
| 模型 | 普通输入 | 缓存输入 | 缓存写入 | 输出 |
|---|---|---|---|---|
| GPT‑6.1 Sol | $2 | $0.10 | $2.50 | $10 |
| GPT‑6 Sol | $2 | $0.20 | $2.50 | $10 |
| GPT‑6 Astra | $10 | $1 | $12.50 | $50 |
| GPT‑6 Luna | $0.10 | $0.01 | $0.125 | $0.50 |
按普通输入和输出费率计算，Sol 的价格是 Astra 的五分之一，缓存输入的价格则是其十分之一。不过，与 GPT‑6 Sol 相比，新版本的普通输入和输出价格并未降低：它的定价优势在于缓存输入，价格减半。Luna 的价格远低于这三款模型，但价格低本身并不能说明它解决复杂任务的能力如何。上述费率见OpenAI API 定价页面。
相同的一次尝试要花多少钱
举个简单例子，假设一次请求包含20,000 个新输入令牌、80,000 个缓存令牌和 10,000 个输出令牌。假设缓存命中；不计缓存写入、工具调用和重试。
| 模型 | 计算 | 费用 |
|---|---|---|
| GPT‑6.1 Sol | $0.040 + $0.008 + $0.100 | $0.148 |
| GPT‑6 Sol | $0.040 + $0.016 + $0.100 | $0.156 |
| GPT‑6 Astra | $0.200 + $0.080 + $0.500 | $0.780 |
| GPT‑6 Luna | $0.002 + $0.0008 + $0.005 | $0.0078 |
按这种请求构成计算，Sol 的单次尝试成本约为 Astra 的五分之一。与 GPT‑6 Sol 相比，差额为 $0.008，约占单次尝试费用的5.1%。这只是算术示例，并非 Codex 典型任务的实测值：不同模型的令牌用量、工具调用次数和重试次数可能各不相同。
此外还有一个定价门槛：当输入上下文超过 272,000 个令牌时，整个请求的输入和缓存费率翻倍，输出费率则提高至 1.5 倍。因此，若上下文很长，上述计算就需要调整；具体条件见GPT‑6.1 Sol 模型页面。
与 Astra 的比较究竟证实了什么
在GPT‑6.1 Sol 发布公告中，OpenAI 表示，在DeepSWE v1.1——一项针对真实代码库中复杂工程任务的基准测试——上，Sol 达到了 Astra 的水平，成本约为后者的五分之一。准确的说法应当是：“根据 OpenAI 的数据，在 DeepSWE v1.1 上表现相当。”
在评估电脑操作任务的OSWorld 2.0上，Sol 在最高推理级别下比 Astra 低 2.1 个百分点。OpenAI 估算，每项任务的成本则约低七倍。该公司提醒，其评估是在研究环境或通过 API 进行的，实际生产界面的表现可能会因系统指令、工具和设置不同而有所差异。
这些结果由供应商自行发布，并非在相同 Codex 工作流程中对模型进行的独立测试。本文审阅的材料中，没有提供在相同 Codex 任务上对 Sol 和 Astra 进行的可比独立测试。
开发者怎么说
发布后的早期讨论可以作为在自己环境中测试模型的理由，但并非具有代表性的评测。在一个讨论速度和额度消耗的 Reddit 帖子中，用户抱怨生成速度慢。一位发帖者称，简单操作或压缩上下文至少花了两分钟。这些只是个别观察，任务并不相同，条件也未经控制。
在另一场关于 Sol 速度的讨论中，参与者意见不一：有人认为生成缓慢是个问题，也有人指出，单看令牌输出速度，并不能说明整个任务需要多长时间。这是不同的指标，而该讨论并未对其中任何一项进行受控测量。
还有一则关于尝试制作游戏演示的负面反馈：发帖者称模型遗漏了要求，并且在收到补充说明后仍未修复重大缺陷。这不能衡量模型的整体质量，也没有直接与 Astra 对比。
最后，在一则关于 VS Code 扩展中选择模型的 GitHub issue中，用户于 9 月 30 日报告称，桌面版 Codex 能看到 Sol，但 Windows 上扩展的模型列表中没有它。这是对特定配置的描述，既不能确定问题原因，也不能说明其影响范围。
这些帖子的发帖者使用的是化名，无法核实身份，因此本文不提供据称有真实姓名佐证的直接引语。对这些早期反馈，务实的结论应更为有限：质量、任务完成速度和额度消耗都需要分别衡量。
简要时间线
- 2026 年 9 月 3 日。OpenAI 发布 GPT‑6 Astra。
- 2026 年 9 月 22 日。GPT‑6 Sol 和 GPT‑6 Luna 在 API 中推出。
- 2026 年 9 月 29 日。OpenAI 宣布 GPT‑6.1 Sol 面向 API、ChatGPT Work 和 Codex 发布。
- 2026 年 9 月 30 日。GitHub 上出现一则报告，称 Windows 上 VS Code 扩展的模型列表中没有 Sol。
发布时间见OpenAI API 更新日志；关于 VS Code 的报告则见具体的GitHub 讨论。这是一份早期时间线，并非对所有用户模型可用性的评估。
什么时候选 Sol，什么时候选 Astra
对于 Plus 和 Standard Business，OpenAI 给出的参考范围是：Sol 每个五小时窗口内可进行15–160 条本地消息，Astra 则为5–45 条。这并非保证能完成的任务数：额度消耗取决于模型、任务和设置；云端任务可能消耗更多额度，也可能适用每周限制。这些估算不能转化为节省比例，也不能直接与 API 价格比较；相关条件见Work 和 Codex 额度说明。
实际选择取决于错误代价和等待时间：
- 值得测试 Sol，用于结果易于检查的重复性任务——例如有测试和明确验收标准的任务。它的标准 API 价格远低于 Astra。
- 复杂或高风险任务可以继续使用 Astra，因为这类任务的结果质量可能比单次尝试的成本更重要。至于它是否更适合团队的具体任务，需要实际测试。
- 简单的重复操作可以考虑 Luna，前提是其质量足够。令牌价格最低，并不能证明使用该模型处理复杂工作总成本更低。
要进行比较，可以在各模型上运行同一小组任务，并提前定义什么结果才算合格：例如测试通过、符合要求并通过代码审查。记录尝试次数、令牌用量、工具调用次数，以及得到最终补丁所需的时间。这样衡量的是结果成本，而不是单次回答的价格。
结论：Sol 的常规 API 输入和输出令牌价格确实只有 Astra 的五分之一；OpenAI 表示，在一项智能体编程基准测试中，两者结果相当。但目前没有足够证据证明它们在 Codex 中整体表现相当。订阅用户无法直接享受 API 价格带来的节省，而开发者的早期反馈仍零散且相互矛盾。Sol 是一个有理由考虑的、更经济的候选方案，但是否用它取代 Astra，取决于两款模型在你团队任务上的实际表现。