同样的 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 费率 | ✅ 已验证 | 输入 125 / 缓存 12.50 / 输出 750 credits per 1M tokens（费率完全相同） |
| GPT-5.6 Terra 公开 Token Credits 费率 | ✅ 已验证 | 输入 62.50 / 缓存 6.25 / 输出 375 credits per 1M tokens（Sol 的 1/2） |
| GPT-5.6 Luna 公开 Token Credits 费率 | ✅ 已验证 | 输入 25 / 缓存 2.5 / 输出 150 credits per 1M tokens（Sol 的 1/5） |
| 缓存输入 = 输入的 10% / 输出 = 输入的 6 倍 | ✅ 已验证 | 三档模型都满足这一比例 |
| OpenAI 限额重置 | ✅ 已验证 | Tibo Sottiaux 2026-07-28 调查更新：所有 ChatGPT Work 与 Codex 用户限额已重置 |
| 典型使用预计维持更久 | ✅ 已验证 | 调查更新称约 18% 更长 |
| 五小时限额恢复 | ✅ 已验证 | 调查更新称次日恢复 |
| Sol 工具调用与子代理协作增加 | ✅ 已验证 | 调查更新明确：Sol 更努力、调用更多工具、协调复杂工作流 |
| 同 reasoning effort 下 Sol 使用更多 token | ✅ 已验证 | 调查更新明确：Sol 在相同 reasoning effort 下 token 使用多于 GPT-5.5 |
| 程序化工具调用（code mode） | ✅ 已验证 | 调查更新：带来灵活性但导致单轮响应数和 token 使用增加 |
| 问题在工具调用与网络搜索时更明显 | ✅ 已验证 | 调查更新明确 |
| 影响不均衡（中位 vs 深度用户） | ✅ 已验证 | 调查更新：median 用户觉得高效，power 用户觉得耗得更快 |
| 官方当前定位 | ✅ 已验证 | Sol 复杂开放任务 / Terra 日常工程 / Luna 清晰重复性工作 |
| "Rate Card 相同 = 任务成本相同" | ❌ 不成立 | 费率只排除"公开单价变化"；模型行为改变执行树 |
| "reasoning effort = 跨模型固定 Token 预算" | ❌ 不成立 | 同名档位可能改变探索 / 验证 / 工具往返 / 子代理 / 停止条件 |
| "18% 改善 = 全部任务都省 18%" | ❌ 不成立 | 典型使用改善不等于复杂任务长尾也改善 |
| "强模型多做 = 一定更划算" | ❌ 不成立 | 额外工作若不覆盖新风险 / 证据 / 验收项，就只是消耗 |
| "模型路由在入口选一次就够" | ❌ 不成立 | 路由应跟随任务阶段：发现→Sol、机械实现→降级、新风险→升级 |
| "平均 Token / Benchmark 决定模型选择" | ❌ 不成立 | 必须用 P95 / P99 / 最大单任务 / 失败任务成本多维度 |
文章正文
摘要
GPT-5.6 Sol 与 GPT-5.5 的公开 Token Credits 费率相同，但复杂任务仍可能更快触碰 Codex 限额。原因未必是单位价格变化，而可能是 Sol 更愿意延长执行、追加验证、调用工具和子代理。本文不再重复通用 Agent 成本公式，而是给出一套判断方法：额外工作是否覆盖了新的风险、证据或验收项。
关键词
GPT-5.6 Sol、Codex、Rate Card、Reasoning Effort、Agent 成本
目录
- [一、Rate Card 相同，只能排除"公开单位费率上涨"](#一、Rate Card 相同，只能排除"公开单位费率上涨" "#%E4%B8%80rate-card-%E7%9B%B8%E5%90%8C%E5%8F%AA%E8%83%BD%E6%8E%92%E9%99%A4%E5%85%AC%E5%BC%80%E5%8D%95%E4%BD%8D%E8%B4%B9%E7%8E%87%E4%B8%8A%E6%B6%A8")
- [二、Sol 的优势，恰好可能扩大执行树](#二、Sol 的优势，恰好可能扩大执行树 "#%E4%BA%8Csol-%E7%9A%84%E4%BC%98%E5%8A%BF%E6%81%B0%E5%A5%BD%E5%8F%AF%E8%83%BD%E6%89%A9%E5%A4%A7%E6%89%A7%E8%A1%8C%E6%A0%91")
- [三、同名 reasoning effort 不是跨模型固定预算](#三、同名 reasoning effort 不是跨模型固定预算 "#%E4%B8%89%E5%90%8C%E5%90%8D-reasoning-effort-%E4%B8%8D%E6%98%AF%E8%B7%A8%E6%A8%A1%E5%9E%8B%E5%9B%BA%E5%AE%9A%E9%A2%84%E7%AE%97")
- 四、典型体验改善与重度任务长尾可以同时存在
- 五、给每个新增动作标注理由
- 六、模型选择应跟随任务阶段
- [七、迁移到 Sol 时应该保存什么](#七、迁移到 Sol 时应该保存什么 "#%E4%B8%83%E8%BF%81%E7%A7%BB%E5%88%B0-sol-%E6%97%B6%E5%BA%94%E8%AF%A5%E4%BF%9D%E5%AD%98%E4%BB%80%E4%B9%88")
- 结论
- 参考来源
一、Rate Card 相同，只能排除"公开单位费率上涨"
OpenAI 当前 Codex Rate Card 给 Sol 与 GPT-5.5 列出的输入、缓存输入和输出 Token Credits 费率相同。这说明公开的单位 Token 费率没有因为换成 Sol 而提高。
但它不能推出：
text
相同任务描述
= 相同模型轮次
= 相同上下文长度
= 相同工具和搜索次数
= 相同子代理数量
= 相同总 CreditsRate Card 决定怎样计价，模型行为决定有多少东西需要计价。模型若多验证两条路径、多读一组文件、追加一次搜索或启动一个子代理，即使单位费率不变，任务总消耗仍会增加。
Sol 限额事件新增的信息正在这里：模型升级不仅改变回答质量，也会改变"任务还要继续到哪里"的执行策略。
二、Sol 的优势，恰好可能扩大执行树
面对"修复支付回调偶发重复入账"，较短的执行可能找到第一个可疑分支、增加判重并运行现有测试。
更主动的执行还可能继续检查：
- 多实例并发是否留下判重窗口；
- 数据库事务是否覆盖幂等检查和写入；
- 消息队列重投会不会绕过保护；
- 上游超时重试是否复用事件标识；
- 缺少的是单元测试还是并发集成测试；
- 修复失败后能否回滚。
这些工作可能把"看起来修好了"提升为"通过真实验收"。但同样的主动性也可能在开放问题上不断扩边界：再读一个模块、再找一个反例、再派一个审查代理。
因此，工具少不等于效率高；模型强也不意味着多做的一切都合理。关键是每个新增动作是否对应新的风险、证据或验收项。
三、同名 reasoning effort 不是跨模型固定预算
Medium、High、Max 很容易被理解成固定算力挡位：
text
GPT-5.5 High = GPT-5.6 Sol High官方调查说明这种等价不成立。reasoning effort 更接近行为策略，而不是跨模型固定的 Token 配额。换模型后，同名档位可能改变：
- 探索多少替代方案；
- 遇到不确定性时是否继续搜索；
- 是否主动验证边缘情况；
- 是否增加工具往返；
- 是否调用子代理；
- 满足什么条件才停止。
所以模型迁移不能只把旧模型 High 替换成新模型 High。应在同一任务集和验收标准下，重新比较结果质量、人工返工、总 Credits、工具调用、模型往返和长尾分布。
四、典型体验改善与重度任务长尾可以同时存在
OpenAI 在调查更新中提到，发布前过度关注平均值和中位数，遗漏了部分复杂任务长尾。
大量用户可能只做单文件修改、解释错误或生成小段代码；少量用户会处理大仓库迁移、跨模块调查、深度网络研究和多代理任务。后一类任务的执行树更宽、更深，更容易触发重复上下文、工具等待和失败重试。
评测至少应分开记录：
| 维度 | 需要回答的问题 |
|---|---|
| P50 | 日常小任务是否稳定 |
| P95 | 大仓库和复杂工程是否明显放大 |
| P99 | 极端任务是否可能耗尽限额或无法收口 |
| 最大单任务 | 是否一次任务吞掉大部分窗口 |
| 失败任务成本 | 没有交付时已经消耗多少 |
| 人工返工 | 多做的工作是否真正减少人工修正 |
"典型使用预计更省"与"少数复杂任务仍然昂贵"并不矛盾。官方所说的约 18% 典型改善，也不能改写成每个用户、每类任务都固定节省 18%。
五、给每个新增动作标注理由
判断 Sol 多做的工作是否值得，可以把新增动作分为五类：
text
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 和预算。
参考来源
- Tibo Sottiaux：GPT-5.6 Sol 使用限额调查更新
- OpenAI Codex Models
- OpenAI Codex Pricing
- OpenAI Codex Rate Card
- OpenAI Codex Speed
错误速查卡
| 症状 | 根因 | 定位 | 修复 |
|---|---|---|---|
| Rate Card 相同就推断总成本相同 | 费率只排除"公开单价变化"；模型行为改变执行树 | 比对实际总 Credits / 工具调用 / 子代理数 / 模型往返 | 按 4 个执行树变宽机制（Explore / Tool / Agent / Verify）逐项测量 |
| 换到 Sol 后限额更快耗尽 | Sol 更努力 + 工具调用更多 + 子代理协作更复杂 | 调查更新明确：同 reasoning effort 下 Sol token 更多 | 用 5 类动作标签（3 续 + 2 停）逐项审计；后两类优先收紧 |
| 把"GPT-5.5 High = GPT-5.6 Sol High" 当固定算力 | 同名档位改变探索 / 验证 / 工具往返 / 子代理 / 停止条件 | 比较同名档位下的探索深度、停止条件、调用次数 | 在同一任务集 + 验收标准下重测；不要把旧模型 High 直接映射 |
| 拿平均 Token / 中位数就宣布"省了 18%" | 平均值/中位数掩盖长尾；调查更新明确发布前过度关注 median | 分 P50 / P95 / P99 / 最大单任务 / 失败任务成本 6 维度记录 | 用 6 维度替换平均值；典型改善 ≠ 每个任务都改善 |
| 强模型多做 = 一定更划算 | 额外工作若不覆盖新风险 / 证据 / 验收项，就只是消耗 | 给每个新增动作打 5 类标签 | 必绑定"覆盖新风险 / 确认新证据 / 满足新验收项"至少一项才能继续 |
| 验收完成后仍持续工作 | 没有停止条件；模型自愿继续润色 | 检查停止条件 + 任务成功验证 + 重复探索比例 | 强化停止条件；验收全部通过后进入"可选润色"层，需显式放行才继续 |
| P50 改善但 P99 爆炸 | 长尾熔断缺失；少数复杂任务吞掉大部分窗口 | 检查 P95 / P99 / 最大单任务 / 失败任务成本 | 增加长尾熔断与检查点；超过预算暂停并重规划 |
| 子代理降低延迟但不提高质量 | 子代理并行放大了 Token 而非质量 | 检查子代理数 / 质量增量 / 重复探索比例 | 减少并发或更换子代理模型；不是"加并发 = 加速" |
| 失败主要来自工具 / 环境却盲目升级模型 | 错误归因到模型；Harness 问题没解决 | 区分失败来源：模型 / Harness / 工具 / 环境 | 修 Harness；不要把 Harness 问题当成模型问题 |
| 模型路由在入口选一次 | 任务阶段会变；发现 vs 机械实现需要不同模型 | 检查任务阶段路由表 | 路由跟随任务状态：发现→Sol、机械→降级、新风险→升级 |
| 18% 改善被改写成"每个任务都省 18%" | 典型使用改善 ≠ 每类任务改善 | 拆 P50 / P95 / P99 + 任务类型分桶 | 报告必须分维度 + 分任务类型；不能拿典型改善为所有任务背书 |
| 只比较 Benchmark / 平均 Token 决定迁移 | Benchmark 不覆盖长尾；平均 Token 不反映执行树 | 检查迁移 8 项指标 | 用 8 项（结果 / 资源 / 长尾 / 行为）替代 Benchmark 单一指标 |
| 复用 GPT-5.5 的停止条件在 Sol 上 | Sol 更愿意延长执行；旧停止条件不够紧 | 验收完成后是否仍继续 + 重复读取比例 | 显式写入停止条件：覆盖新风险 / 确认新证据 / 满足新验收项至少一项 |
| 把"程序化工具调用 = 完全免费" | code mode 带来灵活但单轮响应数和 token 使用增加 | 检查单轮响应数 / 工具调用 / 子代理数 | code mode 不是"无成本扩展"；与正常工具调用一同计费并触发执行树变宽 |
| "模型路由 = 选择 Sol 就够了" | Sol 适合发现阶段，不适合机械实现 | 任务状态表 | 用任务阶段路由表；发现→Sol、机械→降级 |
| 在 P99 爆炸时仍继续用 Sol 不加熔断 | 长尾熔断缺失 | 检查 P99 / 最大单任务 / 失败任务成本 | 加长尾熔断 + 检查点；超过预算暂停并重规划 |
| 把"模型更强 = 应该一直用"作为默认规则 | 没有任务阶段路由 | 任务状态 + 验收进度 | 默认规则改为"任务阶段决定模型"；强模型只在需要时使用 |
| 不记录"新增动作带来的证据或进展" | 每个工具调用没绑定价值 | 每个工具调用 → 证据 / 进展 / 重复 | 强制每个工具调用记录"带来的证据或进展"；否则标记为重复探索 |
作者：武子康的个人博客