Cognition 用 Fable 5 替换了 Opus 4.8，Devin 的成本反而降低了。Fable 5 每 token 的成本是 Opus 4.8 的两倍，但 Cognition 通过一种架构设计，使 Fable 在成本更低的同时得分更高。本文分析了该公司如何实现这一目标，以及这对代理工作的定价意味着什么。

让 Fable 比 Opus 更便宜

我们使用 Fable 5 替换了 Opus 4.8，结果 Devin 的成本下降了。

Fable 5 每 token 的成本是 Opus 4.8 的两倍。但当我们采用新的 Fusion 架构在 FrontierCode 1.1 上运行这两个模型时，Fable 的成本更低。不出所料，它的得分也更高。本文将解释原因，以及这对代理工作的定价意味着什么。

引言

所有运行编码代理的人都知道，更强的模型能带来更好的结果，但代价是成本飙升。

当我们推出 Devin Fusion 时，我们展示了一条出路：让一个前沿模型负责主导，让它委派给一个更便宜、更快的副手，就能在成本降低 35% 的情况下获得前沿级别的性能。

但一旦主导模型委派了大部分工作，它的每 token 价格是否仍然主导总成本？Fable 5 每 token 的成本比 Opus 4.8 高 2 倍，因此由 Fable 主导的代理理论上成本更高。为了验证，我们在 FrontierCode 1.1 上运行了 3,000 次评估会话，涵盖四种配置：Fable 和 Opus 分别担任主导角色，每种配置又分有/无相同廉价副手两种情况。

纯模型运行的结果完全符合直觉：Fable 得分高于 Opus（60.8 vs 55.4），但成本也更高。更好的模型，更大的账单。

引入副手后的运行情况才真正有趣。

在相同副手的情况下，成本顺序发生了逆转：Fable + 副手的成本低于 Opus + 副手（$1.86 vs. $2.04），而得分更高（60.7 vs. 54.6）。 与纯 Fable 相比，Fable + 副手将成本降低了 54%，同时得分几乎不变。

原来，2 倍的每 token 溢价并不是需要关注的关键数字。代理的成本主要取决于主导模型参与了多少轮对话，携带了多少上下文，以及最重要的——它自己决定不做什么。差异归结为管理风格：Opus 像是一个带着实习生的微观管理者；Fable 则是一个带着能干的工程师的经理。

架构设置

快速回顾一下 Fusion 的副手架构工作原理。主导代理掌控整个会话：它与用户对话、制定计划、审查工作并提交代码。它还拥有一个持久的副手子代理，用于委派任务。主导代理用自然语言编写一份交接摘要，然后由使用更便宜模型的副手在其自身的上下文中执行任务并报告结果。主导代理审查结果并决定下一步操作。

为了找出成本去向，我们做了两件事。首先，我们解析了全部 3,000 次会话中的每一次 LLM 调用：哪个模型在说话、调用了什么工具、读写多少 token、每次调用花费多少。其次，我们挑选了 40 个任务进行深入分析：其中 Fable 成本显著更低的、Opus 成本更低的，以及从中部随机抽取的样本。对于每个任务，我们将 Fable 主导的运行与 Opus 主导的运行进行对比，分析其轨迹，并观察资金流向。

代理的成本

下面是实验中成本在主导模型和副手之间的分配情况：

Fable 在副手上的支出比 Opus 多——每次运行多 $0.27。但它自己在自己身上的支出少了 $0.45。Fable 的主导模型每次运行仅需 11.5 轮对话，而 Opus 需要 26.5 轮；Fable 的输出 token 只有 Opus 的三分之一（6.1k vs 19.0k），输入 token 也只有三分之一。Fable 每 token 的成本明显更高，但在上下文管理和轮次数量上胜出。

Fable 的 token 节省源于直接避免了大量工作。有趣的是，在 81% 的 Fable 主导运行中，主导模型从未进行过任何代码编辑。对于 Opus，这一比例仅为 24%。在 13% 的 Fable 主导运行中，主导模型甚至从未自己阅读过仓库文件。

微观管理者 vs. 能干的工程师

这正是差距的有趣之处：两个主导模型委派的次数相同，每次运行约 3 次交接。逐调用日志推翻了“Fable 只是委派得更多”的简单解释。区别在于何时委派以及委派什么。Fable 的第一次交接很早。Opus 往往在较晚的时候才委派，通常在经历了漫长的独立探索和实现之后；到那时，设计决策已经做出，重要文件已经加载到上下文中，昂贵的部分已经完成。

GIF

Fable 主导的典型运行流程：先对仓库进行几次侦察操作，然后编写一份类似规格说明的摘要，将整个“实现+测试+lint”循环委派出去。接着用一次 git show 审查差异，最后提交。

Opus 主导的典型运行流程：通过 20–45 轮对话独立完成探索、设计和实现，最后进行一次晚期的交接，处理机械性收尾工作。

有时 Fable 在会话中的第一个动作就是一次交接。在同一项任务上，两个主导模型的开始方式如下：

明显的解决办法是让 Opus 委派更多的探索工作，但强行施加这种行为往往会降低性能。知道何时可以安全地将调查委派出去，何时需要自己完成，这本身就是一种判断力。被强迫委派的模型并不会获得这种判断力，它只会委派错误的事情。

每个模型的管理风格也在交接摘要中体现出来。当 Opus 委派实现任务时，它会下达指令；而 Fable 则会编写一份设计文档：

委派不仅转移了成本，还改变了工作质量。上面的哈希任务就是一个鲜明的例子。任务规范要求哈希函数在指针长度上是 O(1)。Opus 手动实现了该函数，但从未在任何地方写下这个要求。在某个环节它忘记了这个约束，交付了一个线性时间复杂度的实现，得分仅为 25。相比之下，Fable 使用高级约束进行委派。它的摘要中写道：“operator() 必须是指针长度的 O(1)：不允许全 token 扫描。”副手成功实现了这一约束，得分为 94。

我们发现这一模式在各项任务中普遍存在。Fable 的交接会列举约束条件、边界情况和“完成”的定义，从而节省了自己的精力，同时让副手能够廉价且正确地完成实现。

交接之后

另一半情况是主导模型如何处理副手返回的工作。两个主导模型经常执行相同的廉价检查：两三次 git diff / git show 调用。但 Opus 并不会就此打住。它更频繁地将副手的文件拉回自己的上下文（2 倍频率），并以主导模型的价格进行 4 倍多的修正性编辑。在极端情况下，它甚至撤销了副手的工作并手动重写：

Opus 的不信任也并未提高正确性。在某些评估任务中，Fable 的一次 diff 审查就发现了副手实际存在的 bug，并选择了另一次廉价委派，而不是像 Opus 经常做的那样进行主导级别的重写。

何时委派没有帮助

Fable 的委派策略并非普遍有效；当任务没有可委派的组成部分时，它就会失败。以下类型的任务似乎难以分解：

• 只包含少量主导模型轮次的短任务，在决定和交付之间没有可委派的内容。
• 根因排查是一长串连续判断链条的串行调试任务。在这种情况下，累积的上下文本身就是工作。

值得注意的是，在遇到这些任务时，Fable 几乎不进行任何委派。那种能够写出优秀摘要的判断力，同样知道何时不该写摘要。但当任务没有任何值得委派的内容时，委派就无法对成本产生杠杆作用。

在生产环境中，Fusion 通过另一层机制处理这个问题：委派控制哪些工作留在昂贵模型中，而路由决定是否完全需要昂贵模型参与。

结语

我们开始这个实验时，原以为会衡量 Fable 的 2 倍溢价会带来多少成本增加。令我们惊讶的是，Fable 有效的委派反而整体降低了成本。它描述了约束条件和预期结果，而不是详细列出实现步骤；它给出反馈而不是亲自修复代码；在大多数情况下，它甚至从未碰过代码本身。这些都是优秀经理的习惯。

随着副手模型变得更便宜、更强大，更多的工作可以交给它们。未来值得为前沿模型付出的成本将是判断力：构建什么、约束什么、以及由谁来编写。