Claude Opus 5 vs Claude Fable 5：7 项真实 API 测试，速度、过滤与生产路由怎么选？

Claude Opus 5 和 Claude Fable 5 应该怎么选？

如果只看一次成功回答，两款模型都能给出不错的数学推导。真正影响生产体验的，往往是另外三个问题：

1. 同一类任务能不能稳定交付；
2. 延迟是否适合在线交互；
3. 发生过滤、空正文或异常回答后，系统能不能自动恢复。

2026 年 7 月 25 日，我通过同一个 OpenAI-compatible API，使用相同提示词和参数，对 claude-opus-5 与 claude-fable-5 做了 7 类任务测试。

先说结论：

• claude-fable-5 在双方都成功的任务上更快，输出也更短；
• claude-opus-5 主测试完成 6/7，重试后完成 7/7；
• Fable 5 在普通 Python 代码审查和事故 JSON 提示词上连续触发 content_filter；
• Opus 5 的物理题前两次虽然返回 HTTP 200，却只回复了问候语，第 3 次才恢复正常。

所以，这次测试最重要的结论不是“谁绝对更强”，而是：两款模型的失败形态不同，生产系统不能只配置一个模型 ID，也不能只检查 HTTP 状态码。

一、测试环境

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

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

claude-opus-5
claude-fable-5

正式请求统一使用：

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 200 自动算作成功。每个请求还会检查：

• finish_reason；
• 可见正文是否为空；
• 是否包含题目要求的关键字段；
• 数学和物理数值是否命中参考值；
• JSON 是否可以直接解析；
• 代码分析是否指出真实 bug；
• response ID、returned model、首 token 时间和总延迟。

需要说明的是：这是通过 API 网关完成的端到端测试，没有固定单一上游渠道。因此结果同时反映模型、上游过滤、路由和当时渠道状态，不能当成纯离线模型排行榜。

二、7 项任务结果

测试维度	Claude Opus 5	Claude Fable 5	生产影响
精确数学：马尔可夫链	通过	通过	两者均得到正确的一阶矩、二阶矩与方差
数值物理：耦合振子	前两次仅回复问候语，第 3 次通过	首轮通过	Opus 需要内容验收和重试
约束搜索	通过	通过	两者均找到唯一解
统计纠错	通过	通过	两者均拒绝错误前提并给出正确上界
Python 代码审查	通过	连续 3 次 content_filter	Fable 当前不适合未经回归的代码审查流量
严格 JSON 事故摘要	通过	连续 3 次 content_filter	Fable 当前不适合这类事故文本
实验设计	通过	通过	两者都能识别未配对样本和难度混杂

主测试一次交付率：

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，也仍然判定失败：

• 正文为空；
• finish_reason=content_filter；
• 输出被截断；
• 只返回通用问候语；
• 缺少任务要求的字段；
• 代码或计算结果没有通过独立检查。

三、数学与约束推理：两款模型都通过

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

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

两款模型都给出了正确结果：

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

两者也都写出了暂态矩阵 Q，并用一阶矩和二阶矩方程完成验证。这一题没有出现“最终数字正确，但中间推导自相矛盾”的情况。

约束搜索题要求把 A、B、C、D、E 五场演讲放入五个时段，同时满足：

C 紧跟 A
B 在 D 之前
E 不能在第一或最后
D 恰好在 E 后两个时段
B 不能与 A 相邻

两款模型都找到唯一顺序：

A, C, E, B, D

统计纠错题故意给出一个错误前提：

E[X] = 10
Var(X) = 4
所以 P(X >= 14) = 0.5

Opus 5 和 Fable 5 都指出，仅凭均值和方差无法唯一确定尾概率，并使用单侧 Chebyshev/Cantelli 不等式得到：

P(X >= 14) <= 0.2

这三类题说明，在结构明确、输出较短、验收标准清晰的数学与逻辑任务上，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
content = "Hi! How can I help you today?"
prompt_tokens = 10

真实题目显然不止 10 个 prompt tokens，因此这更像某次请求路径没有正常携带用户输入，而不是模型计算错误。

使用完全相同的参数执行第 3 次请求后，Opus 5 在 34.901 秒内完整返回，所有数值均通过检查。

这类问题不能靠检查 status_code == 200 发现。调用端至少应该检查：

required_terms = ("ω1", "ω2", "X1", "X2")
valid = all(term in answer for term in required_terms)

缺少任一字段就重试或切换模型。

五、代码审查与严格 JSON：Fable 连续触发过滤

代码题要求审查下面的 DFS 环检测逻辑：

def has_cycle(graph):
    visiting, visited = set(), set()

    def dfs(node):
        if node in visiting:
            return True
        if node in visited:
            return False

        visiting.add(node)
        for nxt in graph.get(node, []):
            if dfs(nxt):
                return True

        visited.add(node)
        return False

    return any(dfs(node) for node in graph)

bug 是节点完成 DFS 后没有从 visiting 删除。visiting 本应只表示当前递归栈，却逐渐变成“所有访问过的节点”，最终会把某些 DAG 误判为有环。

Opus 5 给出的最小修复正确：

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

Fable 5 没有返回分析，而是：

HTTP 200
finish_reason = content_filter
content = ""

为了排除偶发问题，我分别执行了原始测试、清洁 system prompt 复测和独立单题重试，三次结果都是 content_filter。

严格 JSON 题也出现同样情况。输入只是 15 分钟内的请求总数、失败数、渠道归因、重试恢复数和处置动作，要求模型返回一个 JSON 对象。

Opus 5 返回的 JSON 可以直接解析；Fable 5 连续三次被过滤。

两次独立复测 response ID：

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

这两个提示词没有要求执行攻击、绕过权限或生成危险代码。因此，本轮更合理的判断是上游过滤误报，而不是合理拒答。

对 API 使用者来说，安全过滤也是模型的生产能力之一。如果正常代码审查或事故复盘文本会稳定触发过滤，就不能让该模型直接接管所有业务流量。

六、延迟和输出长度

为了避免把失败请求的短耗时误算成速度优势，这里只比较两款模型都成功的四项任务：

• 马尔可夫链；
• 约束搜索；
• 统计纠错；
• 实验设计。

单次延迟：

任务	Opus 5	Fable 5
精确数学	16.588 s	20.307 s
约束搜索	10.617 s	8.357 s
统计纠错	10.841 s	7.937 s
实验设计	8.311 s	7.143 s

汇总：

指标	Opus 5	Fable 5
P50 总延迟	10.729 s	8.147 s
P50 首个可见 token	8.376 s	6.974 s
平均可见 completion tokens	797.5	452.3

在这个小样本里：

• Fable 5 的 P50 总延迟低约 24%；
• 首个可见 token 时间低约 17%；
• 可见输出平均短约 43%。

这对在线聊天、批量摘要和高频结构化任务有实际意义。但四道题的中位数不能当成 SLA。正式上线前，应该用真实业务提示词重复 20～50 次，再统计任务成功率、过滤率、P50、P95、P99 和成本。

Fable 5 的响应提供了 cost 字段，本轮 7 次主请求合计约 0.24596 美元。Opus 5 的响应没有提供同口径 cost 字段，因此本文不做美元价格排名。字段缺失不代表免费，也不应该用未经核实的价格补齐。

七、生产路由建议

结合本轮结果，更合理的分工是：

Fable 5 作为已验证任务的第一跳

适合：

• 已做过提示词回归的数学与约束任务；
• 对首 token 和总延迟敏感的在线交互；
• 希望减少输出长度和后处理开销的任务。

但调用端必须检查：

finish_reason == content_filter
正文为空
必需字段缺失
JSON 解析失败

Opus 5 作为高覆盖回退

适合：

• 输入类型不可预测；
• 代码审查、严格 JSON 和复杂物理任务；
• Fable 5 触发过滤后，需要自动恢复的请求。

Opus 5 同样不能免检。本轮的通用问候语异常说明，HTTP 200 和 finish_reason=stop 仍然可能没有业务答案。

OpenAI-compatible 路由代码

下面的示例先调用 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:
    text = (text or "").strip()
    if not text:
        return False
    if text.lower().startswith("hi! how can i help"):
        return False
    return all(term in text for term in required_terms)


def call_model(model: str, prompt: str):
    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=()):
    routes = (
        ("claude-fable-5", 1),
        ("claude-opus-5", 2),
    )

    for model, attempts in routes:
        for _ in range(attempts):
            text, finish_reason = call_model(model, prompt)

            if finish_reason == "content_filter":
                break

            if valid_answer(text, required_terms):
                return {
                    "model": model,
                    "content": text,
                }

    raise RuntimeError("No model produced a valid business answer")


result = routed_completion(
    "Return a JSON incident summary with total, failed and recovered.",
    required_terms=('"total"', '"failed"', '"recovered"'),
)

print(result)

实际项目还应该记录：

requested model
returned model
response ID
finish_reason
首 token 时间
总延迟
验收失败原因
是否发生回退

这样才能区分模型算错、输出截断、内容过滤和路由异常，而不是把它们都归入一个模糊的“模型失败”。

八、最终结论

本轮测试中，两款模型的特点很清晰：

Claude Fable 5

优点：

• 共同成功任务的中位延迟更低；
• 输出更短；
• 数学、约束、统计纠错和实验设计均通过。

风险：

• 普通代码审查和事故 JSON 连续触发过滤；
• 不适合在没有提示词回归和模型回退的情况下接管全部流量。

Claude Opus 5

优点：

• 主测试覆盖更广；
• 代码审查和严格 JSON 成功；
• 物理题重试后完整通过。

风险：

• 两次物理请求只返回通用问候语；
• 输出通常更长；
• 仍然需要关键字段验收和自动重试。

最终建议不是二选一，而是：

已验证的高频任务：Fable 5 优先
content_filter / 空正文 / 验收失败：回退 Opus 5
Opus 返回问候语或字段缺失：重试一次
仍失败：切换渠道并报警

只有把模型选择、内容验收、重试和回退放在一起，模型对比结果才会真正转化成生产可靠性。

完整测试原文与更多 response ID：

https://crazyrouter.com/zh/blog/claude-opus-5-vs-claude-fable-5-api-benchmark-2026?utm_source=csdn&utm_medium=article&utm_campaign=claude_opus5_fable5_benchmark_20260725&utm_content=csdn_claude_opus5_fable5__source