Claude Opus 5 vs Claude Fable 5：7 项真实 API 测试与生产路由建议

Claude Opus 5 vs Claude Fable 5：7 项真实 API 测试与生产路由建议#

Claude Opus 5 和 Claude Fable 5 应该怎么选？如果只看一次成功回答，两款模型都能写出很漂亮的数学推导。真正影响生产体验的，往往是另外三件事：任务能不能稳定交付、延迟是否适合交互、失败后能不能自动恢复。

我们在 2026 年 7 月 25 日通过同一个 OpenAI-compatible API，使用相同提示词和参数，对两款模型做了 7 类任务测试。结果没有落入“更大的模型一定更好”这种简单叙事：

• claude-fable-5 在共同成功任务上更快、更简洁；
• claude-opus-5 最终覆盖了全部 7 类任务；
• Fable 5 在普通代码审查和事故 JSON 提示词上连续触发 content_filter；
• Opus 5 的物理题前两次虽然返回 HTTP 200，却只回复了一句问候语，第 3 次才正常完成。

这意味着生产选型不应该只有一个模型 ID。更稳妥的做法是：先按任务类型选择主模型，再用内容验收、重试和模型回退把异常包起来。

用同一 API 测试 Opus 5 与 Fable 5

快速结论#

如果你的输入类型不可预测，或者必须尽量避免普通业务提示词被过滤，优先考虑 Opus 5。如果任务结构固定、已经做过回归测试，并且交互速度和输出长度更重要，Fable 5 更适合作为第一跳。

我们怎样测试#

测试前先调用模型列表接口，确认两个精确模型 ID 都可见：

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
claude-fable-5

所有正式请求走同一个 endpoint：

POST https://cn.crazyrouter.com/v1/chat/completions

公共条件如下：

相同 system prompt
相同 user prompt
temperature = 1
每道题使用相同 max_tokens
stream = true
不启用工具和联网

统一 system prompt 只要求准确回答并遵守输出格式，没有加入偏向任何模型的角色设定：

Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.

我们记录的不只是最终文字，还包括：

• HTTP 状态与 finish_reason；
• response ID 与 returned model；
• 首个可见 token 时间和总延迟；
• completion tokens、reasoning tokens；
• 可见答案是否满足任务验收；
• 异常请求能否通过相同参数重试恢复。

这是一组 Crazyrouter 网关端到端测试，不是指定单一上游渠道的实验。因此结果同时反映模型行为、上游过滤、网关路由和当时渠道状态。它适合回答“用户通过这个 API 实际会遇到什么”，不适合被包装成 Claude 家族的纯离线能力排行榜。

如果你想了解为什么模型测试必须记录 finish_reason 和输出预算，可以继续看Claude Fable 5 vs GPT-5.5 的 max_tokens 复测。

7 项结果总表#

主测试的一次交付率：

Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%

加入重试后：

Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7

这里的“交付”不是请求成功，而是业务能拿到符合题目要求的可见答案。HTTP 200、模型名和 token usage 都存在，但正文为空、被过滤或只返回问候语，仍然算任务失败。

数学、约束与统计：两款模型都可靠#

数学题使用三状态马尔可夫链，要求计算从状态 1 首次到达状态 3 的等待时间：

E1[τ]
E1[τ²]
Var1(τ)

两款模型都给出：

E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18

它们也都写出了暂态矩阵 Q 和一阶、二阶矩方程。这一题没有出现“最终数字正确但推导不一致”的情况。

约束搜索要求把 A、B、C、D、E 五场演讲排入五个时段，同时满足立即相邻、先后、间隔和不相邻等条件。两者都得到唯一顺序：

A, C, E, B, D

统计纠错题故意给出一个错误结论：“均值为 10、方差为 4，所以 P(X≥14)=0.5。”两款模型都指出两阶矩不足以唯一确定尾概率，并用单侧 Chebyshev/Cantelli 不等式得到：

P(X >= 14) <= 0.2

这三类任务说明 Fable 5 的速度优势并不是靠牺牲基础推理正确性换来的。在明确、短小、可验收的数学与逻辑任务上，它完全可以作为更轻的第一跳。

此前的Claude Fable 5 vs Claude Sonnet 5 API 测试和GLM-5.2 vs Fable 5 输出预算测试也表明：判断一款模型是否适合生产，必须把正确性、输出预算与交付形态放在一起看。

物理题：Fable 首轮完成，Opus 第三次恢复#

物理题要求处理一个带接地阻尼和耦合阻尼的二自由度振子，计算两个无阻尼固有频率，以及 ω=8 rad/s 时两个质量块的复频响。

参考值为：

ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
|X2| = 0.07174 m, phase = -13.90°

Fable 5 首轮就给出了全部正确结果。Opus 5 的前两次调用则出现了一个更值得生产团队注意的异常：接口返回 HTTP 200 和 finish_reason=stop，但正文只有：

Hi! How can I help you today?

这两次响应的 prompt tokens 都只有 10，与真实输入明显不匹配。相同请求第 3 次执行时，Opus 5 在 34.901 秒后完整返回，六个数值全部通过检查。

因此，这类异常不应该被归类为“物理题算错”，而应归类为“请求上下文没有被正常处理”。最简单的防线不是让人工看日志，而是在调用端设置任务级验收：答案必须包含 ω1、ω2、X1、X2；缺失任一字段就重试。

代码与严格 JSON：Fable 的过滤是本轮最大差异#

代码题让模型审查一个 Python DFS 环检测器。bug 很普通：节点完成 DFS 后没有从 visiting 集合删除，导致已经完成的节点仍被误认为递归栈中的节点，从而在 DAG 上误报环。

Opus 5 正确指出最小修复：

visiting.discard(node)
visited.add(node)
return False

Fable 5 没有返回代码分析，而是 finish_reason=content_filter、正文为空。为了排除 system prompt 偏差和偶发路由，我们做了三轮：原始测试、清洁 system prompt 复测、独立单题重试，结果都是 content_filter。

严格 JSON 题同样没有危险内容。输入只包含 15 分钟内的请求总数、失败数、渠道归因、重试恢复数和处置动作，要求输出一个 JSON 对象。Opus 5 返回的 JSON 可以直接解析；Fable 5 同样连续 3 次被过滤。

这两类失败说明：安全过滤本身也是模型 API 的生产能力之一。 如果一个模型在正常代码审查或事故复盘文本上稳定误过滤，即使它在数学题上更快，也不能直接接管所有业务流量。

两次独立重试的 response ID：

代码审查：gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
事故 JSON：gen-1784915390-buOWZQSnqjgHeJ6nUogF

延迟与输出长度#

为了避免把失败请求的短耗时算成“速度优势”，这里只比较两款模型都成功的四项共同任务：数学、约束搜索、统计纠错、实验设计。

在这个小样本中，Fable 5 的 P50 总延迟低约 24%，首个可见 token 低约 17%，答案短约 43%。对聊天、批量摘要和高频结构化任务来说，这些差异会直接影响用户等待时间与下游处理量。

但不要把 4 道题的中位数写成 SLA。上游负载、缓存、路由和限流都会改变延迟。正式上线前，应当用自己的业务提示词重复 20–50 次，再统计 P50、P95、P99 和每个通过结果的真实成本。

Fable 5 的主测试响应提供了 cost 字段，7 次合计约 $0.24596。Opus 5 的 usage 没有提供同口径 cost，因此本文不做美元价格胜负判断。字段缺失不代表免费，也不应该用未经核实的价格补齐。

推荐的生产路由策略#

单模型调用最容易写，但它把模型的所有偶发行为都暴露给最终用户。对于本轮两个模型，更合理的分工如下：

Fable 5 作为第一跳#

适合：

• 已通过回归测试的数学、约束推理与短摘要；
• 对首 token 和整体延迟敏感的交互；
• 希望控制答案长度、减少后处理负担的任务。

前提是任务族已经做过过滤测试，且调用端会检查 content_filter、空正文和缺失字段。

Opus 5 作为高覆盖回退#

适合：

• 输入类型不可预测；
• 代码审查、严格 JSON、复杂物理等需要更宽任务覆盖的场景；
• Fable 5 被过滤后，需要自动恢复用户请求的场景。

Opus 5 同样不能免检。本轮的问候语异常证明：HTTP 200 与 stop 仍可能没有业务答案。

OpenAI-compatible Python 示例#

下面的示例先调用 Fable 5，遇到过滤、空正文或验收失败时回退 Opus 5；如果 Opus 仍然只返回问候语，则再重试一次。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)


def valid_answer(text: str, required_terms: tuple[str, ...]) -> bool:
    normalized = (text or "").strip()
    if not normalized:
        return False
    if normalized.lower().startswith("hi! how can i help"):
        return False
    return all(term in normalized for term in required_terms)


def call_model(model: str, prompt: str) -> tuple[str, str | None]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=1,
        max_tokens=3000,
    )
    choice = response.choices[0]
    return choice.message.content or "", choice.finish_reason


def routed_completion(prompt: str, required_terms: tuple[str, ...] = ()) -> str:
    for model, attempts in (("claude-fable-5", 1), ("claude-opus-5", 2)):
        for _ in range(attempts):
            text, finish_reason = call_model(model, prompt)
            if finish_reason == "content_filter":
                break
            if valid_answer(text, required_terms):
                return text
    raise RuntimeError("No model produced a valid business answer")


answer = routed_completion(
    "Return a JSON incident summary with keys total, failed, recovered.",
    required_terms=('"total"', '"failed"', '"recovered"'),
)
print(answer)

生产实现还应记录 model、response ID、finish_reason、总延迟和验收失败原因。这样你才能区分模型算错、输出截断、内容过滤和路由丢失输入，而不是把它们都归入一个模糊的“模型失败”。

如果你正在规划多模型基础设施，可以参考AI API Gateway、聚合器和直连模型 API 的区别，以及Kimi K3 vs Opus 4.8 的七维测试。

最终建议#

本轮最有价值的结论不是谁拿到了更高分，而是两款模型的失败形态不同：

• Fable 5 的优势是共同任务更快、更短；风险是部分普通业务提示词会稳定触发过滤。
• Opus 5 的优势是重试后覆盖全部任务；风险是偶发返回与真实输入无关的问候语。

因此，建议把 Fable 5 放在已经验证的高频任务前面，把 Opus 5 作为更广覆盖的回退，并对两条路径都做内容级验收。这样才能把模型对比结果转化成真实的可靠性，而不是只停留在一张排行榜上。

创建 API Key，复现这组双模型路由

FAQ#

Claude Opus 5 一定比 Claude Fable 5 更强吗？#

不能从这组小样本得出“所有任务都更强”。两者在数学、约束、统计纠错和实验设计上都通过；Fable 5 更快、更短，Opus 5 的任务覆盖更完整。选择应基于具体任务成功率，而不是模型名字。

Claude Fable 5 适合生产环境吗？#

适合经过回归测试的任务。本轮它在多类推理任务上正确且较快，但代码审查和事故 JSON 连续触发过滤。上线前应使用真实提示词测过滤率，并配置 Opus 5 或其他模型回退。

为什么 HTTP 200 仍然算失败？#

HTTP 200 只说明接口完成了响应。正文为空、finish_reason=content_filter、输出被截断，或者只回复问候语，都无法完成业务任务。生产指标应统计“验收通过率”，而不是只统计 HTTP 成功率。

returned model 为什么是 anthropic/claude-fable-5？#

请求使用 claude-fable-5，响应中的 returned model 稳定为带 provider 前缀的 anthropic/claude-fable-5。这可以视为规范化别名；仅凭前缀变化不足以证明发生了模型替换。

可以直接比较两款模型的美元成本吗？#

本轮不可以。Fable 5 的响应提供了 cost 字段，Opus 5 没有提供同一口径字段。严谨的成本比较应从统一计费日志取数，并以“每个验收通过结果的成本”为指标。

应该重复多少次再决定上线？#

建议每个核心任务族至少重复 20–50 次，并覆盖正常输入、边界输入、长输入和容易触发过滤的输入。至少记录任务成功率、过滤率、空正文率、截断率、P50/P95/P99 延迟和成本。

怎样开始测试？#

使用 https://cn.crazyrouter.com/v1 作为 OpenAI-compatible base URL，分别调用 claude-opus-5 和 claude-fable-5。固定提示词和参数，保存原始响应，再用本地断言或结构校验判定任务是否真正完成。

开始你的 Claude 双模型测试