大家好，我是孟健。
OpenAI新发的GPT-6 Astra，API单价是前代的2.5倍。但Artificial Analysis在9月3日的Coding Agent Index评测发现：Astra max在Codex编码agent基准中，约只用了前代Sol max三分之一的tokens，任务成本约与前代持平，评分还高了2分。
这不是账单承诺，是特定测试harness的观察。AA 9月3日v4.1.1的综合任务集，同档成本增加75%。我补测了两类真实产品模块，Astra都全过，但追加压力复验暴露了全绿补丁仍缺业务响应验证和请求控制的防线缺口。
核心观点：按任务路由，别默认顶配，高级型号不替你定义上线验收。
01 拆解单价倍增与token计费的关系
GPT-6 Astra的API标准价，输入每百万token 10美元，输出50美元。对比前代GPT-5.6 Sol的4美元和20美元，单价确实是2.5倍。这是调用API的费用，不是ChatGPT或Codex订阅价。
OpenAI官方对GPT-6 Astra的定位：复杂推理、编码、computer use等端到端工作
token是模型处理文本的基本单位。每次调用，输入和输出按token计费，缓存命中的输入token计费更低。提示越长、返回内容越多，消耗的token就越多，账单也越高。
AA在9月3日评测中发现：Astra max在Codex约只用了前代Sol max三分之一的tokens。但这不等于所有场景都省token。编码agent基准有特定的工具链和评分逻辑，会影响token消耗模式。输入、输出、缓存的计费权重不同，不能简单用token变1/3乘以单价2.5推导成本。约持平是AA实际统计的结果，不是公式推导的必然。
02 聚焦编码agent基准时成本约持平
AA的Coding Agent Index是特定harness，有自己的工具链和评分逻辑。在这个基准中，Astra在Codex评分67，Claude Fable 5.1在Claude Code评分70。不同工具壳非裸模型公平横评，但可以观察相对表现。
AA Coding Agent Index：Astra在Codex评分67，约只用了前代Sol max三分之一的tokens
关键是：在这套特定评测中，Astra约只用了前代三分之一token，任务成本约与Sol max相同且评分高2分。AA站内数据显示，Astra每任务成本不到同分Fable 5的一半。这是该harness下的观察，不代表所有编程场景。
为什么能省token？可能的原因包括更精准的推理、更少的工具调用轮次、更短的中间输出。仅凭汇总token无法判定具体机制，只知道最终用的token更少。这种效率有边界。端到端的完整编码任务，需要模型理解需求、拆解步骤、生成代码、调试修复、验证结果。在这个过程中，token消耗取决于模型精准度和工具链设计。如果换成你自己的工具链、数据库查询、配置文件修改，省token的前提可能就不成立。
AA的Coding Agent Index观察到Astra在Codex中评分67，约只用了前代三分之一token，任务成本约持平。这使得Astra值得进入复杂编码任务的候选。但这是特定harness的结果，不同的任务组合会有不同的成本表现。我补测的两个模块难度有限，不能用它们来否定Astra在更复杂场景中的价值。OpenAI官方的Codex工具链和省token机制我未在本机测试，不做展开。实际选型时，你需要用自己的真实工作负载验证，看在哪个配置下效率最高、成本最低。
03 别拿编码收益外推全任务
同一天，AA还更新了旧版Intelligence v4.1.1的数据。在这个综合评测中，Astra max相比Sol max，输出token少了约10%，但每任务成本增加75%。单价2.5倍，只省10% token，成本就上去了。
9月4日AA已经更新到v4.2，在新版综合指数中，Astra比Sol高了4分。v4.2移除了饱和的GPQA，加入了AA-Briefcase和GDP.pdf两个新基准。GDP.pdf是跨100份PDF、4592页专业材料、1275项专家原子标准的严格文档任务。全项通过率不是一般回答准确率，而是整项任务全部标准都过的比例。一个标准未满足，整任务就不计入全过。
AA v4.2的GDP.pdf基准：Astra全项通过率33.2%，Sol为28.2%
在GDP.pdf中，Astra的全项通过率是33.2%，Sol是28.2%。这是业界文档处理的表现，不是本机实测。AA还观察到，Astra在AA-Briefcase中分析质量提升了，但呈现质量有所回落。模型能想得更深，但最终输出的结构性可能需要人工整理。
通用任务成本增加75%，对实际工作的影响取决于你的任务组合。如果任务不需要深度推理，多花的钱就没有换回对等价值。
04 把业界判断放进真实产品验证
看完行业数据，我拿ShipSite和ShipSolo的固定源码做了实测。选了两个实际模块，在已有调用逻辑和约束条件下，观察模型交付的修复能否通过验收。全程在隔离环境验证，不涉及线上会员或部署操作。
ShipSite截图模块的场景是：最多3个页面并发，有总预算限制。请求期限到了时，浏览器实例或某个页面可能刚创建完成，Promise.race已返回但没有取消正在创建的资源。这些资源后续需要接管，关闭时可能抛错或挂住。单个页面失败不能拖累整批，清理等待时间也有上限。模型需要在这些约束下给出可用的错误处理。
Astra High首稿在ShipSite通过15/15行为验收,原仓库TypeScript另外通过。这里测的是资源生命周期和原契约，不是保证生产可用。Flash Low首稿也通过相同两项，未显示旗舰独占优势。
ShipSolo是AI编程出海领航计划，这次只取其后台统计模块。缓存key区分上游地址/凭据/查询，同key并发合并一次回源，各调用者返回对象独立、修改不会污染后续缓存。120项LRU、5分钟TTL、真实公历、owner/admin原接口兼容。
Astra High首稿在ShipSolo行为36/36且独立TypeScript通过，Flash Low首稿同样通过。使用本机CLI云端模型、真实源码冻结、Docker模拟依赖，不接触真实会员或生产。只证明已定义断言通过，不称完整业务覆盖。
Flash High在ShipSite首轮工具拒绝响应空，第二轮截断；提取补丁15/15通过但TypeScript失败。ShipSolo第二轮原生完整交付36/36且TypeScript通过，只是代码产物完整度差异。
对已经生成的ShipSolo代码，事后追加了防御压力复验，没有重新调用模型。Astra High首稿、Flash Low首稿、Flash High第二稿，加上原基线和人工参考解，同样条件各重复两次。原来36项行为仍然成立。新增的要求是事后探索，不算违反原题目，也没再给模型机会修复，不代表能力天花板。
HTTP200响应但JSON损坏时，三份模型代码都拒绝了4个调用者，下次上游响应正常后能重新回源。
HTTP200合法JSON但只有error字段没有results时，三份候选都返回并缓存了错误对象。随后上游恢复正常，下一次同key调用仍然得到坏对象，没有重新回源。这不是实际Plausible服务的真实事故，是模拟压力。
模拟上游一直pending的场景下，200毫秒观察窗内两个同key调用者都未完成，共享一次fetch，框架可能另设更长超时，只能说模块在观察窗内未主动返回。
150个不同key同时调用，释放模拟上游前全部发出150次fetch，120项结果缓存不是在途限流。原人工参考解同样缺这些防线。
只有两个源码任务，每配置每任务一个初始生成样本，复验同一代码不是新生成。Low是High之后探索。Astra通过Hermes且首轮加载过通用评测skill，Flash经agy，工具和系统上下文不同，不据此做裸模型的速度或账单排名。未覆盖全仓生产交互。
05 建议按任务路由不要全部顶配
GPT-6 Astra的定位是最难的推理、编码、computer use、研究、文档创建。如果你的任务属于这类端到端工作，可能体现token效率优势。AA的Coding Agent Index已经在那套特定harness中观察到：成本约持平，能力提升。
但本轮补测没有证明旗舰独占正确率。我测试的两个模块，Astra首稿全过，Flash Low在ShipSolo也全过。这说明在这个难度区间，不同配置都能完成任务。已明确验收的修复与未定义的全链路鲁棒性不同，追加压力复验暴露的缺口在原题范围之外，且我没有再让模型按新防御要求修复，所以未测到能力天花板。
如果遇到更复杂的任务，比如理解百页技术规范、生成完整多模块项目、处理跨领域知识整合，贵模型可能就体现价值。但这个价值需要你用自己的真实任务来证明。
实际选型：受控任务、明确验收、大量调用，先用便宜的配置。模糊需求、长链条、高失败代价，优先验证强模型，但仍需验收。中间地带，先用便宜的试，失败了再升级。把常做的活拿来验收，按完成任务的代价选配置。预算用于能测出收益的地方。
参考：OpenAI模型页 · AA Astra独立评测 · AA新版v4.2
👋 我是孟健，前腾讯 T11 / 前字节技术 Leader，现在全职做 AI 编程。
🔥 更多 AI 编程实战：
- GitHub：@mengjian-github
- 专栏：AI编程实战
觉得有用？点赞+收藏 就是最大支持 🙏