GPT-6 单 token 成本涨 2.5 倍，开发者总支出反而更省

GPT-6 Astra 的每 Token 成本是 GPT-5.6 Sol 的 2.5 倍——但开发者反而省了钱

OpenAI 的 Thibault Sottiaux 是 Codex 的工程负责人，上周末在 X 上发帖称："为了帮大家校准 Astra 使用哪种推理强度，了解一个事实即可：GPT-6 Astra 在 low 模式下的表现优于 GPT-5.6 Sol 在 high 模式下的表现。"Artificial Analysis 目前在智能指数上给 Astra-low 打 49 分，勉强领先 Sol-high 的 48 分。Astra-low 的响应也快得多，首 Token 到达时间仅 2.53 秒，而 Sol-high 需要 11.87 秒。

"为了帮大家校准 Astra 使用哪种推理强度，了解一个事实即可：GPT-6 Astra 在 low 模式下的表现优于 GPT-5.6 Sol 在 high 模式下的表现。"

推理强度的变化会改变费用

Astra 的输入 Token 价格为每百万 10 美元，输出 Token 价格为每百万 50 美元，而 Sol 当前的价格分别为 4 美元和 20 美元。将推理旋钮从 high 调到 low 不会改变这些费率，但会影响任务最终完成前完成多少工作——这是 OpenAI 在其迁移指南中明确提出的论点。公司表示，Astra 可以在使用更少输出 Token 的同时产生更强的结果。

OpenAI 用自己的基准测试作为证明。在 Terminal-Bench 4.0 中发现了相同的模式，Astra 得分 57.9%，Sol 得分 37.3%，但每个任务的成本反而低了约 9%。在 GPQA Diamond 上的差距更大：Astra 以 94.9% 对 94.6% 的微弱优势领先，但预估成本低了 37%。

实际工作负载会各有不同，但结果表明，仅看每个 Token 的定价并不能告诉开发者一个模型的实际运行成本——OpenAI 正在探索基于结果的定价（outcome-based pricing）正是基于这个理念。

Token 用得更少，任务更便宜

开发者 Shinpr 在同一个代码库上进行了对比，使用 Sol-high 和多个 Astra 推理级别，涵盖分析、实现和审查三个阶段。

Astra-medium 在时间和成本上都表现更好，实现阶段仅用了 80 次请求，不到 Sol-high 所需的 238 次的三分之一，处理了 1110 万输入 Token 而非 3780 万。到三个阶段全部结束时，Astra-medium 运行耗时约 51 分钟，成本预估 25.67 美元；Sol-high 运行耗时约 75 分钟，成本 31.79 美元。

将 Astra 调到 high 并没有帮助——那次运行耗时 77 分钟，成本 37.23 美元，而且 Shinpr 表示其审查漏掉了一个 medium 模式抓住的启动 Bug。

一个开发者的测试无法告诉我们 medium 是否适合每个工作负载，但确实表明在这里额外的推理并不值得付出代价。此外，这种模式并非处处适用。ARC Prize 的测试结果几乎走向了另一个方向。

将 Astra 调到 high 并没有帮助——那次运行耗时 77 分钟，成本 37.23 美元，而且 Shinpr 表示其审查漏掉了一个 medium 模式抓住的启动 Bug。

推理越多，账单越低

ARC Prize 对 Astra 的评估展示了问题的另一面。更多的推理不仅提高了 Astra 在 ARC-AGI-3 上的分数；在某些情况下，它还降低了成本。

使用 ARC Prize 的标准测试工具，Astra 在 low 推理下得分 17.5%，medium 下 38.6%，high 下 54.8%，max 下 62.7%。Astra 还有一个介于 high 和 max 之间的 xhigh 设置。但最昂贵的运行并非使用最多推理的那些。ARC Prize 在 low 花了 38,166 美元，medium 花 48,090 美元，high 花 40,705 美元。max 仅花费 26,098 美元。

在 max 级别，Astra 在每个决策上使用更多计算资源，但需要更少的操作来解决问题。这种权衡足以降低总体成本，这种情况在 Agent 中会出现。当较低的推理看起来更便宜时，一旦走错路很快就会产生另一次工具调用或另一次重试，其推理成本比一开始就解决错误更高。

当较低的推理看起来更便宜时，一旦走错路很快就会产生另一次工具调用或另一次重试，其推理成本比一开始就解决错误更高。

动态推理，不损失缓存

这是两个极端，开发者不需要在整个工作流程中选择其中之一，这要归功于 Astra 引入了 configuration_update 机制，允许应用程序在响应之间更改推理强度，而无需更改原始请求级配置。

常规工作可以保持在低推理级别，而失败的测试、意外的工具响应或困难的调试问题可以在下一轮触发更高的推理级别。一旦解决，Agent 可以降回来。

这也帮助解释了为什么 Shinpr 和 ARC Prize 得到了如此不同的结果。Shinpr 发现额外的推理增加了时间和成本而没有改善结果，而 ARC Prize 发现更多的推理有时会减少操作数量，从而降低总账单。

目前，configuration_update 仅适用于 Astra 的标准单 Agent 请求。不过，不要纠结于 Astra 2.5 倍的 Token 价格。如果一个昂贵的模型能用更少的调用次数完成任务、更少的尝试次数得到正确结果，它往往是更便宜的选择。