1. 先给结论
需要处理超长材料、持续几十步工具调用、复杂代码库规划或高风险最终复核时，优先测试 Fable 5.1。日常代码生成、重构、测试补全和中等长度 Agent 流程，Opus 5 通常更适合作为默认候选。没有真实任务数据时，不应把任何一款写成“绝对更强”。
2. Fable 5.1 与 Opus 5 规格对比
| 维度 | Fable 5.1 | Opus 5 |
|---|---|---|
| 主要定位 | 最高复杂度推理、长程 Agent | 高质量生产任务与复杂编码 |
| 上下文 | 官方 1M | 以官方当前型号页为准 |
| 模型 ID | claude-fable-5-1 | claude-opus-5 |
| 迁移风险 | 需检查 tool/thinking 严格校验 | 现有项目通常已有行为基线 |
表格故意没有写本站统一价格：渠道价格和可用权限可能变化，采购和预算应以控制台当日目录为准。
3. 长程 Agent 应该选谁
Agent 任务的难点不是单轮回答，而是状态保持、工具选择、错误恢复和结束条件。Fable 5.1 的 1M 窗口与消息级 effort 适合把大量工具记录、计划和中间证据保留在同一工作流中；但窗口越大，输入成本和旧信息干扰也越明显。Opus 5 更适合上下文经过检索和压缩、每一步都可校验的工作流。
不要把整个数据库、完整仓库和所有日志一次性塞入模型。更稳妥的方法是检索候选材料、保留任务状态摘要，再让模型读取真正相关的文件。
4. 编程和 Claude Code 怎么选
日常 Claude Code 工作包括搜索文件、生成补丁、运行测试和根据失败继续修改。Opus 5 可先作为稳定基线；Fable 5.1 用于跨模块架构、复杂故障、长时间自主执行或最终代码审查。评测时至少准备三类任务：明确的小修复、跨文件功能、带失败测试的复杂缺陷。
记录一次通过率、修改文件数、是否引入无关改动、工具调用次数和最终 Token。模型单价高但一次完成，可能比多轮返工便宜；反之，旗舰模型在简单任务上也可能只是过度配置。
5. 不要只比较每百万 Token 单价
单位任务成本 = 输入成本 + 输出成本 + 缓存成本 + 重试成本 + 人工复核时间。长上下文任务还要观察每一轮是否重复发送固定材料。Fable 5.1 支持缓存与更细的 effort 控制，只有正确切分静态上下文和动态消息，才可能转化为真实节省。
预算敏感项目可以采用“Opus 5 执行、Fable 5.1 规划与复核”的分层策略；但回退逻辑必须由确定性代码控制，不能让模型自己决定是否无限升级。
6. 一套可复现的选型测试
- 选取 10 至 20 个真实任务，隐藏历史答案。
- 固定系统提示、工具、最大输出和超时。
- 分别运行两款模型，保留 request ID、usage 和错误码。
- 由测试或人工验收判断是否完成，不用“看起来不错”代替结果。
- 比较成功任务的总成本，而不是只比较平均 Token。
模型信息见 Claude Fable 5.1 API、Claude Opus 5；升级旧项目时先看 Fable 5.1 迁移检查表。
7. 官方规格与价格放在同一张表里
| 维度 | Claude Fable 5.1 | Claude Opus 5 | 对决策的影响 |
|---|---|---|---|
| 官方定位 | 高难度推理、长程 Agent | 多数复杂生产工作负载的起点 | 先用 Opus 建立基线，确有不足再升级 |
| 上下文 / 最大输出 | 1M / 128K | 1M / 128K | 窗口相同不代表有效上下文相同 |
| 标准输入 / 输出 | $10 / $50 | $5 / $25 | Fable 每 Token 为 Opus 的 2 倍 |
| 缓存读取 | $0.25/MTok | 按官方当前标准缓存倍率 | 大量重复静态上下文时需单独核算 |
| 默认 effort | high，adaptive thinking 始终开启 | high，可按任务调节 | 简单任务不要默认升到最高档 |
| 相对延迟 | 官方标记 Slower | 官方标记 Moderate | 交互式编码要关注等待时间 |
8. 两个可以复算的成本案例
案例 A：一次代码审查
假设输入 100K tokens、输出 10K tokens，不使用缓存。Fable 5.1 的官方标准 Token 成本约为 $1.50；Opus 5 约为 $0.75。Fable 必须把失败率、重试次数或人工复核时间至少降低一半，才可能抵消这部分 Token 价差。
案例 B：重复读取 80K 固定规范
若固定规范已经进入 Fable 5.1 缓存，后续请求包含 80K 缓存读取、20K 新输入和 10K 输出，Token 成本约为 $0.72，不含首次写入。这个案例说明缓存能缩小长上下文成本，但不能证明 Fable 自动比 Opus 便宜；仍需按两款模型各自缓存价格和命中率计算。
成本公式应写进评测表：单位成功任务成本 = Token + 工具调用 + 重试 + 人工复核。失败任务也必须计费，不能只统计成功请求。
9. 四类任务的推荐起点
| 任务 | 先测试 | 升级到 Fable 5.1 的条件 |
|---|---|---|
| 单文件修复、测试补全 | Opus 5 | 高 effort 仍反复遗漏关键约束 |
| 跨模块架构改造 | Opus 5 high/xhigh | 需要更长计划保持或多轮工具闭环 |
| 长程自主 Agent | 两者并测 | Fable 的成功率提升覆盖价差和延迟 |
| 最终高风险复核 | Fable 5.1 候选 | 错误代价远高于 Token 成本 |
这不是永久排名。每次模型更新、提示词变化或工具集变化都应重新运行固定样本。
10. 一张真正能做决定的评测表
每个样本至少记录：任务 ID、模型、effort、输入/输出/缓存 Token、工具调用次数、总耗时、测试是否通过、是否产生无关改动、人工修复分钟数和失败原因。将“通过但需人工大改”与“一次完成”分开，避免主观印象替代业务验收。
建议 10 个小任务、5 个跨文件任务和 5 个长程 Agent 任务。样本不足时只写“适合测试”，不要发布“更强”“更稳定”等结论。
官方来源：Claude Fable 5.1 overview、Claude models overview、Claude pricing，核对日期 2026-09-19。本站未进行同任务公开基准测试，因此不提供未经验证的胜负排名。