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

AI 参与说明（Agent：Codex）：本文由 Codex 根据 OpenAI 官方 API 与 Codex 文档协助调研、撰写和校验。价格核对于 2026-09-06，能力与使用指南补充、修订于 2026-09-07；价格、可用性与产品行为可能变化。本次修订的可核验运行记录：模型 gpt-6-astra，reasoning effort ultra，执行入口 Codex Desktop，提供方 openai，CLI 运行时版本 0.153.4（非桌面 App 版本）。

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

两篇官方指南怎样配合阅读

GPT-5.6 开发者指南 发布于 2026-08-13，重点是生产工作流的效率：按步骤选择模型与 effort，保留已有推理，用代码压缩工具结果，并改善并行与缓存。文中的客户案例和评测数字属于 GPT-5.6 及其指定实验，不能直接当作 Astra 的收益。

Using GPT-6 Astra 是持续更新的模型使用指南，重点是 Astra 的行为、新增执行控制和迁移兼容性。实际接入以这份当前指南为准，GPT-5.6 文章则帮助解释为什么模型之外的执行流程同样影响质量、速度和费用。

下面五条工程方法可以作为 Astra 工作流的优化起点：

跨模型路由需要显式实现。例如，设计“Astra 做复杂判断，Luna 做批量抽取”时，应由应用或具有模型选择能力的宿主编排；原生 Responses Multi-agent 的子代理共享该请求的模型与工具，不会自动替每一步选择便宜模型。Multi-agent Quickstart

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 继续支持它们。评估升级时，应分别看模型质量、执行控制与宿主集成。更新说明

在 Codex 中怎样用好 Astra

先定义结果和验收标准

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

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

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

按任务结构选 reasoning effort

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

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

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

官方列出的行为倾向可以转化为具体的协作约定：Prompting best practices。

长期约定适合精简后放入项目指令，某次任务的目标与验收则写在当前请求中。先观察具体问题再补规则，避免重复堆叠含义相近的要求。

在同一任务里及时纠正

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

下面是一个可按项目修改的原创开发任务提示示例：

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

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

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

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

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

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

通过 API 使用 Astra

先用最小请求建立基线

以下为 Bash 与 curl 示例，需要有 Astra 调用权限的 API key，并已设置 OPENAI_API_KEY。它发送一个不含工具的文本任务；medium 是示例选择。已核对请求字段和 Shell 语法，未发起付费调用。Responses API 与 reasoning 示例

curl --fail-with-body https://api.openai.com/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-6-astra",
    "reasoning": {"effort": "medium"},
    "instructions": "用中文回答。先给结论，再给必要依据，保持简洁。",
    "input": "分页列表在筛选条件改变后可能出现空白页，请给出处理逻辑和三个边界案例。"
  }'

成功时返回 Response JSON，可见回答位于 output 中的 message 内容；这段请求会给出逻辑与案例，不会读取或修改本地项目。要执行开发任务，还需接入工具并实现工具结果回传。

迁移现有应用时逐项调整

1. 模型使用 gpt-6-astra。原来是 none 或 minimal 时，从 low 开始比较；其他情况先保留原有有效 effort，建立可比基线，再测试较低档位。
2. 工具调用使用 Responses API。Astra 仍支持 Chat Completions，但其工具调用要求 Responses；不要把 Codex 界面的 Ultra 直接填成 API 的 reasoning.effort。
3. 删除 temperature、top_p、top_logprobs；Chat Completions 还要删除 logprobs，Responses 则从 include 移除 message.output_text.logprobs。
4. 需要在对话中切换 effort 时，评估 configuration_update，保持请求级 reasoning.effort 不变以保留缓存前缀。它目前限定 standard、single-agent 请求，并有 Compaction 等兼容性限制。
5. 从 GPT-5.5 或更早版本迁移时，将 prompt_cache_retention 改为 prompt_cache_options.ttl: "30m"，同时重新核算 Cache writes。EU data residency 下 Astra 应使用 Standard processing；其 Fast mode 没有延迟 SLA。

参数和迁移要求见 Migration quickstart；动态 effort 的完整限制见 Change reasoning mid-conversation。

优化顺序：先正确完成，再减少无效工作

建议保留一批覆盖正常情况、边界情况和历史失败的任务，先比较完成率、总耗时与整项任务费用。每轮只改变一个主要因素：先调 effort，再检查重复检索与过量工具输出，随后评估 Compaction、缓存和并行。

支持模型的 Prompt caching 默认启用，命中效果取决于可复用前缀与请求配置；Async tool calling 等执行控制则需要应用接入，不能仅靠提示词开启。Prompt caching、Async tool calling

长对话可用 previous_response_id 延续状态，或手动回传完整 response items；只拼接可见回答会丢掉用于连续推理的状态。缓存与推理复用也是不同机制：前者复用相同前缀的计算，后者延续模型可使用的 reasoning items。跨模型家族切换时，不应假设不透明推理可以直接复用。Reasoning、Prompt caching

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 文档概览。