GPT-6 Astra：能力更新、使用方法与 GPT-5.6 Sol 成本对比

AI 参与说明（Agent：Codex）：本文由 Codex 根据 OpenAI 官方 API 与 Codex 文档协助调研、撰写和校验。价格核对于 2026-09-06，能力与使用指南补充于 2026-09-07；价格、可用性与产品行为可能变化。本文区分官方说明、算术示例与选型建议，未对两个模型执行 Ultra 实测。

GPT-6 Astra 的主要价值，是把持续推理、工具操作和任务协作结合起来，更好地完成复杂的完整工作流。适合交给它的任务包括较大的代码修改、多来源研究，以及需要按模板交付并校验的文档工作。使用时应提供目标、资料、约束和验收标准，再按实际难度选择 reasoning effort。Models

GPT-6 Astra 的 Standard API token 单价和 Codex credits 单价，均为 GPT-5.6 Sol 的 2.5 倍；一项 Ultra 任务的总成本则没有固定倍率。Ultra 会使用 subagents 并行处理复杂任务，总费用取决于所有参与模型的 token 用量、缓存、推理和工具工作。API Pricing、Codex Pricing、Models

本文将“GPT-5.6”明确为 GPT-5.6 Sol。官方 API 的 gpt-5.6 alias 指向 Sol；Terra 与 Luna 是不同的模型和价格档位，不应混在同一比较里。GPT-5.6 Sol

Astra 突出的能力#

以上是官方定位与行为说明，不能理解为所有任务均已得到独立实测保证。Using GPT-6 Astra

具体的浏览器、文件、终端与应用访问仍需要 Codex 等宿主提供工具。API 模型卡列出的原生输入是 text、image，输出是 text；通过工具生成图片或制作文件，应与模型原生输出模态区分。GPT-6 Astra 模型卡

这次 API 重点更新了什么#

下面列的是 GPT-6 Astra 的 API 更新。Codex 自身的交互功能有独立实现与发布节奏，不能把 API 新增控制都直接视为 Codex 新开关。

Computer use、Structured Outputs、Programmatic Tool Calling、multi-agent orchestration、prompt caching 和 persisted reasoning 等能力在 GPT-5.6 中已存在，Astra 继续支持它们。评估升级时，应分别看模型质量、执行控制与宿主集成。更新说明

已有 API 应用还要检查兼容性：Astra 不支持 none reasoning effort；工具调用要求 Responses API；自定义 temperature、top_p 与 log probabilities 不受支持。不能只替换模型名称就假定原有请求全部兼容。Migration quickstart

在 Codex 中怎样用好 Astra#

先定义结果和验收标准#

提供与任务直接相关的源码、资料、模板和约束，并说明怎样判断工作完成。例如，“完成分页功能，保留当前筛选行为，验证空列表与最后一页”，比只说“优化一下列表”更便于验收。这是基于官方任务指南的使用建议。Models

写清自主处理范围和提问时机#

Astra 更倾向于主动澄清。在已授权的工作中，可以明确让它对常规、可逆的细节采用合理假设并继续；遇到会实质改变目标、范围或交付结果的缺失信息再提问。需要最终确认的动作，先准备好可审阅的结果。这样的约定能减少无必要的停顿。Initiative and follow-through

按任务结构选 reasoning effort#

• Light / Low：目标明确、工作量小的任务。
• Medium：需要一定规划与判断的常规工作。
• High / Extra High：多步骤、多来源或取舍较复杂的任务。
• Max：希望给单个困难问题更多推理时间，能够接受更高耗时与用量。
• Ultra：有多个可独立执行的子任务，希望通过 subagents 提升速度或质量。

官方建议从能满足需求的最低 effort 开始。可并行的代码探索、测试和资料核查适合委派；多个代理同时修改相同文件会增加协调成本，应把写入范围划清。Models、Subagents

清理冲突规则，限制无效验证#

更强的指令跟随也意味着更容易受 AGENTS.md、Skills 中含糊或矛盾的要求影响。遇到反复停下来确认的情况，可以让它指出具体来自哪个文件、哪条要求，再修正规则。官方还提醒 Astra 可能测试得过于充分、回答过长或委派不足；可以直接规定必要验证、停止条件、回答长度和委派范围。Prompting best practices

在同一任务里及时纠正#

补充要求时，写清哪些目标继续有效、哪个条件发生变化，例如：“继续完成分页；刚才补充的要求是筛选条件改变后回到第一页。”Codex 的 Steer 与 Queue 分别对应运行中补充和等待当前工作结束后处理；这一产品交互不能全部归因为 Astra 新增的 API 功能。Steering and queuing

下面是一个原创的开发任务提示示例，可按实际项目修改后使用；它定义协作约定，不保证固定的效果或成本：

请为当前应用的列表页完成分页功能，并交付可审阅的代码改动。

资料与约束：先阅读现有列表实现和项目约定，复用现有技术与组件；
保持筛选行为和页面风格，筛选变化后回到第一页。

验收：覆盖空列表、第一页、最后一页及筛选后总页数变化的情况。

执行：在上述范围内，对常规可逆细节作合理假设并继续。
只有缺失信息会实质改变功能、范围或验收时才提问；同时推进不受影响的部分。
可将代码探索和边界检查交给子代理，集中整合修改，避免重叠写入。

验证：完成项目要求和与改动有关的检查；全部通过后，如没有新问题就结束验证。
本次交付本地代码改动，不包含线上部署。

最终答复：简述实现结果、验证证据和剩余问题，保持简洁。

API 价格#

下表为美元／百万 tokens，采用 Standard processing、输入不超过 272K tokens 的价格：

这些价格来自 API Pricing。Sol 当前为促销价，官方承诺至少持续至 2026-11-21，不应将当前价格视为永久承诺。

输入超过 272K tokens 时，整次请求进入 Long context 计费，而非仅对超出的部分加价。Standard 下，按普通输入／缓存命中／Cache writes／输出的顺序，Astra 为 20／2／25／75 美元，Sol 为 8／0.80／10／30 美元（均按百万 tokens 计），仍是 2.5 倍关系。Astra 计费说明、API Pricing

API Fast mode 为相应 Standard 价格的 2 倍；Batch 和 Flex 为 50%。工具调用等可能另计费用，本文数字不包含这些费用，也不包含区域处理附加费。API Pricing

Codex 中的 credits 和 Ultra#

通过 ChatGPT 登录 Codex 时，应看其 credits 费率和套餐额度。通过 API key 使用时，按 API 定价。两种口径不能直接互换。

以上为 Codex Pricing 的 token rates。Credits 的购买价格与折扣取决于套餐或协议；套餐内任务数量也受上下文、推理、工具调用和缓存影响，不能从表格推出固定的“每周 Ultra 次数”。

官方对两种高强度设置的解释是：Max 给选定模型更多时间深入推理，Ultra 使用 subagents 并行处理可拆分的复杂工作。每个 subagent 都执行自己的模型与工具工作，因此会增加相对于可比单代理运行的 token 消耗。官方没有列出一份独立的“Ultra 每次固定价”或统一的 Ultra 附加倍率。Models、Subagents

还要将 Ultra 与 Fast mode 分开：前者涉及任务并行，后者涉及模型执行速度与费率。在 Codex credits 口径下，Astra 与 Sol 的 Fast mode 都按各自 Standard 费率的 2.5 倍消耗；API Fast mode 则是前述 2 倍。Speed

若两边使用相同速度和上下文计费档位，所有主代理、子代理均使用各自比较的模型，且两边各计费类别的 token 数量相同，Astra 的模型费用就是 Sol 的 2.5 倍。实际 Ultra 运行可能采用不同的任务拆分、上下文与调用次数，应累计整个任务的消耗。

同样使用 Ultra，能力差异在哪里#

模型定位与行为依据 Models 和 Using GPT-6 Astra。官方后者指出，Astra 在部分评测中以更少的输出 tokens 获得更好结果，使估算 API 单任务成本低于较早模型；这是特定评测结论，不能外推为所有 Ultra 工作流都更便宜。

截至整理日，本文核对的官方资料未提供两者在相同 Ultra 配置、相同工具和相同任务集下统一的成功率或耗时提升百分比。因此，不能把“2.5 倍单价”解释为“2.5 倍能力”，也不能保证 Astra Ultra 总是更快。

选型建议：对于大型代码修改、多来源研究或持续多轮调整、且能够拆出独立子任务的工作，可以优先试 Astra Ultra；如果 Sol Ultra 已能稳定达到验收标准，继续使用 Sol 更容易控制 token 成本。简单问答或小改动，先从较低 reasoning effort 开始；强串行、难拆分的问题，可评估 Max 是否更合适。这些是基于官方定位的建议，最终应以实际任务的完成质量、总消耗和返工次数决定。Models

一个可复算的成本例子#

假设整个任务的所有请求累计消耗 100,000 普通输入 tokens、20,000 输出 tokens，无缓存命中、无 Cache writes，且每次请求均处于 Short context、Standard processing：

• Astra：0.1 × 10 + 0.02 × 50 = $2.00。
• Sol：0.1 × 4 + 0.02 × 20 = $0.80。

以下 Python 3 示例只做本地算术，不调用 API、不产生模型费用。保存为 compare_cost.py，运行 python3 compare_cost.py：

tokens = {"input": 100_000, "output": 20_000}
rates = {
    "gpt-6-astra": {"input": 10, "output": 50},
    "gpt-5.6-sol": {"input": 4, "output": 20},
}

for model, prices in rates.items():
    cost = sum(tokens[k] * prices[k] for k in tokens) / 1_000_000
    print(f"{model}: ${cost:.2f}")

预期输出：

gpt-6-astra: $2.00
gpt-5.6-sol: $0.80

API 的 reasoning tokens 按输出计费，即使它们没有显示在最终回答中；读取已包含推理的输出总量时，不要再重复相加。Reasoning

若进一步假设两边的 token 构成按相同比例缩放、费率档位相同且忽略工具费，那么 Astra 必须将 token 用量降到 Sol 的 40% 以下，才能抵消 2.5 倍单价并更便宜。这只是成本平衡点的算术推导，不是模型节省率承诺。

相关导航：LLM 文档概览。