OpenAI Tibo：同样的 Rate Card，为什么更强的 Sol 反而更快耗尽 Codex 限额

同样的 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 tokensSol 的 1/2GPT-5.6 Luna 公开 Token Credits 费率✅ 已验证输入 25 / 缓存 2.5 / 输出 150 credits per 1M tokensSol 的 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 相同只能排除公开单位费率上涨二、Sol 的优势恰好可能扩大执行树三、同名 reasoning effort 不是跨模型固定预算四、典型体验改善与重度任务长尾可以同时存在五、给每个新增动作标注理由六、模型选择应跟随任务阶段七、迁移到 Sol 时应该保存什么结论参考来源一、Rate Card 相同只能排除公开单位费率上涨OpenAI 当前 Codex Rate Card 给 Sol 与 GPT-5.5 列出的输入、缓存输入和输出 Token Credits 费率相同。这说明公开的单位 Token 费率没有因为换成 Sol 而提高。但它不能推出相同任务描述 相同模型轮次 相同上下文长度 相同工具和搜索次数 相同子代理数量 相同总 CreditsRate Card 决定怎样计价模型行为决定有多少东西需要计价。模型若多验证两条路径、多读一组文件、追加一次搜索或启动一个子代理即使单位费率不变任务总消耗仍会增加。Sol 限额事件新增的信息正在这里模型升级不仅改变回答质量也会改变任务还要继续到哪里的执行策略。二、Sol 的优势恰好可能扩大执行树面对修复支付回调偶发重复入账较短的执行可能找到第一个可疑分支、增加判重并运行现有测试。更主动的执行还可能继续检查多实例并发是否留下判重窗口数据库事务是否覆盖幂等检查和写入消息队列重投会不会绕过保护上游超时重试是否复用事件标识缺少的是单元测试还是并发集成测试修复失败后能否回滚。这些工作可能把看起来修好了提升为通过真实验收。但同样的主动性也可能在开放问题上不断扩边界再读一个模块、再找一个反例、再派一个审查代理。因此工具少不等于效率高模型强也不意味着多做的一切都合理。关键是每个新增动作是否对应新的风险、证据或验收项。三、同名 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/LunaP50 改善但 P99 爆炸增加长尾熔断与检查点子代理降低延迟但不提高质量减少并发或更换子代理模型验收完成后仍持续工作强化停止条件失败主要来自工具或环境修 Harness不要盲目升级模型结论Sol 与 GPT-5.5 的公开 Token Credits 费率相同并不意味着相同任务会产生相同总量。Sol 更主动地探索、验证、调用工具和子代理时可能更快消耗限额也可能因为减少漏修和返工让最终通过验收的结果更划算。真正有用的问题不是Sol 烧不烧而是它新增的每一段工作是否覆盖了新的风险、证据或验收项能回答这个问题才有资格讨论模型路由、reasoning effort 和预算。参考来源Tibo SottiauxGPT-5.6 Sol 使用限额调查更新OpenAI Codex ModelsOpenAI Codex PricingOpenAI Codex Rate CardOpenAI 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 / 最大单任务 / 失败任务成本加长尾熔断 检查点超过预算暂停并重规划把模型更强 应该一直用作为默认规则没有任务阶段路由任务状态 验收进度默认规则改为任务阶段决定模型强模型只在需要时使用不记录新增动作带来的证据或进展每个工具调用没绑定价值每个工具调用 → 证据 / 进展 / 重复强制每个工具调用记录带来的证据或进展否则标记为重复探索作者武子康的个人博客