任务花多少钱，主要看跑几轮、缓存命中多少；单价下降只是次要因素
任务成本的主变量是轮次，不是单价：多一轮就多付一次「把之前全部内容重发」的钱，所以最省的一轮是不需要的那一轮。
agent 循环每走一圈就是一次请求，请求里要带上到目前为止的整段上下文。原文的例子：上下文从 20K 涨到 120K，跑 40 轮，累计输入约 2.8M token，缓存命中 90% 时输入费约 $1.62；同一任务压到 25 轮，累计约 1.75M、$1.02。对话本身从没超过 120K，但累计输入是对话体积的许多倍。省轮次的两个办法：给模型一个自检手段（测试、build、调接口的脚本），以及让它一次把需要的东西收集齐、把工具调用合并批量发。
“Each of those steps is a turn, and each turn resends the conversation so far.” ¶2
这一点暂无对应的审视。
缓存命中率对输入成本的影响，比任何设置都大。
同样 2.8M 输入，完全不走缓存要 $11.20，命中 90% 是 $1.62，命中 96% 约 $0.99。原因是 Opus 5.5 的缓存读只按新鲜输入价的 5% 计（从过去的十分之一降到二十分之一）。缓存存的是前缀，只要请求开头和上一轮一致就能复用；会话稳定地往末尾追加内容，命中率自然就高。
“No other setting moves input cost this much.” ¶19
全文的示例算价都不算缓存写入，但同一篇文章又说一次写入顶 25 次读。只要发生停顿、换模型、compaction、接 MCP，真实成本就会比示例高，而且这几类事件在无人值守流水线里并不少见。
输出 token 最贵，而且思考也按输出计费，所以 effort 对账单的影响很大。
在 Opus 5.5 上，一个输出 token 的价格是缓存读的 100 倍。典型任务的 60K 输出花 $1.20，相当于从缓存读 6M token。effort 主要决定模型想多少；Claude Code 界面上只显示思考摘要，但完整的思考 token 全部计费。
“Output includes thinking. You pay for all of it” ¶20
这一点暂无对应的审视。
升级的顺序是：先给模型检查手段，再升 effort，最后才换更大的模型。
典型症状是「只修了一层」：medium 档改了 handler，handler 自己的测试也过了，但客户端还在发旧字段。要是有一条贯穿客户端的测试，medium 档在写下这行代码的那一轮就会失败，问题当场暴露。跑一次测试只花一轮和它的输出；升 effort 则是每一轮都多出思考量。原文算了一笔账：high 档在整个任务里多花 20K 思考 token，约 $0.40，和一个十轮的重试循环差不多，所以只有在它能省掉一次重试的任务上才划算。
“before you raise effort, check whether the model has a way to check its work” ¶52
全文只讲成本，没量化「省钱导致任务失败或质量下降」的概率。原文的重试成本论证用的是假设数字（high 多 20K 思考 vs 十轮重试），medium 多常出现「只修一层」也没有数据。
会话开始时把配置定好，中途不要动：有好几类操作会让缓存整段重写。
以下情况会触发缓存写入：停顿超过缓存寿命；在 Bedrock、Google Cloud、网关上改 effort；会话里第一次开 fast mode；连接或断开 MCP server；切换模型；compaction（压缩会话）。改工具定义会清空整个缓存。120K 上下文下，写一次五分钟缓存约 $0.60，读一次约 $0.02，一次写顶 25 次读。另外，用 API key 或订阅时，中途改 effort 不会丢缓存。
“So set these up when the session starts, and leave them alone while it works.” ¶84
「xhigh 两次卡在同一问题就换 Fable 5.1」是往更贵模型引导的经验法则，没有给出依据数据；而且换模型会让缓存整段重写，原文对这部分成本只给了定性描述。
「Opus 5.5 便宜 40%」不等于单价降了 40%：单价本身的降幅要小得多，剩下的部分要看每个任务实际少用多少 token。
Fig B 用相同的 token 数给同一段会话算价，只体现单价变化，结果约便宜 31%。40% 是厂商对 medium 默认档、按 token 计费的典型负载做的估计，额外假设了每个任务用的 token 更少。但 Opus 5.5 回答前总会先思考，在某些任务上反而可能用得更多。原文的判断是：任务边界清楚时两边轮数差不多，基本只吃到降价；开放式任务的差距可能最大。
“so it isn't a 40% cut to the price of a token” ¶27
「便宜 40%」和「订阅额度能多用约 25%」都是厂商估计，前者还依赖「每任务用更少 token」这个没有公开数据的假设；文末也承认 Opus 5.5 总会先思考，可能用更多 token。
作者没有直接谈到这一点。
/usage 的美元数是在本机按标价算的；在订阅下它只是工作量参考，不是实际花费。
作者没有直接谈到这一点。
prompt-audit 的 18%、9%、25% 来自一个包含 44 张工单的内部客服基准，起点还是 Opus 4.8，外部无法复现，原文自己也说只能当例子。
作者没有直接谈到这一点。
文章面向交互式编程会话，没讨论无人值守的 headless 定时任务：没人能在「medium 卡住时」手动升档，降级和换模型的时机也只能由脚本决定。
每一轮都要把整段会话重发一次，所以少跑一轮往往比降低单价更省钱
任务成本的主变量是轮次，不是单价：多一轮就多付一次「把之前全部内容重发」的钱，所以最省的一轮是不需要的那一轮。
agent 循环每走一圈就是一次请求，请求里要带上到目前为止的整段上下文。原文的例子：上下文从 20K 涨到 120K，跑 40 轮，累计输入约 2.8M token，缓存命中 90% 时输入费约 $1.62；同一任务压到 25 轮，累计约 1.75M、$1.02。对话本身从没超过 120K，但累计输入是对话体积的许多倍。省轮次的两个办法：给模型一个自检手段（测试、build、调接口的脚本），以及让它一次把需要的东西收集齐、把工具调用合并批量发。
Each of those steps is a turn, and each turn resends the conversation so far.
¶2 ↗
缓存命中率对输入成本的影响，比任何设置都大。
同样 2.8M 输入，完全不走缓存要 $11.20，命中 90% 是 $1.62，命中 96% 约 $0.99。原因是 Opus 5.5 的缓存读只按新鲜输入价的 5% 计（从过去的十分之一降到二十分之一）。缓存存的是前缀，只要请求开头和上一轮一致就能复用；会话稳定地往末尾追加内容，命中率自然就高。
No other setting moves input cost this much.
¶19 ↗
输出 token 最贵，而且思考也按输出计费，所以 effort 对账单的影响很大。
在 Opus 5.5 上，一个输出 token 的价格是缓存读的 100 倍。典型任务的 60K 输出花 $1.20，相当于从缓存读 6M token。effort 主要决定模型想多少；Claude Code 界面上只显示思考摘要，但完整的思考 token 全部计费。
Output includes thinking. You pay for all of it
¶20 ↗
升级的顺序是：先给模型检查手段，再升 effort，最后才换更大的模型。
典型症状是「只修了一层」：medium 档改了 handler，handler 自己的测试也过了，但客户端还在发旧字段。要是有一条贯穿客户端的测试，medium 档在写下这行代码的那一轮就会失败，问题当场暴露。跑一次测试只花一轮和它的输出；升 effort 则是每一轮都多出思考量。原文算了一笔账：high 档在整个任务里多花 20K 思考 token，约 $0.40，和一个十轮的重试循环差不多，所以只有在它能省掉一次重试的任务上才划算。
before you raise effort, check whether the model has a way to check its work
¶52 ↗
会话开始时把配置定好，中途不要动：有好几类操作会让缓存整段重写。
以下情况会触发缓存写入：停顿超过缓存寿命；在 Bedrock、Google Cloud、网关上改 effort；会话里第一次开 fast mode；连接或断开 MCP server；切换模型；compaction（压缩会话）。改工具定义会清空整个缓存。120K 上下文下，写一次五分钟缓存约 $0.60，读一次约 $0.02，一次写顶 25 次读。另外，用 API key 或订阅时，中途改 effort 不会丢缓存。
So set these up when the session starts, and leave them alone while it works.
¶84 ↗
「Opus 5.5 便宜 40%」不等于单价降了 40%：单价本身的降幅要小得多，剩下的部分要看每个任务实际少用多少 token。
Fig B 用相同的 token 数给同一段会话算价，只体现单价变化，结果约便宜 31%。40% 是厂商对 medium 默认档、按 token 计费的典型负载做的估计，额外假设了每个任务用的 token 更少。但 Opus 5.5 回答前总会先思考，在某些任务上反而可能用得更多。原文的判断是：任务边界清楚时两边轮数差不多，基本只吃到降价；开放式任务的差距可能最大。
so it isn't a 40% cut to the price of a token
¶27 ↗
「便宜 40%」和「订阅额度能多用约 25%」都是厂商估计，前者还依赖「每任务用更少 token」这个没有公开数据的假设；文末也承认 Opus 5.5 总会先思考，可能用更多 token。
全文的示例算价都不算缓存写入，但同一篇文章又说一次写入顶 25 次读。只要发生停顿、换模型、compaction、接 MCP，真实成本就会比示例高，而且这几类事件在无人值守流水线里并不少见。
/usage 的美元数是在本机按标价算的；在订阅下它只是工作量参考，不是实际花费。
prompt-audit 的 18%、9%、25% 来自一个包含 44 张工单的内部客服基准，起点还是 Opus 4.8，外部无法复现，原文自己也说只能当例子。
全文只讲成本，没量化「省钱导致任务失败或质量下降」的概率。原文的重试成本论证用的是假设数字（high 多 20K 思考 vs 十轮重试），medium 多常出现「只修一层」也没有数据。
文章面向交互式编程会话，没讨论无人值守的 headless 定时任务：没人能在「medium 卡住时」手动升档，降级和换模型的时机也只能由脚本决定。
「xhigh 两次卡在同一问题就换 Fable 5.1」是往更贵模型引导的经验法则，没有给出依据数据；而且换模型会让缓存整段重写，原文对这部分成本只给了定性描述。