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