每开一个新会话，先挑模型，再挑推理档位。我数过，一天三十次上下，多的时候五十次。
以前我从来都是拉到最高档，理由很省事：贵一点总不会更差吧。
十月十五号 Dex Horthy 那份 SlopCodeBench 更新，把这句话打掉了。
先把边界说清楚：这次跑的是完整基准，36 道题、196 个检查点，跟五月那次三题六题的子集不是一回事，两个数别直接对着看。我只关心一件事——同一个模型，档位从中调到最高，通过数涨不涨。
答案是不怎么涨。
Opus 5.5 从 Medium 换到 XHigh：严格通过 28 掉到 25，核心通过 145 掉到 141，成本 4.22 倍。GPT-6 SOL 那边 30 掉到 26，核心通过从 133 微升到 134，成本 2.11 倍。三组能对比的设置里只有 Astra 是升档真涨的，29 到 32，代价 2.91 倍。而全榜最高的 Astra XHigh 是 32/196，只比第二名多过两个检查点，估算成本 758 美元。
两个检查点，七百多美元。
Fable 5.1 XHigh 更离谱，一千五百多美元，是 GPT-6.1 SOL Medium 的 8.68 倍，严格通过反而少三个。
⚡ 所以我做的事就一行：把项目应用里那个默认模型设置从中高档改回中档，只有真卡住的时候才手动升。
我的 CLAUDE.md 里现在挂着这么一句：
默认走 Medium。同一个问题连错两次，或者要跨三个以上文件动签名，才手动升 XHigh。
复制粘贴就能用，两分钟的事。改的是默认值，不是每次开新会话靠意志力去选。
这儿得插一句自我更正。上面我把话说得挺满，但作者自己在文里写明了：每个模型每个档位只跑了一次，分不清多少是运行之间的波动。所以这份数据能撑住的只是“升档没有稳定回报”，撑不住“升档有害”。区别很大，我不想在这一步上含糊——我自己最烦那种没有对照的倍率口号，不能转头自己也来一个。
档位说完，说点更值钱的。
这份基准里我最想抄进日常工作的，是它那个通过标准。它把“过”拆成两种：核心通过只要求非空的 Core 类别全过；严格通过要求这个检查点上所有测试类别全过，含回归。而且前面的检查点挂了，后面的检查点照样能拿到核心通过。
翻译成干活的话：新需求做出来了，旧行为悄悄坏了，分数照样拿到。
差距有多大？Opus 5.5 Medium 核心通过 145/196，73.98%，全场最高；严格通过 28/196。同一批代码，同一套题。
你在自己仓库里怎么撞上这件事，应该不用我描述。加个字段，agent 顺手把序列化改了；改个接口，三个调用点里有一个还是老签名，而那三个点的测试你本来就没写。
所以跟默认档一起改的还有第二个习惯：接受改动之前先跑回归，别跑全量，先跑上一次挂的那批。
pytest -q --lf
一步到位，比你肉眼看 diff 快得多，也比你相信那句“所有测试通过”靠谱。
还有个细节我单独记了一笔，因为它反过来提醒我别把“更干净”当“更对”。XHigh 的 Opus 5.5 在 slop 占比上是 77.75%，Medium 是 94.25%——大概干净五倍，严格通过却更少。代码更干净，事没办成。而且那套检测规则是三月论文加五月 v1.1 里两百多条手工规则，新模型完全可能长出规则没覆盖的新毛病，所谓“更干净”里有多少是“没被扫到”，作者自己都说要谨慎读。这条我不下判断，只记着。
最后给个让人清醒的数字：五月那次严格通过 14.8%，这次 16.3%。五个月，一个半点。外面讲得热闹，账面上就这么点。
你能改的从来不是模型那一侧，是自己那一行被吃灰的默认值，和改完代码之后那一步测试。
这笔账很好算：改配置两分钟。一天三十次，每次开局犹豫两秒，一分钟没了；一年六小时，够我把拖了半年的那个脚本写完。按同样的倍率往自己账单上套，更是肉疼。三分钟成本，一周内回本。
限定一句：如果你手上的活全是那种一口气动五个文件、改完还得自己重新想一遍架构的硬骨头，这条别听我的，该拉满就拉满。工具是拿来把事办成的，不是拿来省 token 的。
你们要是有更快的写法，教教我。