Opus 5推理强度并非越高越好，中等档位性能最佳

有用户使用FrontierCode编程基准对Opus 5的推理档位从Low到Max进行了全面测试。结果发现，性能并非随档位提升而单调递增，而是呈现倒U型曲线：Medium档位达到性能顶峰，Max档位反而下降。这一发现颠覆了“推理强度越高越好”的直觉。

推理档位本质上是推理预算的闸门，控制模型思考的余量。档位越高，模型在动手前思考的时间越长、越深。然而，当任务本身不需要那么多思考量时，多余的预算会导致模型反复校验、重复梳理已有结论，甚至偏离原始需求。

在代码修复场景中，低档位（如Low）会针对性地输出补丁，仅修复几行函数的bug。但拉高强度后，模型富余的算力会驱使它擅自重构无关函数、调整导入、重命名变量，甚至优化无关代码。一份小问题直接扩成了完整的PR，多给的预算反而成了负担。

这一痛点在Opus 5身上尤为明显，模型一言不合就给自己“加戏”。Anthropic在提示词指南中几乎明示用户将推理档位调低：只要评测能证明质量不掉，就大面积使用Low和Medium以压降成本和延迟，高档位留给真正硬核的长周期任务。

尽管Anthropic建议用户优先使用Low和Medium档位，但Opus 5发布时，推理默认值却被设为High。这一矛盾导致许多用户在不经意间选择了过高档位，承受了不必要的成本和质量风险。

用户可通过API修改output_config.effort参数，或在Claude Code配置中更换默认档位。调整后，模型不再“满地撒欢”，输出token大幅缩水，结构化任务的质量反而更好了。

最优策略是按任务分层：格式化、信息提取等机械任务使用Low；日常编码、代码审查使用Medium或High；只有需要长时间自主推理的长周期Agent任务才启用xHigh或Max。

然而，切换档位会清空上下文缓存，因为effort档位是缓存匹配标识。即使单轮单价下降，缓存失效导致的重复加载可能使总成本上升。因此，建议为工作流锁定单一档位，全程不调整，以持续命中缓存，压缩整体开销。