别急着给 Claude Fable 5 排名我更建议先查 returned model 字段Claude Fable 5 重新开放之后很多讨论都集中在两个问题上Fable 5 是不是比 Opus 4.8 更强 Fable 5 和 Sonnet 5 到底怎么选但如果你是 API 用户我建议先别急着给模型排座次。更值得先确认的是另一个细节你请求的是claude-fable-5最终 API 响应里的model字段是否真的还是claude-fable-5这次我用 Crazyrouter 的 OpenAI-compatible API 做了一组小样本验证。结果里最有价值的不是某个回答写得多好而是requested_model和returned_model出现了不一致。测试时间2026-07-03Base URLhttps://cn.crazyrouter.com/v1对比模型claude-fable-5 claude-opus-4-8 claude-sonnet-5先给出核心结论claude-fable-5能调用本轮 5 次请求全部 HTTP 200。claude-fable-5本轮 5 次 content 都非空。但请求claude-fable-5的 5 次里只有 2 次返回模型仍是claude-fable-5。另外 3 次响应字段里的model是claude-opus-4-8。本轮没有足够证据说明 Fable 5 稳定强于 Opus 4.8。claude-sonnet-5本轮有一次 HTTP 200 但 content 为空。所以这篇不讨论“Fable 5 是否封神”。我更想把它当成一次 API 路由字段审计新模型上线或解禁后开发者应该记录哪些字段才不容易测偏。1. 为什么 returned model 比正文更重要很多人测模型时会直接看输出正文print(response.choices[0].message.content)这样当然能看出模型有没有回答但它不能告诉你一个关键事实这次真正返回的模型是谁对于普通聊天这个细节可能没那么敏感。但对于新模型评测、成本核算、路由排查、SLA 统计它非常重要。原因很简单如果你请求claude-fable-5但响应里的model是claude-opus-4-8那么这次输出还能不能算作 Fable 5 的能力样本至少不能简单算。所以这次我把日志拆成两层requested_model请求里写的模型 returned_modelAPI 响应里返回的模型然后再看response_id finish_reason content_empty usage elapsed_ms2. 测试设计15 条请求不做大 benchmark这次不是严格 benchmark只是一次针对“可调用性”和“返回模型一致性”的小样本检查。测试接口GET /v1/models POST /v1/chat/completions测试任务如下任务主要观察点smoke能否返回指定文本reasoning简单推理是否正确输出是否完整code_review能否发现代码中的真实 bugcreative_control中文生成是否遵守约束identity_route_probe是否能从模型正文判断路由或降级证据每个模型各跑 5 次总共 15 条请求。我没有把这轮测试设计成“能力榜单”因为样本太小而且部分任务受max_tokens设置影响明显。它更适合回答下面这些工程问题模型是否可见请求是否能成功content 是否为空返回模型是否与请求模型一致finish_reason是否暴露了截断或工具调用问题3. 模型列表Fable 5、Opus 4.8、Sonnet 5 都可见GET /v1/models中三个模型都能看到模型是否可见endpoint typesclaude-fable-5是anthropic,openaiclaude-opus-4-8是anthropic,openaiclaude-sonnet-5是anthropic,openai这说明第一步没问题从模型列表看三者都是可选项。但模型列表只能证明“入口存在”。真正的运行行为要看 chat completion 的返回。4. 汇总结果Fable 5 的一致性最值得关注总表如下请求模型请求数HTTP 200content 非空返回模型与请求模型一致finish_reasonstop平均耗时claude-fable-55552313695 msclaude-opus-4-85555413858 msclaude-sonnet-55545215256 ms如果只看 HTTP 200三者都正常。如果看 content 非空Fable 5 和 Opus 4.8 都是 5/5Sonnet 5 是 4/5。但如果看 returned model一下就不一样了请求 claude-fable-55 次 返回 claude-fable-52 次 返回 claude-opus-4-83 次这说明 Fable 5 本轮最值得关注的问题不是“文本写得好不好”而是“返回模型字段不稳定”。5. Fable 5 明细5 次请求有 3 次 returned model 是 Opus 4.8下面是请求claude-fable-5的明细任务请求模型响应 modelresponse idfinish_reason耗时smokeclaude-fable-5claude-fable-5msg_015Wqx2LE1AemAdGYpDmkAw1stop15343 msreasoningclaude-fable-5claude-opus-4-8msg_01LhtDxG3rGPbSH79HsCGnuylength11857 mscode_reviewclaude-fable-5claude-fable-5msg_01RJqbZnKv5vm6vn3Ybx45ezlength15017 mscreative_controlclaude-fable-5claude-opus-4-8msg_01Qbr9evb9CGFLhk2uxgDmHwstop15041 msidentity_route_probeclaude-fable-5claude-opus-4-8msg_013vwMf74gNMis5egogfMpicstop11218 ms这张表比截图回答正文更有用。因为它直接说明同样请求claude-fable-5返回模型并不总是claude-fable-5。6. 这是不是“Fable 5 降级到 Opus”不能这么直接下结论。从客户端能看到的只有响应字段。它可以证明本轮请求 claude-fable-5 时有 3/5 的响应 model 字段是 claude-opus-4-8。但它不能直接证明服务端内部发生了哪一种调度可能是 Fable 5 的部分请求被路由到 Opus 4.8可能是上游返回的实际模型名就是 Opus 4.8可能是网关或供应商侧存在别名映射可能是 fallback、灰度或模型归一化逻辑也可能是 Fable 5 当前阶段把 Opus 4.8 作为部分后备能力。所以我不建议写“Fable 5 主动降智”。更严谨的说法是API 层出现了 requested model 与 returned model 不一致的可观察现象。对开发者来说这个结论已经足够重要。7. 让模型自己解释有没有降级靠谱吗不靠谱。我专门设计了一条探测任务Return compact JSON with keys visible_model_claim, can_access_provider_logs, can_access_hidden_chain_of_thought, downgrade_evidence. Only state what is visible to you in this chat response. Do not speculate.这条请求的关键字段是Requested model: claude-fable-5 Returned model: claude-opus-4-8 Response ID: msg_013vwMf74gNMis5egogfMpic Finish reason: stop模型正文返回{visible_model_claim:null,can_access_provider_logs:false,can_access_hidden_chain_of_thought:false,downgrade_evidence:null}这其实是正常结果。普通 chat completion 模型不能读取 provider logs也不能读取 hidden chain-of-thought。让模型自己说“我有没有被降级”不是可靠方法。要查这种问题应该看API 响应里的model网关路由日志channel 日志计费日志上游返回原始 envelope8. 代码审查任务Fable 5 能抓 bug但 Opus 4.8 更完整代码题如下functiontopTwo(nums){leta0,b0;for(constnofnums){if(na){ba;an}elseif(nb){bn}}return[a,b]}题目说明输入可以包含负数。核心 bug 很明确a和b初始化为 0。如果输入是全负数比如[-5, -2, -9]结果会错。Fable 5 抓到了这个问题{bug:Initializing a and b to 0 fails when all numbers are negative...,fix:let a-Infinity,b-Infinity,test:topTwo([-5,-2,-9])...}Opus 4.8 也抓到了并且补充了更多边界全负数数组重复最大值数组长度不足 2这一题的结果可以这样看模型是否抓到核心 bugfinish_reason输出完整性claude-fable-5是length被截断claude-opus-4-8是stop更完整claude-sonnet-5否可见内容为空tool_calls不可用所以这一题不能说明 Fable 5 比 Opus 4.8 强。更准确的结论是Fable 5 有能力抓住关键 bug但本轮输出完整性不如 Opus 4.8。9. 推理题答案都对但 max_tokens 偏小推理题是A 7-step machine starts at 3. On odd steps it doubles the current value and adds 1. On even steps it subtracts 4. What is the final value after step 7? Return JSON with keys answer and steps.正确答案是 7。三者都答出了 7但finish_reason都是length请求模型响应 model答案finish_reason耗时claude-fable-5claude-opus-4-87length11857 msclaude-opus-4-8claude-opus-4-87length23414 msclaude-sonnet-5claude-sonnet-57length36726 ms这说明max_tokens260对这条任务偏小。所以这条不适合做速度排名也不适合做输出质量排名。它更适合提醒我们评测模型时finish_reason必须纳入结果表。10. Sonnet 5 的问题HTTP 200 但正文不可用本轮 Sonnet 5 最大的问题不是“弱”而是有一次正文不可用HTTP: 200 Response ID: msg_01VVQjZ5dy2LLRkp3CAYE8wt Returned model: claude-sonnet-5 Finish reason: tool_calls Content empty: true这类情况在业务里很麻烦。因为从 HTTP 层看它成功了但从用户体验看它没有给出可用正文。所以我建议无论用 Sonnet、Opus 还是 Fable都不要把 HTTP 200 当成最终成功。至少还要检查content 是否为空 finish_reason 是否可接受 是否触发 tool_calls 是否需要重试或 fallback11. 建议的日志字段如果你要测 Fable 5我建议最少记录这些字段requested_model returned_model response_id finish_reason content_empty usage elapsed_msPython 示例fromopenaiimportOpenAIimporttime clientOpenAI(api_keyYOUR_CRAZYROUTER_API_KEY,base_urlhttps://cn.crazyrouter.com/v1,)requested_modelclaude-fable-5startedtime.perf_counter()respclient.chat.completions.create(modelrequested_model,messages[{role:user,content:Return compact JSON with keys answer and reason.}],max_tokens300,temperature0.2,)elapsed_msint((time.perf_counter()-started)*1000)choiceresp.choices[0]contentchoice.message.contentorprint(requested_model:,requested_model)print(returned_model:,resp.model)print(response_id:,resp.id)print(finish_reason:,choice.finish_reason)print(content_empty:,notbool(content.strip()))print(elapsed_ms:,elapsed_ms)print(usage:,resp.usage)ifresp.model!requested_model:print(WARNING: returned model differs from requested model)这段代码里最重要的是print(returned_model:,resp.model)如果没有这一行模型评测很容易变成“看起来像测了 Fable 5实际上混入了其他 returned model 的结果”。12. 这轮测试的边界这轮测试能说明Fable 5 当前可以通过 API 调用。Fable 5 本轮 5 次 content 都非空。Fable 5 本轮 5 次里有 3 次 returned model 是 Opus 4.8。本轮没有看到 Fable 5 稳定超过 Opus 4.8 的证据。Sonnet 5 本轮出现一次 HTTP 200 但 content 为空。这轮测试不能说明Fable 5 永远会返回 Opus 4.8。Fable 5 一定没有任何场景强于 Opus 4.8。returned model 不一致一定等于供应商内部主动降级。15 条请求足够代表长期性能。如果要继续测下一轮应该增加每个任务多次重复更难的代码和长上下文任务OpenAI-compatible 与 Anthropic-native endpoint 分开测returned model 分布统计服务端路由日志、channel 日志、计费日志对齐Fable 5 返回 Opus 4.8 的比例追踪。13. 结论Fable 5 可用但先别急着下排名结论我的判断是Fable 5 可用但本轮不能证明它稳定强于 Opus 4.8。更重要的是请求 claude-fable-5 时部分响应的 returned model 是 claude-opus-4-8。对于普通用户这可能只是“模型能不能用”的问题。对于 API 用户这就是一个需要进日志、进监控、进评测表的问题。做 Claude Fable 5 测试时建议同时看三件事请求的模型是谁 API 返回的模型是谁 计费和日志里记录的模型是谁三者一致模型能力对比才更有意义。参考链接Crazyrouter 模型列表与 API 入口https://crazyrouter.com/models?utm_sourcecsdnutm_mediumarticleutm_campaignclaude_fable_returned_model_audit_20260704utm_contentcsdn_model_list原始站内实测文章https://crazyrouter.com/blog/claude-fable-5-vs-claude-sonnet-5-api-test-2026?utm_sourcecsdnutm_mediumarticleutm_campaignclaude_fable_returned_model_audit_20260704utm_contentcsdn_original_articleAnthropic Claude Fable 5 / Mythos 5 公告https://www.anthropic.com/news/claude-fable-5-mythos-5Anthropic Claude Sonnet 5 公告https://www.anthropic.com/news/claude-sonnet-5