“新 Fable 出现在云平台”“一个神秘模型跑分超过 Opus”“可能下周发布”，这三句话看起来能拼成一条完整的产品新闻。对准备更新模型路由、预算和内容排期的团队来说，真正要回答的是另一组问题：哪个模型已经由厂商正式确认？哪个只是第三方数据中的名字？能否用自己的账号调用？数字背后的测试条件是什么？截至 2026 年 10 月 30 日，公开资料还不足以把 Fable 5.5 或名为 Obsidian 3 的条目写成 Anthropic 新品发布。本文把证据逐层拆开，并给出一套可以照着执行的核验和试用流程。
这个结论并不否认有真实线索。LiteLLM 仓库确实出现过 azure_ai/claude-fable-5-5；“出现过”与“已发布”之间，隔着官方公告、正式模型 ID、账户权限、可复现调用和计费这几道门。把它们逐项核验，既能追踪进展，也能避免把未确认型号写进生产配置。
先给消息贴状态：发布、可见、可调用不是同一件事
截至本文核验时，Anthropic 的 Claude 模型目录列出的 Fable 为 5.1，Opus 为 5.5，同时还有 Sonnet 5.5 与 Haiku 5.5。官方目录没有列 Fable 5.5，也没有列“Obsidian 3”。Microsoft Foundry 的 Anthropic 模型目录同样能查到 Fable 5.1 与 Opus 5.5，却查不到 Fable 5.5。目录是一个时点快照，不构成“未来绝不会发布”的证明；它只能支持当前的发布状态判断。
这里至少有四种经常被混用的状态。名称被看到可能只是内部标签、缓存、第三方同步条目或测试别名。厂商宣布意味着有可核查的公告和产品文档。账户可调用还要有正确的模型 ID、地域、权限和成功请求。适合上线则必须经过自己的任务评估、费用测算及回退验证。一个状态不能自动推出下一个状态。
图 1｜把“名称出现”“官方列出”“账号可调用”“生产可用”分成四层。图为核验流程示意，不是某平台的实时截图。
同一个模型在不同渠道的上线时间也可能不同。即使某个发布日出现官方公告，也应分别检查 Claude 网页、Anthropic API、云平台和聚合服务的可用范围。对 API 团队尤其如此：控制台看得到选项，不等于当前密钥具备权限；网关能补全一个名称，不等于上游存在该部署。
Fable 5.5 线索里，最值得看的其实是撤回记录
10 月 13 日，LiteLLM 的自动同步提交给价格与能力映射表加了一行 azure_ai/claude-fable-5-5。这个事实可以核验，但不能顺手把该行继承的上下文长度、定价和能力标志当成 Fable 5.5 的官方规格。提交说明明确写着：大量字段沿用 Fable 5.1，且当时没有官方来源确认 Fable 5.5 的价格、窗口或能力。
紧接着，LiteLLM 维护者提交了删除该条目的修正记录。记录中给出两个很具体的反证：查询 Azure 模型列表未见该部署；用同名配置发起请求得到 DeploymentNotFound。这比“截图曾出现”更接近普通开发者要面对的使用现实。那次修正提交的状态还应照实写：它是维护者提出并关闭的 PR；不能把“提出删除”误写成“已在所有版本完成删除”。但其中公开的查询和 404 样例足以说明：单靠自动同步行，无法证明模型可用。
图 2｜同一条模型线索经历自动收录、维护者复核和部署不存在的调用反馈。时间线只表示可核验事件，不推断内部开发计划。
看到类似线索，最实用的做法是记录“三个版本”：发现时的网页或提交、后来是否被更正、自己账号在何时何地的调用结果。特别留意数据来源。第三方价格表、云平台公共目录、需要登录的管理 API、真实推理端点并非同一个系统；前两个都不能替代最后一个。
也不要把 DeploymentNotFound 解释过头。它说明该请求指向的部署不存在或不可用，并不证明厂商内部没有任何实验。我们的稿件面向外部读者，能确认的是公开状态与账户可用性，不能猜内部路线图。
“Obsidian 3”跑分能说明什么，不能说明什么
另一个传言来自基准测试数据中短暂出现的“Obsidian 3”名字。即使一行成绩与截图都真实，它最多证明某份数据曾用这个标签记录一次配置。要进一步证明它是 Anthropic 的下一代 Opus，需要至少一项可复核的厂商身份信息：正式模型 ID、官方声明、供应商签名的测试说明，或能够核对响应模型字段与账单的授权访问。名字本身不是品牌归属证明。
排行榜最容易遗漏的是“模型以外的变量”。同一模型换了代理框架、工具集、检索内容、思考档位、时间预算、重试次数和人工介入，结果就可能变化；榜单上的一个百分点不一定来自权重升级。对编程基准还应问：题集是否公开、是否有污染风险、评审是单次还是多次、失败案例是否可查、代码是否按维护者标准验收。没有这些条件，数字只能作为进一步测试的线索。
图 3｜同一成绩可能同时受模型、代理框架、工具、预算与评审方式影响。示意图用于解释为何不能从代号直接推断产品身份。
一种常见误读是：某个代号的成绩略高于当前已发布模型，于是标题直接写成“下一代 Opus 已经超越”。这里至少跳过了三步：先确认代号属于谁，再确认与 Opus 使用同一评测条件，最后确认差异大于测试波动。若三步任何一步缺证据，正文就应使用“数据中曾出现该标签”“身份未获确认”，而不是“新 Opus 跑分曝光”。
社区里的图片或视频演示也要按相同标准看。鹈鹕骑车、游戏手柄、精细 SVG 等作品可以展示某次输出，却无法单独证明模型名称、调用路径、提示词、修改次数或是否有人后期加工。图片质量更不是通用能力测试；重复流传的样题尤其容易受训练分布和提示词调优影响。把演示当作灵感没有问题，把它当作正式发布或性能排名则证据不足。
IPO 是已确认事件，但不是型号和日期的证明
Anthropic 在 10 月 26 日宣布已向美国证券交易委员会提交拟议 IPO 的 S-1 注册文件；SEC 的公开申报记录也能核对日期和文件类型。这是一件真实的公司事件，却不能推出“Fable 5.5 下周发”“神秘代号就是新 Opus”，也不能把网上流传的估值区间直接写成最终发行估值。
产品发布取决于安全评估、容量、价格和平台准备情况；IPO 进度有其独立的监管流程。两条时间线相近，容易让人觉得它们互相证明。更谨慎的写法是：上市申报可能提高市场对产品节奏的关注，但公开文件没有替未发布模型给出发布日期。若今后真的有公告，应以公告当日的型号、型号 ID、地区和试用资格更新文章，不用事前推测倒推事实。
图 4｜S-1 申报属于已核验公司事件；新型号何时发布属于待证实产品事件。两条线不能仅凭时间接近而合并。
对内容团队来说，这个区分还有实际好处。它允许及时报道“市场传闻是怎么来的、目前有哪些反证”，同时不把预判伪装成新闻。标题可以保留读者关心的型号，但要写清“传闻”“核验”“尚未确认”。如果后来官方发布，更新记录可追加在文章开头，说明核验时点与变化，避免读者把旧判断误当实时信息。
开发者可复用的六步核验流程
**第一步，打开官方模型目录与发布日志。**优先查看 Claude 模型目录和 Anthropic 新闻页，记录查看日期、截图或存档。没有出现在这些页面，不等于永远不会发布，但公开稿件不得写成已经发布。
**第二步，查渠道目录。**云平台看官方目录及该地区的部署文档。不要拿第三方网关的可选项代替上游发布信息。若条目只在社区截图出现，记录“截图未独立复核”；不要据此给出价格、窗口或服务等级。
**第三步，核对精确模型 ID。**厂商可能使用显示名、别名和快照 ID。核验时把它们分开保存，注意 Fable 5.1 与所谓 Fable 5.5 不能混写。正式文章中的参数与价格，必须与一个可明确定位的官方 ID 对应。
**第四步，小配额发起真实请求。**用已获授权的测试账号和脱敏输入，记录时间、区域、端点、请求 ID、HTTP 状态、响应中的模型字段。404、403、429 含义不同：404 可能是部署不存在，403 可能是权限不足，429 可能是限流；任何一种都不能单独证明模型不存在于所有渠道。
**第五步，跑自己的对照题。**挑 10—20 道团队真实任务，固定输入、工具、超时和验收标准。把代码是否通过测试、文档是否可追溯、人工返工分钟数与请求成本一起记录。样题越接近业务，越能决定是否迁移；追热点的展示题不应成为生产路由依据。
**第六步，设定发布阈值。**只有在官方发布、账户可用、质量通过、费用可预估、回退可执行时，才进入小流量试用。任何一项没有结果，状态写“待核验”或“仅观察”，不要占用正式生产模型 ID。
图 5｜从公告、目录、模型 ID 到实际调用、对照试验和回退。每一步都有可保存的证据，不靠传闻推进。
可把一次核验写成一条记录：名称 / 发现位置 / 官方状态 / 渠道状态 / 账户调用结果 / 任务测评 / 成本 / 决定 / 下次复查日期。例如，“claude-fable-5-5；第三方同步记录；官方目录未列；Foundry 公开目录未列；测试部署返回 404；未跑评测；暂不接入；官方公告后复查”。这条记录里，404只描述当次环境，不能扩大为全球断言。
Apito 团队：把型号可见、调用成功和账单分开验收
使用 Apito 或其他 API 接入层时，界面上的候选型号只应视为配置入口。团队要分别确认三个事实：上游正式模型 ID 是否存在、当前账号和地区是否获准调用、成功请求是否按预期出现在用量与账单里。本文没有声称 Apito 已提供 Fable 5.5 或 Obsidian 3；应以实时模型列表和授权情况为准。
若有新型号开放，先用脱敏请求检验返回的 model 字段、请求 ID、耗时、输入输出 token 和错误码。再把小样本任务与当前稳定型号做盲测。记录每个“通过人工验收任务”的总成本，而不是只比较标价；遇到超时、重试、缓存失效和 429，也计入费用与稳定性。确认回退路径后才逐步放量。
哪些说法适合写进稿件，哪些应先等
可以写：“截至 2026 年 10 月 30 日，官方模型目录仍列 Fable 5.1 和 Opus 5.5；LiteLLM 曾自动收录一个 Fable 5.5 条目，随后出现针对该条目缺少 Azure 部署的修正记录。”也可以写：“社区作品和基准代号引发讨论，但身份与发布安排未获厂商证实。”这两句都有明确的证据边界。
不宜写：“Fable 5.5 已在 Azure 上线”“Obsidian 3 确认是新 Opus”“下周必发”“细节更多所以性能全面超越”“为 IPO 即将放出双模型”。这些句子要求的证据比当前资料多，尤其是发布日期和因果动机。即使日后预测碰巧成真，今天无证据的说法也不会因此变成今天的事实。
读者若只是想选模型，当前能直接做的是比较已正式列出的 Fable 5.1、Opus 5.5 等型号，按账号权限和真实任务测试。官方模型目录给出了现行 ID 与定位；关于未来型号，只需设一个更新提醒。把精力放在可调用能力上，等正式 ID 出现再更新路由，通常比追逐无法复现的样图更省时间。
核验所用的一手资料
- Anthropic Claude 模型目录：核对已公开型号、ID 与产品定位。
- Microsoft Foundry 的 Anthropic 模型目录：核对公开云平台条目。
- LiteLLM 自动同步记录与后续修正记录：核对条目出现、继承字段和部署调用结果。
- SEC 的 Anthropic S-1 公开记录：核对申报事件；不承担模型发布证明。
常见问题（FAQ）
Fable 5.5 现在能用吗？
截至 2026 年 10 月 30 日，Anthropic 官方模型目录与 Microsoft Foundry 公开目录未列出它。LiteLLM 的相关修正记录还展示了一个 Azure 部署不存在的调用结果。若以后官方发布，仍要用自己的账号、地区和权限实测，不能只看目录名称。
“Obsidian 3”是不是下一代 Claude Opus？
公开信息不足以确认。基准数据里的代号并不自动等于厂商型号；需要正式模型 ID、提供方确认或可核验的授权调用证据。文章不把一个匿名条目当成 Anthropic 产品。
既然 Anthropic 已提交 S-1，是不是新模型很快就会发布？
S-1 申报已获 SEC 记录证实，但申报文件不是产品发布日期公告。发布日期只能依据 Anthropic 的正式发布信息确认。
看到模型名出现在 LiteLLM 或其他网关，就能写进生产配置吗？
不能。网关条目可能来自自动同步、手动映射或继承配置。先核对上游官方 ID、账号权限与端点请求，再以真实任务验证质量、成本和回退。
社区的精美图片能证明新模型更强吗？
一张作品只能说明某次输出的观感。没有可复核的模型 ID、完整提示词、生成次数、后处理信息和一致的对照条件，就不能据此判断通用能力或正式发布状态。
