Claude Fable 5.2获评测榜最高65分

Claude Fable 5.2 在 Artificial Analysis 智能指数中拿到 65 分，但伴随它的还有高价格、长等待和大量输出。对程序员来说，值得读的不是一个榜首标题，而是这份评测揭示的选择题：更高的综合能力，是否值得放进每天反复调用的开发流程？

这份来自 Hacker News 的材料实际更像模型评测页摘录。下面的解读只依据所给内容；标题中的「迄今最高」缺少完整榜单佐证，而正文足以支持的结论是：它明显高于所列同类中位数，代价也相当突出。

65 分说明能力强，但不能直接等同于代码更好

材料称，Anthropic 的 Claude Fable 5.2 于 2026 年 11 月 9 日发布。本次评测对象是 Claude Fable 5.2 (Max, Default Fallback)，属于推理模型，使用扩展思考处理复杂问题。结论首先对应这个具体配置，不能自然推广到同名模型的其他运行方式。

它在 Artificial Analysis Intelligence Index 上得到 65 分，对照中位数为 40。但这不是百分制考试，不能理解为正确率 65%，也不能把两者相除，宣布开发效率提升了多少。

评测使用 Intelligence Index v5.0.1，包含 AA-Briefcase v1.1、AutomationBench-AA、Terminal-Bench 4.0、FrontierCode 2.0、AA-Omniscience v1.1、GDP.pdf、HLE-Diamond、CritPt v2 (Hard Subset) 和 Terminal-Bench-Science 0.1。它把知识工作、编程、终端操作、科学任务等多种能力合成一个指标。

这种综合成绩适合筛选候选模型，却不能直接回答「修复我的 Node 服务故障更可靠吗」。原文列出了不少能力维度，却没有给出对应分项成绩，无法判断 65 分究竟主要赢在哪里。

其中，AA-Omniscience v1.1 的计分方式尤其值得理解：答对加分，幻觉扣分，拒答不扣分；Net Score 范围是 -100 到 100，0 表示正确与错误答案一样多。它关注的是知识可靠性，而非模型是否总能给出一段回答。不过，材料没有提供 Fable 5.2 在这一项上的具体得分。

真正影响账单的是单价和生成量一起上涨

原文给出的 Anthropic API 价格是：每 1M 输入 tokens 收费 $8.00，每 1M 输出 tokens 收费 $40.00；所列同类中位数分别为 $2.00 和 $10.00。输入与输出单价都是中位数的 4 倍。

与此同时，模型跑完整套智能指数评测生成了 275M 输出 tokens，对照中位数为 72.8M，约为后者的 3.78 倍。

这两个因素会叠加。即使输入相同，单价更高、生成量更多，也会推高成本。但不能把两个倍数直接相乘当作实际账单差距，因为评测成本还涉及输入、缓存命中、缓存写入、推理和答案 tokens，以及不同任务的权重。

原文给出的加权平均成本是每个评测任务 $26.54。它反映的是这套基准的任务组合，不能拿来估算「改一个 React 组件要花多少钱」。

页面还给出一个混合价格：按缓存命中、输入、输出为 7:2:1 的比例，每 1M tokens 为 $5.74。这是带使用结构假设的数字。若你的 Agent 经常生成长答案，或提示词缺少可复用前缀，实际比例就可能差很多。材料也明确说明，缓存写入与存储另行计费，不同供应商可能不同。

判断模型贵不贵，要看完成一个合格任务的总成本。

这里的「合格」不能省略。便宜模型若需要多轮返工，优势可能缩小；昂贵模型若没有提高任务成功率，额外开销也难以成立。原文没有提供这种业务对照，不能替它补上结论。

等待多久，比每秒输出多少更接近使用体验

材料给出的每个智能指数任务耗时是 46.4 分钟，同类中位数为 12.7 分钟，约为后者的 3.65 倍。但页面对这个指标有明确算法：用每个任务的输出 tokens 除以输出速度，再按各基准权重汇总。

因此，它是评测口径下的任务时间指标，不能解释成每次 API 调用都要等 46.4 分钟，也不宜当作完整 Agent 工作流的墙钟耗时。

更贴近日常交互的是首个答案 token 时间。Fable 5.2 为 215.95s，同类中位数为 11.78s，约相差 18.3 倍。对推理模型来说，这个时间包含回答前的思考；如果接口不支持流式输出，则对应收到完整结果的时间。

对于边写边问的开发流程，几分钟后才出现答案，会显著改变使用节奏。对于允许后台执行的复杂任务，等待可能更容易接受，但仍要看结果是否减少返工。

页面的速度与延迟数据采用过去 5 天的运行平均值，常规端点每 6 小时测一次，已弃用模型端点每 18 小时测一次。端到端输出速度还包含推理 tokens，不能直接等同于用户可见文字的生成速度。

能力规格方面，它支持文本、图片输入和文本输出，上下文窗口为 1M tokens。这个窗口是输入与输出合计的上限，页面提醒输出通常另有更低限制，却没有给出该模型的具体输出上限。

对于检索增强生成（RAG）或仓库分析，长窗口提供了装入更多资料的空间。但原文没有给出长上下文准确率，也没有证明把整个仓库塞进去，比检索相关文件更有效。能装多少，与能否稳定找对证据，是两件需要分别验证的事。

我的判断

这份材料最有价值的地方，是把分数、生成量、费用和等待时间放在了一起。65 分值得关注，但模型选型至少还要回答：任务能否完成、需要多少人工修正、多久完成、最终花多少钱。

比较口径则有几个问号。页面说这一类别有 237 个模型；推理模型会同时与推理和非推理模型比较，专有模型则按输入与输出 3:1 的混合价格划分同价格档位。但摘录中同时出现每 1M tokens 为 $0.15–$1 的区间，与这里的 $8.00 输入、$40.00 输出价格明显不协调。材料没有说明这是哪个区间，也没有列出计算中位数的模型名单，所以「同类」不能被理解成条件完全一致。

另外，275M 是整套评测的总输出量，不能据此认定用户每次都会收到长篇答案；是否主要消耗在内部推理，摘录没有拆分。标题中的「最高」同样缺少完整排名、差距和不确定性信息。

我的取舍是：把它视为复杂任务的候选模型，先做小规模对照，再决定是否扩大使用。相比直接统一切换，按任务难度分配模型也值得测试。但原文没有证明哪种策略更划算，这仍是待验证的工程选择。

能拿来做什么

• 挑选你已有验收标准的前端或 Node 任务做对照，例如真实缺陷修复和跨文件修改，同时记录测试结果、人工修改量、实际费用与完成时间，不只比较回答是否流畅。
• 接入 AI 编程流程前，分别记录首个答案出现时间与任务完成时间。如果等待接近材料中的 215.95s，应按后台任务设计交互，提供状态反馈和取消入口。
• 评估 1M tokens 长窗口时，用同一任务比较「提供大量上下文」与「检索后提供相关文件」，检查遗漏、错误引用和费用。不要只验证请求能否成功提交。
• 核算 API 成本时使用自己的缓存命中、输入和输出比例，并固定模型配置及供应商。原文称有 6 家 API 供应商，但没有列出名单，也不能据此假定价格和延迟相同。