如果不管什么任务都用最高档的 AI 模型，你 Hold 住成本吗？
最近大家有没有发现，模型商把模型分档了：例如 GLM 有 5.3 和 5.3 Flash，DeepSeek 也有 Pro 和 Flash 两个版本。
前几天，OpenAI 发布了全新的 GPT-6 Astra，它的出现，让开发者又多了一个选择。
OpenAI 把它定位为目前能力最强的模型，主要面向复杂推理、编码、计算机操作、研究和文档创建等高难度任务。
如果你现在打开 Codex，你会发现现在你有：
GPT-6 Astra
GPT-5.6 Sol
GPT-5.6 Terra
GPT-5.6 Luna
GPT-5.5
抛开 GPT-5.5，等于你有四个模型可以选择。
写一份发布说明、修复一个可以稳定复现的 Bug、完成一次跨模块迁移，需要的判断能力显然不在一个级别。
此时，你一定会想：GPT-5.6 已经过时了吗？
从官方公布的规格和价格来看，答案没这么简单。
我们在选模型时，更值得考虑的是：任务最终能不能通过验收、失败后重试要花多少钱，以及结果是否容易验证，当然，速度，也至关重要。
它们有什么区别
| 模型 | 官方定位 | API 标识符 |
|---|---|---|
| GPT-6 Astra | 面向高难度端到端工作的最高能力模型 | gpt-6-astra |
| GPT-5.6 Sol | 面向专业工作的旗舰模型 | gpt-5.6-sol |
| GPT-5.6 Terra | 在能力与成本之间取平衡，大致对应之前的 mini 档 | gpt-5.6-terra |
| GPT-5.6 Luna | 面向经济型、高吞吐量任务，大致对应之前的 nano 档 | gpt-5.6-luna |
它们是四个独立的模型选项。Sol、Terra 和 Luna 不是推理强度设置。
这些定位还是有点抽象。拿高考数学题打个比方，可以这样理解它们各自适合先试的任务：
- Luna：能靠代入选项、简单计算就验证答案的选择题。候选答案已经给出，求解过程比较明确，可以先试成本较低的模型。
- Terra：需要自己组织几个步骤的常规填空题、解答题。理解题意、选好方法，再完成推导，适合用它兼顾能力和成本。
- Sol：需要综合多个知识点、分类讨论的难题。既要把推导串起来，也要检查有没有漏掉某种情况。
- Astra：思路难找、要反复尝试和检查条件的压轴题。走不通时需要换条路，还得记住前面已经排除了哪些可能。
这是一种直观的选型思路：解法越明确、答案越容易验证，就越适合先试成本较低的模型；越需要探索解法、完成长串推导，就越值得用能力更强的模型。
题型只是比喻，不是四个模型的能力分界线。Sol 也可以挑战压轴题，Astra 也可能犯简单错误。两者尤其值得比较的，是在步骤多、需要不断判断和调整的任务中，Astra 能否少出错、少返工。这也正是下一节要看的区别。
Astra 到底强在哪
按照 OpenAI 的说法，Astra 在长时间任务中更不容易丢失上下文，指令遵循能力更强，也更擅长处理执行过程中发生的需求变更。
OpenAI 还表示，在几项评估中，Astra 使用的输出 Token 更少。虽然单价更高，但部分任务的预估总成本反而可能更低。注意，这是厂商给出的测试结果，不代表你的工作负载也一定如此。
官方指南重点提到了三项工作流能力：
- 异步工具调用：应用执行工具时，模型可以继续处理其他互不依赖的工作。
- 回合中途调整：通过 WebSocket 使用 Responses API 时，可以在任务执行途中补充指令。模型会根据新要求调整方向，同时保留已经完成的工作。
- 动态调整推理强度：对话进行到一半时可以修改推理强度，不需要重写原本已经缓存的 Prompt 前缀。
Astra 也保留了 GPT-5.6 已经支持的能力，包括结构化输出、计算机操作、流式输出和上下文压缩。单凭这些能力，还不足以证明它实现了代际提升。
OpenAI 提到，面对一个规模不大的编码任务，Astra 可能会提出更多澄清问题，测试范围也可能超出实际需要。
站在开发者的角度，我会用这类问题来测试它：一个 Bug 同时涉及导航、生命周期和埋点。模型能不能守住原有事件协议，找到根因，给出足够克制的修改，并在需求中途变化后继续完成验证？
这类任务的结果，才值得拿来判断是否应该为 Astra 多花钱。
技术规格：上下文窗口没有变大
| 规格 | GPT-6 Astra | GPT-5.6 Sol | GPT-5.6 Terra | GPT-5.6 Luna |
|---|---|---|---|---|
| 上下文窗口 | 1,050,000 Token | 1,050,000 Token | 1,050,000 Token | 1,050,000 Token |
| 最大输出 | 128,000 Token | 128,000 Token | 128,000 Token | 128,000 Token |
| 知识截止日期 | 2026 年 4 月 30 日 | 2026 年 2 月 16 日 | 2026 年 2 月 16 日 | 2026 年 2 月 16 日 |
| API 推理强度 | low 至 max | none 至 max | none 至 max | none 至 max |
上下文窗口需要容纳输入、推理和输出；最大输出额度也包含推理 Token，并非全部用于最终回答。因此，不能在塞满 1,050,000 Token 的输入后，再额外生成 128,000 Token 的输出。
相同的上下文上限，并不能说明每个模型都能同样可靠地利用每个细节。即使整个仓库都能塞进上下文窗口并留出足够的推理和输出空间，任务范围仍然要足够明确，也要有真正能说明问题的验证方式。
知识截止日期更晚，也不等于模型了解某个依赖或产品的当前状态。如果信息的新鲜度会影响结论，就应该把最新文档交给模型，或者接入检索。
花多少钱
我知道，其实你最关心这个。
下面是 Standard 处理模式、短上下文文本请求的价格，单位为每 100 万 Token 的美元价格。这些数字与 ChatGPT 订阅价格无关。
| 模型 | 输入 | 缓存输入 | 输出 |
|---|---|---|---|
| GPT-6 Astra | $10.00 | $1.00 | $50.00 |
| GPT-5.6 Sol | $4.00 | $0.40 | $20.00 |
| GPT-5.6 Terra | $2.00 | $0.20 | $12.00 |
| GPT-5.6 Luna | $0.20 | $0.02 | $1.20 |
当输入超过 272,000 Token 时，整个请求都会按长上下文计价：输入、缓存输入和缓存写入费率均变为短上下文的 2 倍，输出费率变为 1.5 倍。上表未列出缓存写入费率，实际发生缓存写入时还需按对应费率计费。
算一笔账
假设每次请求消耗 10,000 个未缓存输入 Token，以及 2,000 个需要计费的输出 Token，其中包含推理 Token。使用 Standard 处理模式，不调用工具、不重试，也没有其他费用。
| 模型 | 每次请求的计算成本 | 1,000 次请求的计算成本 |
|---|---|---|
| Astra | $0.2000 | $200.00 |
| Sol | $0.0800 | $80.00 |
| Terra | $0.0440 | $44.00 |
| Luna | $0.0044 | $4.40 |
Astra 的计算过程是：
(10,000 × $10 + 2,000 × $50) / 1,000,000 = $0.20
在这组固定假设下，Astra 的成本是 Sol 的 2.5 倍，Terra 的成本是 Luna 的 10 倍。
这些数字只是根据公开价格算出来的，不能用来证明哪个模型更省钱或性能更好。不同模型完成同一项任务时，实际消耗的 Token 数量可能不同。推理 Token 即使不会出现在最终回答中，仍然会按输出 Token 计费。
更贵的模型，什么时候反而更便宜
沿用刚才的请求规模，Sol 尝试 3 次需要 0.20。
如果 Astra 一次成功，而 Sol 总共尝试 3 次才成功，那么 Astra 的模型费用大约低 16.7%。
这只是用来说明盈亏平衡点，并不表示真实任务一定会出现这样的重试规律。实际的后续请求通常有不同的输入长度，缓存情况也会变化。
应该统计的是：总工作流成本除以通过验收的结果数量。
这里的总成本不能只算最后一次成功请求。失败尝试产生的费用也要算进去，人工修正时间则按约定的人工小时成本折算为费用。也就是：总工作流成本 = 模型与工具费用 + 人工修正小时数 × 人工小时成本。一个单次价格很低、却需要大量返工的回答，最后可能一点也不便宜。
怎么选
下面是我根据官方模型定位整理的一套起步策略。这些任务分配没有经过本文的基准测试。
| 工作内容 | 首选模型 | 什么情况值得升级模型 |
|---|---|---|
| 按照固定分类体系给 Issue 标题分类 | Luna | 在有歧义的样本上反复出错 |
| 按给定 Schema 提取字段 | Luna | 字段缺失或归一化结果不正确 |
| 解释一个函数，或完成边界明确的小改动 | Terra | 依赖关系让任务范围超出预期 |
| 为验收标准清楚的功能补测试 | Terra | 状态转换复杂，或失败原因难以分析 |
| 跨多个模块实现一个功能 | Sol | 反复丢失约束，或漏掉模块之间的交互 |
| 审查架构，或调试偶发故障 | Sol | 多种解释互相冲突，迟迟无法排除 |
| 调查棘手的全局回归问题 | Astra | 失败尝试本身已经很昂贵时，直接从 Astra 开始 |
| 同时协调文档、代码和不断变化的需求 | Astra | 根据最终交付物的一致性和证据判断结果 |
日常开发中，我会先从 Terra 开始。范围窄、重复性高、验证成本低的任务用 Luna；实现难度较高的任务用 Sol；需要在多个步骤中持续做判断时，再上 Astra。
一个 Android 开发中的例子
假设有一个 Android 应用，在页面导航和重组之后都会发送一次页面浏览埋点。但埋点协议要求的是：每次由用户主动进入页面，只发送一次事件。
这时可以这样写 Prompt：
追踪这个事件的所有发送路径，说明具体是哪条执行路径造成了重复发送。实现最小范围的修复，保留现有事件名称和属性。补一条回归测试，同时覆盖重复重组和真正的再次进入。最后给出支持这次修复的证据，以及仍未验证的假设。
当然，通常我也会用 ask-matt 或者 using-agent-skill 技能去完成这个任务。
如果问题只在局部，而且可以稳定复现，可以先试试 Terra。
如果问题横跨生命周期所有权、导航和共享 Flow，我会使用 Sol。
要是之前的尝试始终无法跨过这些层级守住事件协议，我会把失败记录一起交给 Astra 再试一次。
不管最后用哪个模型，验收标准都不能变：事件次数正确、Payload 保持不变，并且测试能够捕获最初的问题。
推理强度也要考虑
提高推理强度可能改善复杂任务的结果，但也会增加等待时间和 Token 消耗。OpenAI 建议从默认值开始，只在确有需要时提高强度。
在 ChatGPT Work 中，Ultra 还会用到 Subagent，因此不能把它当成一个所有 API 都支持的通用推理强度值。不同客户端、账号和发布批次能够使用的模型也不完全相同。
我的习惯是：答案可以直接验证时，推理强度不用开得太高；任务涉及相互竞争的假设、架构取舍或多个彼此影响的约束时，再往上调。
模型和推理强度应该放在一起评估。只比较模型，不控制推理强度，结果很容易失真。
我会这么做
我们可以通过查阅官方页面，确认价格、上下文限制、模型定位和支持的工作流。但在这些资料里，我没有找到一张能够直接比较四个模型的数值基准表。
所以，我不会给 Astra 填上一个 SWE-bench 分数、每秒 Token 数，也不会凭空写一个性能提升百分比。
如果你的团队正在选模型，我会先跑一轮包含 40 个代表性任务的小规模测试：10 个信息提取任务、10 个边界明确的修复、10 个功能开发任务，以及 10 个高难度调查任务。
这是一套建议的评估方案，不是已经完成的测试数据。
测试时，仓库状态、工具、任务说明和验收标准都要保持一致。不确定的案例需要重复执行。首次尝试通过率与允许重试后的最终通过率应分别记录，后者需要统一重试上限。具体记录下面这些指标：
| 指标 | 记录内容 |
|---|---|
| 任务验收通过率 | 满足预设评分标准的任务数 ÷ 参评任务总数，分别记录首次尝试和允许重试后的结果 |
| 得到可验收结果所需的时间 | 从开始到通过验收的完整耗时，包括重试 |
| 人工修正时间 | 修复或补全模型输出花费的分钟数 |
| 总工作流成本 | 所有模型和工具费用（包括失败尝试）加上按统一人工小时成本折算的人工修正费用 |
| 回归率 | 导致原本正常行为被破坏的改动比例 |
当 Astra 能带来更多通过验收的结果、明显减少人工修正时间，或者算上重试后反而更省钱，它就有使用价值。
反过来，只要 Sol、Terra 或 Luna 能以更低成本满足同一套验收标准，它们就是更合适的选择。
以我最近购买的每月 20 美元的 Codex 为例，我通常会用能力更强的模型（例如 Sol 或 Astra）来分析需求或制定计划；但到了实施计划的时候，我会用 Terra 以及 Luna，毕竟这两个模型用起来够快！
总之，先看清下一项需要完成的具体工作，再让实际结果告诉你，该往上升一档，还是往下降一档。
