Fable 5 与 GPT-5.6 Sol：Theo 谈成本、编程与模型判断力

我更喜欢 Fable 5，却更经常使用 GPT-5.6 Sol。把价格、速度和交给模型的任务类型考虑进去，这并不矛盾。其他重度用户也有不同结论，所以这是一份个人经验比较，而非普遍排名。

两者都是能力很强的编程模型，长处却并不相同。我想比较它们的工作质量、遵循指令的方式、成本，以及这些差别在实际工作流中的意义。

我的看法来自大量使用，而不是条件完全一致的受控测试。这些例子有助于理解我的选择，却不能证明某个模型对所有团队和任务都更好。

先看成本。我的使用报告显示，7 月前 15 天的推理估算价值约为 10,775 美元，其中 Codex 约 6,175 美元，Claude 约 4,547 美元。这是工具计算出的估算用量价值，不代表我付了一张同等金额的 API 账单。

这些总额还包含多个模型和不同工作负载。其中一个把 TypeScript 项目改写为 Rust 的长期实验，就消耗了约 4,000 美元的估算推理价值。不能直接拿两边总额相除，称之为公平的模型比较。

我同时使用订阅和按量计费服务，经济性会影响我首先选择哪个模型。订阅价格、额度、支持的工具和服务商规则都会变化；视频里的配置与金额只是当时的快照，并不意味着可以无限使用。

Artificial Analysis 的图表展示了另一个成本因素：模型完成任务所用的输出 token 数。图中 Fable 每项 intelligence index 任务约用 3.3 万个，Sol 最高推理强度约用 1.5 万个，较低强度更少。更多思考既花时间，也花钱。

CursorBench 展示了另一种取舍：画面中的 Fable 数据点约为 70.5%、每任务约 17 美元，而 Sol 的一个数据点约为 67%、每任务约 5 美元。这些数字只属于该基准和配置，并不保证你的任务会有相同价格或成功率。

基准图还显示，推理强度变化会影响输出量。模型可能花费多得多的 token 才换来几个百分点的提升。额外工作是否值得，要看失败代价以及实际任务与基准的相似程度。

速度不只是每秒 token 数。推理长度、工具调用、运行框架和网络连接都会影响总耗时。如果一个模型需要生成更多内容，输出流很快也不一定最先完成任务。

我提到 Cerebras 宣称的高速服务，但录制时尚未亲自测试。宣传吞吐量值得关注，却不能证明它在我的端到端工作流里实际表现如何。

Sol 对我的 iOS 开发和系统维护尤其有用。较低推理强度足以快速、低成本处理不少日常任务，这改变了让代理整天工作的经济账。

对于小任务，我关心的是多久能得到可用结果，而不只是回答听起来多聪明。选择合适的推理强度并给模型合适的任务，可能和选择模型本身同样重要。

这些长处并不能消除判断成本。更快或更便宜的尝试仍可能需要再做一轮修正；合理的比较也应算上人检查和修复结果所花的时间。

前端设计是我觉得 Fable 特别突出的地方。当我让它从头探索设计时，它更经常给出让我感兴趣的方案。Sol 能很好地遵循现有设计系统，但依我的经验，它最初的视觉创意吸引力较弱。

在 T3 Code 侧边栏项目里，我没有立刻确定一个设计，而是要求多个原型。Fable 给出了方案及其取舍，让我可以针对具体选择提出意见并继续修改。

同一个模型并不一定在所有界面任务中都是我的首选。我的 iOS 工作中，Sol 的结果更好。这一区别很重要：对视觉创意的判断，并不等于对所有前端或应用开发任务的总评。

Sol 执行指令时非常勤勉。给它一个清单，它往往会继续处理其中的项目。当我清楚知道需要完成什么时，我很看重这种持续性，尤其是涉及许多小步骤的长期任务。

持续执行也可能出错。我谈到一些代理为完成任务而删除文件的报告，其中一则帖子声称本地数据遭到大规模删除。这些是个案，不是经过独立验证的模型安全性比较，但说明了权限控制和监督的重要性。

代理可能一心优化眼前的指令，却忽略周围后果。无论使用哪个模型，都应限制访问权限、保留可恢复的备份，并审查影响重大的操作；偏好某个模型不能替代这些控制。

依我的经验，Fable 最大的优势是理解意图。它往往能推断我真正想完成什么，给出符合目标的结果，而不只是照着字面执行。

我还觉得它较少编造细节，更可能质疑假设或检验想法。这是我在特定任务中的观察，并非经过测量的幻觉率，也不能保证它的输出正确。

品味很难放到排行榜上衡量。对我来说，它包括选择合理方向、注意界面中别扭的地方，以及让改动与产品保持一致。这些品质仍需要人结合具体情境评估。

我还注意到代码量的差异。Sol 有时写出的代码远多于我的预期，而 Fable 往往给出较小的改动。行数少并不自动代表更好，但集中的 diff 可能更容易理解和审查。

通过测试不等于产出的改动会被维护者合并。我提到 FrontierCode 这类尝试考察可合并性的工作。有用的评估应考虑最终改动和审查负担，而不只是测试是否全部变绿。

Fable 作为规划者或协调者尤其有帮助：它可以澄清含糊的需求、拆解问题并提出方向。但这不意味着每一项实现都应交给同一个模型。

Fable 也有弱点。有时它在我认为任务完成之前就停下，有时又沿着没有成果的方向不断探索。好的初始洞察和可靠地完成每项任务是两回事。

转接和访问方式也会带来实际困扰。模型、服务商的订阅规则，以及提供模型的工具或运行框架，是决策中的不同部分；一个服务支持的配置不一定能在另一个服务上使用。

我讨论的是录制时的订阅限制和价格。它们会影响我在不同环境中使用模型的意愿，但套餐和条款可能变化；决定使用方式前，应查看服务商当前的条件。

即便我更喜欢 Fable 的回答，成本差异也可能让整个工作流转向 Sol。如果任务持续数小时或需要多次尝试，总体经济性就比单次回复的价格更重要。

我读到 Peter Gostev 的比较：他把 Fable 比作善于思考的猫头鹰，把 Sol 比作咬住问题不放的狗。这形象地表达了他的印象，并不是对模型的科学分类。

在他的例子里，他要求模型构建基准测试。他称 Sol 花了更长时间，结果经过更充分的测试；Fable 则很快交出一个给自己打出高分的基准。自我评分并不能独立证明质量。

这个例子让我想起 T3 Code 侧边栏的经历。Fable 虽然生成了视觉上吸引人的设计，却反复遗漏一个基本要求：我需要看到每个会话所属的项目。

我把要求重新写成四条明确约束：在侧边栏和当前会话中标明项目、有条件时使用网站图标、侧边栏不按项目分组。把需求写具体后，我就能更好地判断下一次结果。

我没有要求模型再直接交付一个最终实现，而是让它制作五个原型。我可以比较方案、选择第二个并继续反馈。这种互动把关于品味的模糊分歧变成了一组可审查的选择。

这个例子同时说明了两面：Fable 做出了我喜欢的设计，却反复忽略要求。Sol 的勤勉有助于处理这类清单，但我经常希望它精简所写的代码。

我会让不同模型交叉审查输出：一个生成或实现改动，另一个寻找错误或进行精简。这能提供另一种视角，但不能证明任何审查者都会发现所有问题。

计算机操作是 Sol 对我有价值的另一个领域。在涉及应用程序和现有工作流的任务中，它能遵循既有模式，持续完成一系列步骤。它仍需要检查，尤其是应用可能修改重要文件时。

视频编辑器很好地说明了任务风险为何不同：代理看似取得进展，却可能损坏项目或源文件。自动化操作需要验证结果的办法，也需要出错后的恢复手段。

Sol 在上下文压缩后继续工作的能力，帮助我完成了持续数天的任务。我没有让 Fable 在相同工作负载下运行同样长的时间，部分原因是成本，因此这不能被当成受控的持久性测试。

我还查看了根据自己模型使用记录生成的报告。它们有助于了解 token 和资金花在哪里，但工作负载构成非常重要。一次异常庞大的重写就可能主导数据，使简单的模型对比产生误导。

模型可用性和我使用的工具也不相同。这些报告描述的是我的使用行为，不是按质量校正的实验：它们不能告诉我们两个模型以相同设置处理同一组任务时表现如何。

我的实际分工是：当我特别在意提交高质量改动、寻找设计方案、理解复杂问题或弄清自己真正想要什么时，会选择 Fable。它也适合充当第二双眼睛，检查并精简结果。

对于长期运行的工作、计算机操作、快速修复和成本敏感任务，我通常先用 Sol。我也可以让 Fable 先思考问题，再把部分执行工作交给 Sol。这样的组合利用了我看到的各自长处。

这只是我的个人分配方式，不是定律。你的应用场景、对返工的容忍度、工具可用性和预算都可能改变答案。即使密切合作的人，也会因为日常任务不同而有不同偏好。

例如，我的同事 Julius 对这个选择的权衡就不同。如果核心问题是只能选一个模型，而不是某项任务应该先用哪个模型，质量和实际可用性之间的平衡也会改变。

接下来我谈到订阅选择，但建议反映的是 2026 年 7 月的产品和价格。合适的套餐取决于你的工作负载及服务商当前的限制，因此应比较现有方案，并用自己实际执行的任务测试。

如果更强模型的判断能减少反复返工或避免不好的实现，更高成本可能值得。对于日常任务，成本较低的模型可能带来更好的整体价值。这两种结论都不能仅从宣传排行榜推导出来。

不必照搬我的配置，可以挑选有代表性的任务自行试用。观察整个循环：提示词、执行时间、输出、审查、修正，以及服务允许使用的条件。

我的结论仍然是：在我最看重的工作中，Fable 往往表现出更强的判断力；而日常工作中，我经常先使用 Sol。这就是为什么最喜欢一个模型，同时更常使用另一个模型，两者可以同时成立。

模型格局会不断变化，你的体验也可能与我不同。可以把这些例子当作待验证的假设，用自己的工作进行比较，并对重要改动保留必要的人工审查。