发布边界：模型定位、Rate Card、限额和 reasoning effort 行为可能变化；发布前必须复核官方页面。文中场景和决策表用于说明方法，不代表作者完成了对照实测。
摘要
GPT-5.6 Sol 与 GPT-5.5 的公开 Token Credits 费率相同，但复杂任务仍可能更快触碰 Codex 限额。原因未必是单位价格变化，而可能是 Sol 更愿意延长执行、追加验证、调用工具和子代理。本文不再重复通用 Agent 成本公式，而是给出一套判断方法：额外工作是否覆盖了新的风险、证据或验收项。
关键词
GPT-5.6 Sol、Codex、Rate Card、Reasoning Effort、Agent 成本
一、Rate Card 相同，只能排除“公开单位费率上涨”
证据图 1：OpenAI Codex Rate Card 的连续表格裁剪，保留表头及 Sol、Terra、Luna、GPT-5.5 行。访问于 2026-07-29；该图不占结构化配图额度。
OpenAI 当前 Codex Rate Card 给 Sol 与 GPT-5.5 列出的输入、缓存输入和输出 Token Credits 费率相同。这说明公开的单位 Token 费率没有因为换成 Sol 而提高。
但它不能推出：
相同任务描述
= 相同模型轮次
= 相同上下文长度
= 相同工具和搜索次数
= 相同子代理数量
= 相同总 CreditsRate Card 决定怎样计价，模型行为决定有多少东西需要计价。模型若多验证两条路径、多读一组文件、追加一次搜索或启动一个子代理，即使单位费率不变，任务总消耗仍会增加。
Sol 限额事件新增的信息正在这里：模型升级不仅改变回答质量，也会改变“任务还要继续到哪里”的执行策略。
二、Sol 的优势，恰好可能扩大执行树
证据图 2：公开说明的必要段落裁剪，保留作者、时间和支撑 18%、工具/子代理、reasoning effort 与长尾结论的上下文。2026-07-29 UTC；该图不占结构化配图额度。
面对“修复支付回调偶发重复入账”，较短的执行可能找到第一个可疑分支、增加判重并运行现有测试。
更主动的执行还可能继续检查：
- 多实例并发是否留下判重窗口；
- 数据库事务是否覆盖幂等检查和写入；
- 消息队列重投会不会绕过保护；
- 上游超时重试是否复用事件标识；
- 缺少的是单元测试还是并发集成测试；
- 修复失败后能否回滚。
这些工作可能把“看起来修好了”提升为“通过真实验收”。但同样的主动性也可能在开放问题上不断扩边界：再读一个模块、再找一个反例、再派一个审查代理。
因此，工具少不等于效率高；模型强也不意味着多做的一切都合理。关键是每个新增动作是否对应新的风险、证据或验收项。
三、同名 reasoning effort 不是跨模型固定预算
Medium、High、Max 很容易被理解成固定算力挡位：
GPT-5.5 High = GPT-5.6 Sol High官方调查说明这种等价不成立。reasoning effort 更接近行为策略，而不是跨模型固定的 Token 配额。换模型后，同名档位可能改变：
- 探索多少替代方案；
- 遇到不确定性时是否继续搜索；
- 是否主动验证边缘情况；
- 是否增加工具往返；
- 是否调用子代理；
- 满足什么条件才停止。
所以模型迁移不能只把旧模型 High 替换成新模型 High。应在同一任务集和验收标准下，重新比较结果质量、人工返工、总 Credits、工具调用、模型往返和长尾分布。
四、典型体验改善与重度任务长尾可以同时存在
OpenAI 在调查更新中提到，发布前过度关注平均值和中位数，遗漏了部分复杂任务长尾。
大量用户可能只做单文件修改、解释错误或生成小段代码；少量用户会处理大仓库迁移、跨模块调查、深度网络研究和多代理任务。后一类任务的执行树更宽、更深，更容易触发重复上下文、工具等待和失败重试。
评测至少应分开记录：
| 维度 | 需要回答的问题 |
|---|---|
| P50 | 日常小任务是否稳定 |
| P95 | 大仓库和复杂工程是否明显放大 |
| P99 | 极端任务是否可能耗尽限额或无法收口 |
| 最大单任务 | 是否一次任务吞掉大部分窗口 |
| 失败任务成本 | 没有交付时已经消耗多少 |
| 人工返工 | 多做的工作是否真正减少人工修正 |
“典型使用预计更省”与“少数复杂任务仍然昂贵”并不矛盾。官方所说的约 18% 典型改善，也不能改写成每个用户、每类任务都固定节省 18%。
五、给每个新增动作标注理由
判断 Sol 多做的工作是否值得，可以把新增动作分为五类：
required_for_acceptance 支撑验收
risk_discovery 发现风险
evidence_confirmation 确认证据
optional_polish 可选润色
duplicate_exploration 重复探索前三类可能提高任务成功率；后两类通常应优先收紧。
例如：
- 读取调用链入口：支撑根因定位；
- 补并发回归测试：支撑验收；
- 检查事务边界：支撑风险判断；
- 第三次搜索相同概念：可能重复探索；
- 验收全部通过后继续优化命名：属于可选润色。
这样，“模型太能干”就变成了可审计问题。额外消耗若没有新增证据、没有覆盖新的失败模式，也没有满足新的验收项，就不应仅凭模型能力获得豁免。
六、模型选择应跟随任务阶段
官方当前定位大致是：Sol 面向复杂、开放式任务；Terra 面向日常工程；Luna 面向清晰、重复性工作。这更适合作为路由起点，而不是永久规则。
| 任务状态 | 默认倾向 | 判断原因 |
|---|---|---|
| 范围清晰、步骤稳定、验收确定 | Luna 或较低成本路径 | 不需要开放探索 |
| 日常功能、常规修复、已有测试 | Terra | 平衡质量、速度和成本 |
| 根因未知、跨系统、高风险迁移 | Sol | 额外推理和验证可能有价值 |
| 已完成发现，只剩机械修改 | 从 Sol 降级 | 不让强模型承担重复劳动 |
| 低档模型连续失败且原因明确 | 升级 | 把能力用在真实瓶颈 |
| Sol 持续扩边界但验收没有推进 | 暂停并重规划 | 防止无界消耗 |
发现阶段可能需要 Sol，机械实现阶段可能不需要；验证发现新风险时又可以升级。模型路由应跟随任务状态，而不是只在入口选择一次。
七、迁移到 Sol 时应该保存什么
结果
- 验收是否通过；
- 缺陷和遗漏；
- 人工返工时间；
- 回滚率。
资源
- 总 Credits；
- 模型往返；
- 工具和搜索次数；
- 子代理数量；
- 总延迟。
长尾
- P50、P95、P99；
- 最大单任务；
- 失败任务消耗；
- 长线程恢复后的增量消耗。
行为
- 验收完成后是否仍继续；
- 重复读取和重复搜索比例；
- 每个工具调用带来的证据或进展；
- 不同 reasoning effort 的质量增量。
最终可以形成下面的决策：
| 观察 | 决策 |
|---|---|
| 成功率明显提高，成本温和增加 | 保留 Sol |
| 成本增加但质量没有变化 | 降档或路由到 Terra/Luna |
| P50 改善但 P99 爆炸 | 增加长尾熔断与检查点 |
| 子代理降低延迟但不提高质量 | 减少并发或更换子代理模型 |
| 验收完成后仍持续工作 | 强化停止条件 |
| 失败主要来自工具或环境 | 修 Harness，不要盲目升级模型 |
结论
Sol 与 GPT-5.5 的公开 Token Credits 费率相同，并不意味着相同任务会产生相同总量。Sol 更主动地探索、验证、调用工具和子代理时，可能更快消耗限额；也可能因为减少漏修和返工，让最终通过验收的结果更划算。
真正有用的问题不是“Sol 烧不烧”，而是：
它新增的每一段工作，是否覆盖了新的风险、证据或验收项？
能回答这个问题，才有资格讨论模型路由、reasoning effort 和预算。