给努力程度封顶：maxEffortLevel 怎么卡住成本
团队共用 Claude Code 时，最怕有人把 effort 拧到最高挡，账单和延迟一起起飞。CLI 2.1.267 起可以用 maxEffortLevel 设天花板：写在顶层，或写在 modelSettings 里按模型分别限制；对 Bedrock、Vertex、Foundry 等通道同样生效。用户仍可以选更低的档，但不能越过管理员设的上限。
这是配置层的成本闸门，不是再包一层包装脚本去改环境变量。
它管的是什么
「努力程度 / effort」影响模型愿意花多少推理与工具回合去啃同一题。上限越高，往往越「较真」，也越贵、越慢。maxEffortLevel 的职责是：
- 管理员设天花板（组织级 managed settings 或项目约定）。
- 个人可下调（省额度、加快简单改动）。
- 跨提供商一致：不只官方 API，Bedrock / Vertex / Foundry 也吃这套上限。
和周限额不是同一根轴：限额管「这周还能不能用」，effort 管「这一问愿意打多深」。限额说明见站内周限额相关文；本文只谈努力程度封顶。
怎么配
changelog 表述：可放在顶层，或放在 modelSettings 下按模型。典型意图：
| 写法 | 适用 |
|---|---|
顶层一个 maxEffortLevel | 全队统一天花板，规则简单 |
modelSettings.<模型>.maxEffortLevel | 贵模型拧紧、便宜模型略松 |
具体键名与合法枚举以你安装版本的设置 schema / /config 为准；改完用新会话验证，并让成员看一眼当前档位是否被夹住。
建议落地顺序：
- 先在小范围（一个项目或一个小队）设中等上限，跑几天看完单率与 token。
- 硬重构、大范围排查的窗口再临时抬高；日常修 bug 保持封顶。
- CI 与
-p脚本单独约定：自动流水线通常比交互会话更应该「封顶 + 失败退出」，避免静默烧钱。
和「静默夹紧」的心理预期
封顶之后，用户若选了更高档，客户端应表现为落到上限（而不是神秘失败）。对共享额度池，这比「允许超标再事后追责」好管。若你的组织更希望「超标直接失败」，那是策略选择，需要在文档里写清，不要只改数字不说人话。
顺带：--system-prompt-snapshot off
同版本还加了 --system-prompt-snapshot off：让系统提示在每次请求重新渲染，而不是会话内拍一份快照反复用。
什么时候有用：你在快速迭代 Skills / 钩子 / 会改系统提示的配置，希望下一轮立刻吃到新提示。
什么时候要小心：系统提示很长时，每轮重渲染可能影响缓存命中与延迟，token 与耗时都会上去。默认快照适合稳定会话；关掉是调试与提示迭代的开关，不是日常默认。
社区里有人把它和「skill 迭代加速」绑在一起用——合理，但别在生产长会话上长期关着玩。
小结
- 2.1.267：
maxEffortLevel全局或按模型封顶，Bedrock / Vertex / Foundry 一并覆盖；用户可下调不可上越。 - 先定组织天花板，再谈个人偏好；和周限额分开看。
--system-prompt-snapshot off利于提示迭代，长提示下有缓存与成本代价。
先 claude --version 确认 ≥ 2.1.267，再把封顶写进团队 settings，而不是靠口头「别开太高」。