How-toSelected73°

Fable and Opus Loop Cuts Token Costs in Coding Workflows

最近摸索了一种新的节约 Token 但是效果不错的模式(都是被逼的,Token 太贵): Fable 写设计方案 -> (Loop 开始) Opus 执行 -> Advisor(Fable) 验收...

Why we picked it

The loop turns model review into an automated gate, so the expensive model spends tokens on planning and judgement rather than routine execution. Developers on metered Claude plans can replicate it with a single advisor command and one review prompt, cutting manual back-and-forth. The /compact timing tip matters too: compressing right after the plan is written lands while prompt caching is still warm, so it costs less than compacting after the cache expires.

Blogger Baoyu (dotey) shared a token-saving workflow that pairs a stronger model as a planner and reviewer with a cheaper executor model. He uses Fable to write the design document, then sets it as an advisor via the /advisor fable command so Claude's Opus and Sonnet models consult it automatically. Once Opus finishes implementation, it sends its work to Fable for acceptance review and fixes issues in a loop until approval, removing the need for the human to shuttle results between sessions. He also shares a variant using Fable 5 for planning, /compact to compress context while prompt caching is still active, and Codex (GPT-5.6 Sol xhigh) for execution.

Original · 宝玉

最近摸索了一种新的节约 Token 但是效果不错的模式(都是被逼的,Token 太贵): Fable 写设计方案 -> (Loop 开始) Opus 执行 -> Advisor(Fable) 验收...

最近摸索了一种新的节约 Token 但是效果不错的模式(都是被逼的,Token 太贵): Fable 写设计方案 -> (Loop 开始) Opus 执行 -> Advisor(Fable) 验收 (Loop 结束) 步骤是这样的: 1. 先 Claude 里面设置一下 advisor 为 Fable > /advisor fable 这样在使用 Opus,Sonnet 模型的时候,遇事不决它会请教 Fable,可能会有无谓的 Fable 消耗,但还是可以接受也值得 就好比请了个高级工程师当顾问 2. 复杂一点的问题先让 Fable 出方案,最大化利用 Fable 的能力。 就好比你让一个高级工程师写一个技术方案,让普通工程师去执行 3. 方案写好了确认了,让 Opus 去执行,但是执行的时候,加一句提示词: > 完成后让你的 advisor 验收一下,如果验收有问题就按 advisor 的反馈修复,修复完成后再让 advisor 验收,直到通过 advisor 的验收为止 可以配合 /goal 使用效果更佳 这样 Opus 在实施完成后就会找 Advisor 验收,通过 Advisor 就会给出反馈,然后 Opus 继续修改。 这样的好处就是整个过程你不需要人工去用 Fable 确认—— 以前我就是这么干的,Opus 执行完,我得回到之前 Fable 的会话去让它验收,或者新开一个会话,把文档发给 Fable 验收。 现在 Agent 自己就能形成闭环,不用你自己参与。 就好比你请了个高级顾问,复杂问题找顾问出方案,执行让你的工程师去按照方案执行,每次工程师做完自己去找顾问验收,顾问不仅验收还会告诉工程师哪里不对,然后工程师自己改,不用说每次做完找你,你再找顾问。 宝玉 @dotey 现在我很多复杂一点的任务都是 Fable 5 写方案,Codex 去执行,Fable 5 验收,相对来说可以做出比较靠谱的方案,以及兼顾性价比。具体是这么做的: 1. Fable 5 的产出是技术方案文档(图1) 一方面文档方便批注修改,另一方面文档方便其他 Agent 快速上手 2. 文档确认后在当前先 /compact 一次 这一步不是必要的,但是有好处,因为后续还要在同一会话去验证,/compact 压缩后,节约后续的上下文空间,之所以讨论方案就马上发送 /compact,因为这时候 Prompt Caching 还在,成本低,后面缓存过期了 compact 要贵一点。 3. 把文档交给 Codex (GPT-5.6 Sol xhigh)去执行(图2) 如果任务明显比较复杂,我一般会加上 /goal,这样中间就不需要反复去 continue,一次性把任务完成 4. Codex 完成后让 Fable 验证(图3) 直接告诉 Fable 其他 Agent 已经实施了,让它确认有没有遗漏,或者方向有无偏离。 如果有些遗漏之类的,把 Fable 的反馈发回给 Codex(图4),不需要新开会话,在同一个 Codex 会话,Codex 会根据反馈继续完善。 --- 如果用 Opus 5 替代 GPT 5.6 也可以,做法上可以跟上面一样新开会话,用文档传递上下文。 也可以直接让 Fable 5 开 SubAgent 并指定用 Opus 5 模型,并且要求在 SubAgent 完成任务后验证。 但是我执行下来 Opus 5 不如 GPT 5.6 Sol 稳定,也不如 GPT 5.6 Token 耐用,所以宁愿麻烦一点。 🔗 View Quoted Tweet 💬 4 🔄 9 ❤️ 74 👀 7442 📊 21 ⚡