Fable 5.1 对比 GPT-6 Astra：Theo 谈编程、计算机操作与成本

上周出现了两个真正影响我工作流程的模型：Claude Fable 5.1 和 GPT-6 Astra。它们都很出色，但差异足够大，简单选出一个赢家会掩盖各自的能力。我每天都用 Fable，认为 Astra 也是一次巨大飞跃；两个模型加起来，我每天用掉近十亿 token，因此见过它们的长处，也遇到过令人意外的弱点。

我想比较它们擅长和不擅长什么、token 使用效率如何，以及多快会碰到订阅额度。没有这些细节，推荐就会掩盖两者能力上的差异。

先看科学任务。Anthropic 展示了 Terminal-Bench Science 0.1：此前 Fable 5 花费 34 美元取得约 25% 的成绩，5.1 在超高推理强度下以更低成本达到约 50%。OpenAI 的图表显示，Astra 在低推理强度下以约 11 美元达到 54.3%，成本不到三分之一，成绩却超过 Fable 的最佳结果。这些是基准测试结果，并不保证适用于每项科学任务。

两个模型在科学和 3D 方面都取得了显著进步。我猜测共同的训练数据或强化学习工具可能发挥了作用，但这只是猜测。Astra 在 3D 方面的进步尤其醒目。Fable 制作的 Fish Slop 潜艇游戏已经有像样的鱼、珊瑚、灯光、小型经济系统和战斗，移动手感也出奇地好。

Fable 的第一个 Fish Slop 原型让潜艇在鱼群中移动、喂鱼并参与小型经济系统。鱼看起来确实像鱼，眼睛位置也对，操作手感也令人愉快。在看到 Astra 的版本之前，这已经是很出色的结果。

Astra 的版本看起来像是跨越了一代：鱼缸和环境令人惊叹。但它并非全面获胜，移动手感和核心玩法不如 Fable，我还得要求它修复性能。其他例子，包括 Blender 制作的亚马逊球形建筑和带家具的示范住宅，说明 Astra 能帮助制作实用的 3D 模型，而不仅是概念演示。

我还看到了用 Astra 制作的 Blender 项目，包括亚马逊球形建筑的复刻和 Thomas Ricouard 的示范住宅。住宅里有家具，窗外背景也很可信。对我来说，这种进步类似于从自动补全跃升到能够完成任务的代理。

与作品互动时，差异就显现出来。按我的经验，Fable 更擅长处理镜头移动、动画等精细的游戏交互。我会先用 Astra 制作原型、确定外观，再让 Fable 收拾细节。Astra 像一把大锤，Fable 则能更轻柔地修改。

画面领先并不能决定游戏开发的胜负。光标移动或镜头跟随鼠标时，动画曲线和速度的细小变化会影响游戏手感。尽管 Astra 的视觉效果更强，这些细节上我仍更喜欢 Fable。

计算机操作是 Astra 的另一大优势。它比 GPT-5.6 Sol 快得多，而进步不仅来自模型，也来自 Codex 在 macOS 上启动、获取上下文和后台工作的改进。我甚至另设了一台 Mac mini，让它全天执行任务。我的手受伤了，代理有时能比我更快完成电脑工作，尤其方便。

Sol 的计算机操作能力已经足够让我经常用它处理繁琐工作。Astra 让我扩大了这种用法，不过差距也部分来自 Codex 产品及其集成。我认为看过的基准测试没有充分体现日常使用中的区别。

即使没有特殊指令，两个模型写出的文字也比前代更易读。尽管原版非思考模型 Kimi K2 有其他局限，我仍更喜欢它的写作；这些模型生成的文案，我也经常亲自重写。Astra 的文字略胜一筹，能点评 Fable 的文案，但它建议的改写仍常常不够好。

Astra 能识别 Fable 生成文案中的问题并提出改进，但我仍常常自己重写。论文字质量，我给 Astra 略高评价；要得到有用的产品文案，两者都还需要人编辑。

Astra 令人烦恼的习惯是在界面里塞满不必要的副标题。Fish Slop 的一个版本清理前有 21 处，满页面都是类似“小鱼缸，大生命”的句子。如果模型坚持到处放文案，写得更好也帮不上多少忙；我不会在缺少仔细监督的情况下把界面工作交给它。

在音频和视频方面，两者都让我失望，不过我承认自己特别挑剔，别人的体验可能不同。Ben Davis 展示了一个有用的例外：Astra 可以操作电脑，帮剪辑师准备 Final Cut 项目，整理工作环境，而不是直接剪视频。即使创意剪辑仍由人完成，这种准备也可能节省时间。

这就像程序员开始工作前，助手帮忙打开正确的文件、终端和开发环境。助手没有完成创意工作，但已经把房间准备好了。Ben 的例子说明，Astra 可以为剪辑师做好类似准备。

现在看到的 AI 剪辑视频让我想起 2020 年 GPT-3 生成简单 React 应用的演示。当时那很惊人，但专业开发者不会直接发布那个应用。视频剪辑也许终有类似飞跃，但我认为目前这两个模型都还不能自动完成专业剪辑。由于计算机操作能力，Astra 在这一项略胜。

GPT-3 的 React 演示刚出现时很惊人，但那个小应用远远满足不了资深工程师做真实项目的需求。我认为炫目的 AI 剪辑演示与达到专业创作者标准的成片之间，也有类似差距。

前端设计方面，Astra 相比 Sol 进步很大：它更能遵循指令，做出的落地页也没那么尴尬。经过足够迭代，它可以产出好的设计。比较示例页面时，我看到了更好的动画和可用的起点，但仍有太多泛泛的文案和不必要的标签。

我展示的比较网站里，Sol 的页面能用，却充斥着通用的 Tailwind 风格布局和装饰性文字。Astra 的版本有所改进，也增加了不错的动画，但有些仍会出现尴尬的内容截断和重复措辞。启用设计 skill 有一点帮助，但仍离不开人的判断。

Fable 5.1 一次生成的设计更让我印象深刻：布局、动画和鲜明风格都不那么像明显的模板。不过，在已有设计上迭代时，两个模型仍常让我沮丧。前端工作我不会给它们任何一个超过五分；Fable 达到不错的起点所需的反复推动比 Astra 少得多。

与 Fable 5 的同类结果相比，Fable 5.1 的设计看起来更像定制作品。我在网上看到它，可能不会立刻猜出它是一次生成的。这让 Fable 成为更好的起点，但仍不能取代反复检查和打磨。

在全栈理解上，两个模型现在似乎都能把后端、前端、客户端和服务器联系起来，并在整个代码库中做出合理修改。按我的经验，上一代并非如此。Fable 似乎更快理解代码的影响，Astra 则更倾向于反复验证假设，持续推进直到找到答案。

面对同一个大型项目，Fable 可能先检查代码、识别顾虑，再据此设计方案；Astra 可能探索多种做法并逐一压力测试，最终得出相似结论。Fable 的直觉正确时速度更快；Astra 费力的做法可能发现 Fable 漏掉的深层问题，但也可能花更多时间和 token。

这种方法差异体现在 Astra 对各种边界和假设的反复验证上。Fable 更快的直觉让普通修改更顺手，Astra 不懈的验证则可能发现更深的问题。代价是时间和 token；我认为两者的整体全栈能力很接近。

这引出了一个主题：Fable 的表现比较稳定，Astra 则既有令人惊叹的高峰，也有让我怀疑订阅价值的时刻。它的坚持尤其适合大型重写。在用 Rust 移植 TypeScript 的实验中，Sol 在现有测试套件上达到约 30%，Astra 大约三天内超过 80%，随后停在约 82.6%。

这个 Rust 重写从 Sol 的约 30% 测试通过率提升到 Astra 的 80% 以上，随后停在 82.6%。它比我尝试过的其他模型走得远得多，但停在这个数字并不意味着移植已完成或可用于生产。

我给这个重写设定了目标和 40 个子代理，自己没有持续参与。比较中有一个重要偏差：OpenAI 早期测试期间没有向我收取用量费用，我用了 1300 亿 token。我从未获得过同等无限免费的 Fable 访问权限，因此对 Astra 的投入并没有在竞争模型上做同等测试。

我还发布过一些 Astra 生成的重写成果，包括 T3 Code 的 Swift 移动版本，也试过 Rust 的 GPUI 版本。但大型重写暴露出一个反复出现的问题。对于旧的 Ping 视频协作应用，我让模型规划现代化改造、创建分支并实现，大约一小时二十分钟后它交出了结果。

免费访问会影响这些结果的解读。早期测试时，我能给 Astra 非常大的预算，却没有同样免费的无限 Fable 额度。因此，这些极限重写实验不是公平对等的比较。

Ping 让主播把嘉宾带入通话，并作为图层嵌入 OBS。原来的界面由我们的联合创始人 Bryn 精心设计。重写替换了落地页和仪表盘，让信息难以辨认，加入时发生布局跳动，还把设备选择藏在额外步骤后面。这些细节对直播制作中的创作者很重要。

Ping 重写的问题不只是页面外观变了。仪表盘不再清楚传递信息，加入通话时布局发生跳动，预览所选摄像头也需要额外步骤。对把嘉宾嵌入直播布局的主播来说，这些行为可能和应用能否运行同样重要。

最糟糕的是它忽略了我的指令：逐项移植功能，尽可能复用界面代码。重写却丢弃了原有界面。这不能简单归咎于上下文压缩：我使用了百万 token 的上下文，并且在预览版之外也见过类似问题。我可以追加一段要求像素级一致的话，但不应该这样反复强调原本已说清的要求。

我不止一次见过 Astra 无视保留界面行为的要求；T3 Code 的 GPUI 版本就用了旧式侧边栏。明确的验收标准或许有帮助，但我不想每次已经要求复用界面时，还要追加一大段保留要求。

就代码可合并性而言，Fable 5.1 在我的工作流里胜出。从 PR 提交到合并，我统计到 Fable 平均需要约两次后续修改，Astra 约六次。这反映的是我的项目里审查机器人发现问题及后续修复的情况，是个人测量而非受控基准。Fable 提交的代码通常更接近可用状态，也更善于聚焦修改范围。

我不是说 Astra 的代码无法合并。我的主观图表把它放在 Fable 5 附近或略高的位置，比 Sol 进步很大；我过去主要把 Sol 用于探索或可用程序验证的工作。Fable 5.1 又提高了一档。Astra 和 Fable 5.1 的差距远小于我看到的 Sol 与 Fable 5 的差距。

我给出的粗略可合并性评分只是主观示意，不是正式测量。Sol 有足够反馈时也能最终做出可运行代码，但 Fable 5 更常产出我愿意合并到数十万用户所用项目里的修改。Astra 已经赶上早期 Fable 的水平，即使 5.1 仍然更好。

Astra 更彻底，解释也更易读，还能写出优雅、范围恰当的代码，但它仍常让范围蔓延。普通 bug 修复、重要界面修改或功能改进，我默认用 Fable。Astra 陷入循环时，我有时会把 PR 交给 Fable，让它丢掉不必要的部分，把有用的修改落地。

处理范围明确的修复时，Astra 的解释比旧版 Fable 5 更易读，它的彻底检查也能发现遗漏。不过，需要干净地合并 PR 时，我仍更喜欢 Fable 5.1。应该比较当前实际可用的版本，而不是只拿 Astra 对比旧模型。

收到误导性的审查意见后，Fable 也会让修改膨胀，但 Astra 更容易发生。即便要求尽量小改，审查反馈也可能让它偏离方向，使本应只有 50 行的修改变成上千行 PR。持续参与可以缓解，但让 Fable 保持聚焦通常更省力。

游戏开发方面，Astra 做出的 3D 画面更令人惊叹，Fable 则更擅长移动、镜头响应和动画曲线。我认为两者都无法独立做出一款好游戏，但结合使用可以帮助迭代。我预测会出现主要由 AI 制作的热门独立游戏；这是预测，并不能证明模型今天能独自做到。

漂亮的片段和手感好的游戏是两种不同的检验。我预计模型生成的组件会越来越有用，但我仍会组合并引导它们，而不会因为渲染场景好看就认为完整游戏也好。

按我的经验，理解意图仍是 Astra 的严重弱点。我合并了大约 150 个 AI 生成的 PR，其中出现两次回归，都来自 Astra。一次性能优化把 T3 Code 营销页面自动滚动的用户评价改成了手动滚动网格。我让它找到并回退修改，恢复动画。

这次评价区回归源于一次性能修改：连续滚动的跑马灯被替换成静态横向网格。我直到后来手动部署营销网站时才发现。我明确希望保留滚动效果，因此要求回退破坏它的修改。

尽管我反复使用“回退”一词，Astra 删除了一些变量和监听器，却没有恢复自动滚动。我还要求它启动 Tailscale 开发服务器，方便远程测试。它先启动了 T3 Code 应用，而不是营销网站；随后虽然开放了网站，主机配置却阻止了请求。

远程测试很重要，因为我当时在另一台电脑工作，想通过 Tailscale 检查修改。主 T3 Code 应用的服务器无法验证营销页面修复。模型最终启动正确的网站后，开发服务器配置又拒绝了那个主机。

它提交了针对特定机器的主机放行配置，后来停掉开发服务器，却让链接仍指向旧端口，最后甚至在没有解决问题的情况下合并了 PR。我给 Fable 基本相同的请求，但把 Tailscale 要求放在开头。大约五分钟后，它找到了出问题的 PR，恢复滚动并提供了可用链接。

Fable 找到了改变跑马灯的 PR，并解释后续增加的分页计时器对性能目标并无必要。它恢复了滚动行并给我一个可用链接。我确实需要引导它跳过前一个代理 PR 所造成的困惑，因此这并非完全受控的测试。

两次比较并不完全相同：Fable 对另一个代理合并又回退的 PR 产生疑虑，我需要纠正它；Tailscale 要求则是作为后续引导消息发给 Astra 的。即便考虑这些差异，Astra 的执行仍是我近期最糟糕的体验之一。严重失败并不常见，但可能令人难以理解；这次我认为它失败于基本代理工作，而不只是揣测我的意图。

我并非每次运行 Astra 都会遇到这种严重失败。问题在于，一旦发生，结果可能与要求的工作相差太远，反复反馈让人精疲力尽。决定需要多少监督时，这种波动值得考虑。

代理编排是 Astra 再次脱颖而出的地方。Fable 可以规划一系列子代理，Astra 则能协调一个代理群：代理并行工作、交换消息并发送更新，根代理据此分派更多工作。在 TypeScript 重写中，我见过它管理 40 个并行代理并维持上下文流转。我认为这可能打开更大规模的问题空间，但更宏大的期待仍是推测。

这种编排不只是同时启动几个代理。Astra 可以接收它们的发现、回复消息、让代理相互交流，并随着调查推进创建更多工作。我在 TypeScript 重写中见过这一过程，但运行大量代理也有显著成本。

Astra 也能在工作时处理新的引导。过去我补充一个遗漏要求，旧代理常常就放弃原有任务；Fable 5.1 在这方面更好，Astra 看起来又更进一步。配合合适的运行框架，它可以提出问题而不阻塞独立工作，随后在运行中吸收回答，或者完成后恢复并处理回答。

非阻塞提问依赖周围的应用或运行框架。模型可以询问用户更喜欢哪个选项，继续处理独立工作，之后再根据回答调整。我在 T3 Code 里见过这种功能；最初测试时没有相应支持，问题可能只出现在推理中，我却无法回答。

Astra 给自己和其他代理写提示词的能力略好，不过我仍更喜欢经验丰富的开发者写的提示词。两个模型都不够可靠，不能未经审查地连续生成 skill：让一个生成的 skill 再创建另一个，很快就会放大糟糕的指令。应该手写 skill，或者认真审查。

使用 skill 和编写 skill 是两回事。按我的经验，Fable 能可靠地选择并遵循有用的 skill；Astra 有时会在后续轮次忽略它。我怀疑原因部分来自 Codex 的运行框架和指令，而不全是模型本身。两者也都可能忽视边界或拒绝；Fable 在我看来更可靠，但都还没有达到我的期望。

我见过的一次失败涉及 PR 监控 skill：加载后，代理在随后的多次追问中忽略了它。我了解到 Codex 系统指令也规定 skill 何时跨轮次适用，因此很难把这种行为全归因于模型。在我的工作流里，Fable 在这方面需要的关注更少。

不能只凭单个 token 价格判断成本。录制时，我提到 Fable 5.1 的缓存读取价格从每百万 1 美元降到 0.25 美元，但缓存读取只占我账单的一小部分，缓存写入却超过 Fable 成本的 60%。OpenAI 当时也开始对缓存写入收费。这些比例取决于我的工作负载，价格和限额也可能变化。

缓存读取价格相差四倍听起来很大，但影响取决于它占账单的比例。我的 Fable 用量中，这个比例从约 3% 降到 1%，而缓存写入仍重要得多。其他用户的用量结构可能得出不同结果。

重要的是每项任务的总成本和 token 效率。我展示的 Artificial Analysis 指数中，Astra 每项任务为 3.26 美元，Fable 5.1 为 7.60 美元，尽管标称 token 价格相近。图中 Astra 完成任务大约使用 2.7 万 token，Fable 接近 8 万。这些数字描述的是该基准，并非适用于所有工作负载的普遍比例。

展示的 Artificial Analysis 比较中，Astra 报告的每任务成本为 3.26 美元，Opus 5 约 5.86 美元，Fable 5.1 为 7.60 美元。我的推论是，仅靠更便宜的缓存读取无法解释最终账单；模型完成工作所用的 token 数量也很重要。

OpenAI 的 flex API 选项可以把价格减半，代价是吞吐量不确定、响应延迟。对不需要立即得到结果的任务，这可能有吸引力。我希望 Codex 也有类似选项，因为我经常在晚上运行任务，可以接受等待。

订阅限额使比较更复杂。按我的估算，200 美元的 Claude Code 计划约有 8000 美元的推理额度，200 美元的 Codex 计划约有 1.2 万美元，但我的 Claude 每周额度只有一半能用于 Fable。这些估计和限制反映的是我当时的体验，不代表当前计划或其他用户的情况。

我的订阅估算还取决于计划允许使用哪个模型。我描述的有效 Fable 额度约为 Claude 估算总额度的一半，而 Astra 则可使用估算的完整 Codex 额度。这个计算来自我的个人用量和当时的限额，之后可能改变。

我还觉得 Claude 的五小时限额比较严格；我当时说较高档的 Codex 计划只有周限额，没有五小时上限。我使用多个账户，工作负载也比大多数开发者重得多；fast 和 ultra 模式可能特别快地耗尽额度。按我的用法，同价订阅下 Codex 加 Astra 感觉能完成约四倍工作，但这只是感受，不是经过测量的普遍规律。

我用大型 Rust 重写和众多子代理等异常繁重的任务来测试这些系统。每天使用几小时、代理更少的人可能体验不同。我特别提醒，fast 模式和高推理设置会很快消耗可用额度。

那段时间 Codex 也经常重置额度，有时在正常的每周重置之前就返还用量。我不会假定这种频率有保证。两个前沿模型仍然昂贵，预算紧张的人可能更适合等待类似能力以更低价格出现。我的多个计划每月合计消耗数万美元的推理用量。

我观察到 Codex 经常进行额外额度重置，包括可储存的重置，并引用另一位用户统计的 30 天内八次。这些重置让我的额度在那段时间更耐用，但我不会基于它们持续发生来做长期购买决定。

我心中的质量图像是：Fable 是一条稳定的高位线，Astra 的波动则大得多。Fable 通常按我预期行事，虽然偶尔令人失望。Astra 能做 Fable 做不到的事，转眼又可能在循环里浪费时间或破坏网站。如果意外失败会打乱工作、成本又不是首要问题，Fable 的稳定性也许值得多花钱。

Astra 的高峰可能非常惊艳，低谷则可能是昂贵的循环或损坏的网站。Fable 的质量也会变化，但按我的经验，波动范围更窄。Astra 给我的压力更大，即使 token 账单更低，这种使用成本也确实存在。

我喜欢两个都用。如果必须选一个，我倾向 Astra，因为计算机操作和其他非编程能力能在编程之外帮助我，尤其是在手受伤期间。对无法负担这个价格的人来说，等待或探索更便宜的选项是合理的；我预计类似能力会逐渐降价。

如果成本是主要顾虑，我建议看看是否符合开源项目计划的条件，或者等待更便宜的模型。我提到 GLM-5.3 Flash，因为我发现它在类似工作中不那么容易失控。这是个人体验，不保证适用于其他人的任务。

我的实际分工是：用 Fable 合并代码，用 Astra 操作电脑和处理其他任务。我估计 Fable 更常产出可合并的代码，表现最差时也没有那么糟；Astra 的能力更广，高峰也更惊人。我还观察到 Astra 在我的使用中更常因为安全原因拒绝请求。两者都提高了 T3 Code 的生产力，我认为它们是互补的。

我不认为代码能力的差距有失败时带给我的压力差距那么大。Fable 更可靠的代码和 Astra 更广泛的能力都很重要。我的建议是有条件的话两个都试试，让它们各自在适合的工作中发挥作用。