GPT-6 Astra 推理强度：max 同答案成本是 low 的 2.3x

在 GPT-6 Astra 上，reasoning_effort: "max" 的成本是 low 的 2.3x，但在 11 个已验证任务中，两者每次都给出了相同答案。只有 none 会影响准确率：11 个任务各运行 3 次，共 33 次，其中失败 17 次。reasoning_effort 是一个请求参数，用来控制模型回答前进行多少隐藏推理。这些推理会按输出价格计为 reasoning token。本文测试了从 none 到 max 的所有档位。实际档位与文档不一致：API 自身的输入校验列出了 7 个值，其中 minimal 在所有模型上都会被拒绝，而校验结果从未提及的 disabled 却能在 Astra 上使用，并且根本不会禁用推理。理解 OpenAI 发布时公布的 benchmark 数据时，这一点很重要。官方称结果取“所有推理强度中的最高值”，因此排行榜上的分数来自成本最高的档位。

TL;DR

• GPT-6 Astra 接受 7 个 reasoning_effort 值，包括 none 和 disabled；文档只列出 5 个，并称不支持 none。
• 只有 none 会将 reasoning token 降到 0，但它在 33 个已验证运行中失败了 17 次；其他档位均为 33 次全部正确。
• disabled 消耗 243 个 reasoning token，low 只消耗 151 个；准确率相同，但前者每个正确答案的成本高出 54%。
• 按标价计算，在两个模型都能答对的任务上，GPT-6 Astra 使用 low 时，每个正确答案的成本是 GPT-5.6 Sol 的 1.57x；使用 max 时则是 2.57x。

GPT-6 Astra 的 benchmark 表现如何？

在智能体类任务上领先。这类任务通常由模型循环调用工具，很多时候是在终端中操作。但在 Humanity’s Last Exam 和 Artificial Analysis Intelligence Index 上，它落后于 Claude Fable 5.1。后者是由 10 项评测组成的独立综合指数。所有公布的分数都取自得分最高的推理强度。下表来自 OpenAI 的发布页面，对比列也由 OpenAI 选定：

看这些领先结果时，还要结合以下 3 点：

• 在 Humanity’s Last Exam 一项中，Astra 落后 Fable 5.1 达 7.8 分。这个结果只出现在表格中，正文完全没有提及。
• 在 OpenAI 自己的表格里，Artificial Analysis 一项上 Astra 落后于 Claude Fable 5.1、Claude Opus 5 和 Claude Fable 5；当前的 v4.2 排行榜中，Fable 5.1 得分 57，排名第一，Astra 得分 55，排名第三。
• OpenAI 明确表示，网络安全评测是在“没有生产环境安全防护”的条件下完成的；正式发布的模型“会拒绝”概念验证型漏洞利用任务。

表格下方这句话直接关系到最终账单：“评测分数取所有推理强度中的最高值。”Artificial Analysis 排行榜会分别列出同一模型在各个推理强度下的结果。Astra 在 xhigh 下得分 54，在 max 下得分 55。本文接下来会计算这个分数对应的成本。

GPT-6 Astra 接受哪些 reasoning_effort 值？

一共 7 个，但与 API 宣称支持的集合并不一致：有一个对外宣称支持的值会被所有模型拒绝，还有一个能够使用的值从未出现在任何说明中。模型页面列出了 low、medium、high、xhigh 和 max，并明确表示该模型“不支持 none 推理强度”。API 与文档有两处冲突，内部校验之间也有一处冲突。

发送一个无效值时，第一层校验会在请求进入模型之前检查请求结构。无论使用 GPT-6 Astra 还是 GPT-5.6 Sol，返回的允许值列表都相同：

Invalid value: '__invalid__'. Supported values are: 'none', 'minimal', 'low', 'medium', 'high', 'xhigh', and 'max'.

接着逐个发送这些值，模型专属的第二层校验会拒绝第一层声称支持的部分取值。200 表示请求成功，400 表示请求被拒绝：

因此，文档声称不支持的 none 实际可用；对外宣称支持的 minimal 在所有模型上都会被拒绝；只有 Astra 接受 disabled，但任何列表里都没有这个值。错误消息还暴露了 gpt-6-astra alias 当前指向的带日期构建版本：gpt-6-astra-2026-09-03。

none 和 disabled 会关闭推理吗？

none 会关闭推理，而且只有它能做到。disabled 只是一个名称容易误导的普通档位。我们先在本地通过穷举计算了 11 个任务的答案，确保答案表不会出错。这些任务包括连续应用同一规则 40 次、满足 3 个约束的计数问题、背包问题、进制转换、7 的 222 次方对 1000 取模，以及另外 6 个较短的任务。随后通过兼容 OpenAI Chat Completions API 的 endpoint，在全部 7 个推理强度下测试，每个任务和档位运行 3 次。Sol 会拒绝 disabled，因此只测试了 6 个档位。以下是 GPT-6 Astra 在最难的 5 个任务上的结果：

每个正确答案的成本，是一个任务与推理强度组合的总支出除以正确运行次数。如果某个设置的正确率只有 20%，平均就要支付 5 次运行的费用才能得到 1 个正确答案。准确率断层只跨了一个档位。在两个模型上，从 low 往上的所有档位，11 个任务共 33 次运行全部正确。none 在 Astra 上只答对 33 次中的 16 次，在 Sol 上答对 21 次。在迭代映射任务中，Astra 连续 3 次给出了 3 个不同的错误数字。这里没有可供微调的渐进式退化：要么开启推理，要么模型只能猜。

disabled 才是陷阱。它消耗的 reasoning token 比 low、medium 和 high 都多。在准确率同为 100% 的情况下，它每个正确答案的成本比 low 高 54%。只有 xhigh 和 max 的每个正确答案成本高于这个名字看起来像是关闭推理的值。

max 相比 low 能带来什么？

在这些任务上没有任何收益，但价格是 2.3x：每次调用分别为 $0.01946 和 $0.00851，准确率都为 100%。reasoning token 从 low 的 151 个升到 max 的 370 个，并且全部按每百万输出 token $50 计费。

这个数字要与 benchmark 表一起看。“评测分数取所有推理强度中的最高值”意味着每项分数都来自得分最高的档位。在独立排行榜上，Astra 的最高分来自 max，比 xhigh 高 1 分；根据我们的档位测试，max 的成本是下一级的 1.3x。如果工作负载与发布时的 benchmark 相似，额外推理可能物有所值。如果工作负载与我们的任务相似，就不值得。判断方法是先用 low 测量自己的任务。

GPT-6 Astra 每个答案的价格是 GPT-5.6 Sol 的 2.5x 吗？

使用 low 时不是，而是 1.57x。使用 max 时是，为 2.57x。标价是供应商自己页面上的每 token 价格。Astra 的价格为每百万 token 输入 $10、输出 $50，Sol 为输入 $4、输出 $20。这些数据来自 2026-09-07 的 OpenAI Astra 和 Sol 模型页面。因此，两者的输入和输出标价差距都是 2.5x；[GPT-5.6 Sol 与 GPT-6 Astra 对比页面](/compare/models/gpt-5-6-sol-vs-gpt-6-astra/)提供实时目录价格。下表根据 11 个任务的 token 数量和标价计算每个正确答案的成本。两个模型从 low 往上均为 33 次全部正确：

在较低档位下，Astra 用更少的 reasoning token 得到了相同答案。在 11 个任务中，使用 low 时，Astra 每次调用平均消耗 91 个，Sol 为 158 个，因此缩小了价格差距。随着档位提高，Astra 的推理消耗增长更快。使用 max 时，Astra 为 249 个，Sol 为 242 个，此时每个答案的成本差距回到了完整的标价差距。

这个结论的适用范围很窄：两个模型从 low 往上都达到 100% 正确率，因此这组任务无法区分模型能力，只能比较它们都能答对时的答案价格。仅调整一个参数，差距就会从 1.6x 变到 2.6x。OpenAI 的发布页面显示，智能体任务上的结果正好相反：在 Terminal-Bench 4.0 上，Astra 的“每项任务预计 API 成本”比 Sol 和 Fable 5.1 分别低约 9% 和 63%。如果一个模型能用更少的 token 解决更多任务，即使每 token 单价更高，总成本也可能更低。不同工作负载的结果不同，但推理强度都会直接影响账单。

JSON schema 或工具调用会增加推理成本吗？

使用 low 时不会，使用 medium 时会。我们用 3 种形式发送了一个单步骤任务，也就是在 08:15 的基础上加 2 小时 37 分钟：直接提问、放入严格的 response_format JSON schema 中（回复必须是符合指定结构的 JSON），以及强制工具调用（通过 tool_choice 固定到一个函数，模型必须调用该函数作答）。共测试 4 个推理强度，每种形式和强度运行 3 次。下表是 GPT-6 Astra 的平均 reasoning token、其占全部计费输出 token 的比例，以及每次调用成本：

low 可以缩减到 0。在无需多步处理的任务上，它不消耗 reasoning token，成本与 none 相同；在上面的多步骤任务集中，它每个任务消耗 16 到 345 个 token，并在 none 大量出错时保持正确，因此 low 是最低可用档位。外层格式本身并不是主要成本来源：使用 low 时，schema 或工具调用只增加 0 到 4 个 reasoning token；使用 medium 时，即便任务无需推理，直接提问和 schema 形式的 reasoning token 也分别占输出 token 的 67% 和 57%，工具调用中则占 18%。在 schema 中，同一项提取任务使用 medium 的成本是 low 的 1.6x；直接提问时则为 2.2x。7 月发布的 GPT-5.6 成本指南也发现该系列模型存在同样的成本杠杆。Sol 的变化更平缓：无论推理强度如何，直接提问和 schema 都不消耗 reasoning token；强制工具调用从 medium 往上消耗 14 到 18 个 token。

能看到自己付费购买的推理内容吗？

OpenAI 的两个 API 接口中，只有一个可以。较旧的 Chat Completions endpoint 和较新的 Responses endpoint 接受相同模型，计费方式也相同。我们在 medium 下向两个接口发送同一个问题，每个接口运行 3 次：

两组 token 数量处于正常波动范围内，因此计费方式相同，区别只在于能否看到自己付费购买的内容。输出价格为每百万 token $50，能否查看取决于 endpoint。文档还要求工具调用使用 Responses（“GPT-6 Astra 支持 Chat Completions，但工具调用必须使用 Responses”），因此需要使用工具的工作负载必须进入可查看推理摘要的接口。

GPT-5.6 的哪些行为延续到了新模型？

大部分 API 契约都保持不变。实测结果如下：

• Tokenizer。 同一篇 900 词文本，在 GPT-6 Astra、GPT-5.6 Sol、GPT-5.6 Luna、GPT-5.5、GPT-5.4 和 GPT-5.2 上都被编码为 1,017 个 prompt token。此前为 5.x 测量的 prompt 大小仍适用于 Astra，无需重新计算。
• 参数。 temperature 在 Astra 和 Sol 上都会返回 400（“not supported with this model”），top_p 和 logprobs 也是如此；使用严格 JSON schema 的 response_format 会在两个模型上返回符合 schema 的输出；低于 16 的 max_tokens 在两个模型上都会被拒绝。
• Sol 上的 max。 7 月时，通过 Chat Completions 向 GPT-5.6 Sol 发送 reasoning_effort: "max" 会返回 400。现在它已经可以使用，Sol 在该档位下 33 次全部正确。

以下数据来自文档，本文未做实测：context window 为 1,050,000 个 token，最大输入为 922,000 个，最大输出为 128,000 个；当 prompt 超过 272K 个输入 token 时，输入和 cache 费率按 2x 计费。GPT-5.6 系列采用相同阈值，我们也测量过不同供应商采用的同类机制；cache 读取价格为每百万 token $1，cache 写入价格为 $12.50。新的 prompt_cache_options.ttl: "30m" 参数取代了 prompt_cache_retention。Fast mode 是付费选项，OpenAI 称其速度最高可达 2x，价格也是标准模式的 2x。

Synthorai 如何处理这些参数

gateway 会原样传递 reasoning_effort，包括文档没有列出的值。每次请求的 usage 记录会在 completion_tokens 和计费成本旁单独保存 reasoning_tokens 字段。上面的所有表格都基于这些数据生成：请求使用的推理强度、实际消耗的推理量及其成本都可以逐请求查看，无需从月度总账中反推。

FAQ

GPT-6 Astra 支持 reasoning_effort none 吗？

支持。文档称不支持，但 API 在 GPT-6 Astra 和 GPT-5.6 Sol 上都会接受该值，而且只有它能让 reasoning token 变为 0。不过，在一组已验证任务中，它在 33 次运行里失败了 17 次。因此，它适合查询和转换任务，不适合任何包含多步骤处理的任务。

reasoning_effort disabled 在 GPT-6 Astra 上有什么作用？

它仍然会推理。GPT-6 Astra 接受 disabled，GPT-5.6 Sol 则会拒绝。任何文档或 API 声明列表中都没有这个值。在我们的困难任务集中，它每次调用消耗 243 个 reasoning token，而 low 只消耗 151 个，两者准确率完全相同。应把它视为某个中间档位的昂贵 alias，而不是关闭开关。

GPT-6 Astra 默认应该使用哪个 reasoning_effort？

low。在 GPT-6 Astra 上，它处理单步骤任务时不消耗 reasoning token，处理多步骤任务时每个任务消耗 16 到 345 个 token。在 none 只答对 33 次中的 16 次时，low 达到了 33 次全部正确；max 给出相同答案，但成本是它的 2.3x。只有当自己的 eval 证明更高档位能改变结果时，才应提高特定调用点的推理强度。每次调用都应显式设置该值，并从 usage block 中读取 reasoning token 数量：

resp = client.chat.completions.create(
    model="gpt-6-astra",
    reasoning_effort="low",
    messages=[{"role": "user", "content": prompt}],
)
print(resp.usage.completion_tokens_details.reasoning_tokens)

测量时间为 2026-09-07。主要通过兼容 OpenAI 的 Chat Completions 接口测试，另使用 Responses endpoint 对比推理可见性。测试包含 11 个任务，答案均在本地通过暴力求解得到；共测试 7 个推理强度，两个模型的每个组合均运行 3 次；prompt 加入随机盐值，每次请求带有唯一后缀，避免从 cache 返回回复；成本取自逐请求 usage 计费记录。Benchmark 数据来自 OpenAI 发布表格和 Artificial Analysis 排行榜，两者均在同一天获取。与 GPT-5.6 Sol 对比的每个正确答案成本，根据各推理强度的 token 数量和各模型文档标价计算。

相关阅读：13 个模型的推理控制方式、GPT-5.6 成本指南、Claude Opus 5 成本、长上下文分级定价、prompt cache 写入成本。

← 返回博客