让Fable当包工头，省下的是额度，赔进去的是返工

Fable 5.1上线后，有人分享了一种省额度的方法：让Fable只做计划和验收，写代码这类实现工作全交给Opus或Sonnet的Subagent，好让Fable额度和总额度两条进度条走得一样快。
出发点可以理解。Fable额度先耗完就得换模型，大家都想把它用在刀刃上。
但我不同意。省额度可以，不能靠把一个任务切碎来省。分工可以横着分：Fable做计划，Opus完整施工，Fable再验收。但不能竖着分：让Fable当包工头，带一群只交摘要的Subagent干活。
Fable 5.1的缓存读取价格降到了Fable 5的四分之一，官方就是在鼓励你把长任务留在同一个上下文里。你却把它固定成只看摘要的包工头，等于请了一支能包整套装修的施工队，只让队长站在门口收进度表。
更大的问题是，Subagent交付时会筛选信息。它读了几十个文件，排除了几个方向，最后只汇报一句“问题出在缓存，已修复”。结论可能没错，但哪些线索被排除、测试里出过什么异常、什么细节可能推翻这个判断，都在摘要里消失了。
装修里这叫返工。水电队开墙看见旧管线，但任务单只写了移插座，于是报告“线路正常”。木工照尺寸装柜，吊顶照图纸封板，各自验收都合格。装完才发现插座被柜子挡住，管道和吊顶打架，只能拆掉重来。每支队伍都没错，错在现场被切成了几张任务单，开墙时看到的情况没有传给下一个人。
总包当然可以加强验收，要求照片和测试全部回传。但验收越细，总包重新理解现场的活就越多，分包省下的工时也被吃掉了。
所以Subagent我只用在信息损失小、结果一眼能验的地方，比如搜代码、跑测试、做机械修改。需要跨很多文件理解关系、做着做着还会改方案的任务，我让Fable留在同一个上下文里做完。要不要开Subagent，交给主模型按现场判断，默认不开。
另一条路线也完全可以，Fable出完整计划，整个实施交给Opus 5 xhigh，做完再让Fable复核、Opus修改。效果可能不如Fable亲自下场，但成本低很多，能力也都用在了刀刃上。
这就是设计师出方案，施工队完整施工，监理最后验收。三个角色各干各的，谁的能力都没被切碎。反过来让Fable带着Opus当小弟，损耗出在层层交接上，不是Opus不行。
分工可以横着分，不能竖着分。别让Fable当包工头，让它当设计师和监理。