Meta最强AI模型不进API：50美元订阅Muse Code才能用

Meta一次发布了两款前沿模型，但开发者只能调用其中较弱的那一个。据TechCrunch、Meta官方产品页和Artificial Analysis的独立评测，Meta在10月12日（周一）推出的Muse Wonder Full是其自家评分卡上表现最好的模型，却仅限Muse Code订阅用户使用。而API里能调到的Muse Wonder，在Meta自己的14项基准对比中输给同价位的Claude Opus 5.5多达9项。

两个模型，两扇门

Meta这次发布的策略很简单：把最强模型留在自己的代理产品里。Muse Wonder Full在Meta的Personal Superintelligence Index上拿到59.1分，领先所有模型；而API可用的Muse Wonder只有54.3分，不仅落后于Opus 5.5（55.2），也不如GPT-6 Astra（54.5）。

价格上，Muse Wonder在Meta Model API中定价为每百万输入token 4美元、每百万输出token 20美元，与Claude Opus 5.5完全一致。但在Artificial Analysis Intelligence Index上，Muse Wonder得分52，Opus 5.5得分58。花同样的钱，独立评测显示你买到的是更弱的模型。

要使用Wonder Full，你需要订阅Muse Code，最低档Power Usage计划每月50美元，最高档Maximum Usage计划每月200美元。

Personal Superintelligence Index 是 Meta 为配合 Muse 系列发布而推出的自研评测体系，据其官方说明，该指数针对个人助理与代理场景下的推理、长上下文吞吐、工具调用和编码任务等维度综合打分，采用 Meta 内部提示词与工具框架。需要指出的是，这类厂商自建指数并非行业通用标准，其题目、权重和运行环境均不对外完全公开，因此分数更适合横向比较 Meta 自家模型代际差异，而不宜直接与 Artificial Analysis 等第三方榜单互推。Artificial Analysis Intelligence Index 则是独立评测机构 Artificial Analysis 维护的公开榜单，聚合多套标准化基准并采用统一推理配置，覆盖约 200 余个模型，常被用作跨厂商对照。两者口径不同，导致同一模型在两张榜上分数差距可观，这也是原文中 Muse Wonder 出现「自家 54.3 分、独立 52 分」的原因之一。

逐项拆解：Muse Wonder的强项与短板

Meta自家评分卡的14行对比中，Muse Wonder赢了5行输了9行，Wonder Full则赢了8行输了6行。逐行细看会发现一些有意思的分化。

Muse Wonder在DeepSWE 1.1上以78.8对74.2击败Opus 5.5，在Harvey法律代理基准LAB-AA上以10.0对4.2大幅领先。它还拿下了SWE-Marathon的53.1分对46.3分。但Meta自己在模型卡中标注，SWE-Marathon并非受控的同构比较。Muse Wonder在发布时被Artificial Analysis排在219个模型中的第9位，属于前沿级别。

问题在于定价策略。Meta的Alexandr Wang曾对Handy AI表示API定价将"显著低于"竞争对手。这一说法对Claude Fable 5.1每百万token 10/50美元的定价成立，但对Opus 5.5不成立。

文中反复出现的 SWE-Marathon 与 DeepSWE 1.1 都是面向软件工程代理的基准。SWE-Marathon 侧重点不在单次修复，而在于让代理在长周期、多步骤的任务链中持续推进，例如跨文件重构、连续迭代直到测试通过，因此更贴近「长时程编码」能力，而非一次性补丁正确率。DeepSWE 1.1 则是 DeepSWE 系列的更新版，主要考察多仓、多依赖场景下的工程任务完成度。二者与 Harvey LAB-AA 这类垂直领域基准一样，都依赖一套执行环境、工具集和评分脚本。Meta 在模型卡中标注 SWE-Marathon「并非受控的同构比较」，指的正是各厂商运行该基准时所使用的代理框架、工具数量、重试次数和推理力度可能不同，分数不能简单视为模型裸能力的对等比较。

模型正在变成代理的功能模块

Meta这次发布折射出一个更大的行业趋势：过去，实验室发布模型，模型进入API，开发者自选工具调用。编辑器、代理和脚本都是通往同一个房间的门。

Wonder Full不进API，意味着Meta最强的模型成了Meta自家代理的一个功能。你不能单独选择模型，你得选择Muse Code，付费订阅，模型随之而来。Claude Code已经绑定Claude的计划，Codex绑定ChatGPT的计划，Meta更进一步：最强模型只存在于捆绑包中。

所以现在选一个代理，等于选择了一整套限制：能触达哪些模型、哪个计划及其用量上限、在哪套沙箱和审批模型下工作、账单落在谁头上。

Meta这么做有一个合理推测：模型卡明确说性能"会随量化、服务配置、提示词、工具和代理框架而变化"。如果框架本身影响分数，把最强模型只放在自家框架里，是控制用户看到的结果的一种方式。

推理力度（reasoning effort） 是近年前沿模型普遍引入的可调参数，通常分为 low、medium、high、xhigh 等档位，档位越高，模型在回答前生成的内部思考链越长，相应地消耗更多输出 token、延迟更高，但在复杂推理和长周期任务上通常得分更好。不同档位之间同一模型在基准上的分数可能相差数个百分点。这就是原文强调「Wonder Full 数据使用了 xhigh 推理力度」的意义：若对比双方未在同一档位下运行，分数差异可能部分来自配置而非模型本身。此外，量化（quantization） 指将模型权重从高精度压缩为低精度以降低推理成本，通常伴随轻微能力损失；服务配置 则包括批处理大小、并发上限、上下文窗口截断策略等。这些因素共同构成厂商在自家代理内更易控制的变量，也是「把最强模型留在自家框架里」这一策略在技术上的合理动机。

Muse Code的50美元值不值

公平地说，Muse Code本身有其价值。产品页列出了内置多代理协调、并行worker、后台审查者、隔离worktree中子代理的cookbook，以及"每个操作可审计"。Meta还描述了两个模型特性：Active Memory跨对话携带相关上下文，Active Focus在困难目标上持续尝试不同路径并在关键操作前确认。

Wonder Full在长周期编码任务上表现最强：SWE-Marathon得分57.5对Opus 5.5的46.3，DeepSWE 1.1得分79.0对74.2。但模型卡提醒SWE-Marathon不是受控同构比较，且Wonder Full的数据使用了xhigh推理力度，这一行需要谨慎对待。

早期反馈好坏参半。在Hacker News的讨论中，有评论者称Muse Code的沙箱"在Mac和Linux上都从未正常工作过"，另一位说付费后不断报错。也有人表示热情。这些只是发布当天少数人的评论，原作者也未亲自运行过Muse Wonder或Muse Code。

别把自己锁死在一个代理上

如果模型会越来越藏在代理背后，防御策略就是保持代理可替换。原文建议：每个代理使用独立的登录和计划；在同一仓库上并行运行，一个任务一个git worktree，尝试新代理的代价只是一个分支；当一个代理触及用量上限，或更好的模型出现在另一个代理背后时，随时切换。

目前接入Muse有两条路。一是安装Meta自己的代理，命令行工具muse会安装到~/.local/bin。二是把Claude Code指向Meta的API，通过设置环境变量ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN和ANTHROPIC_MODEL等，将模型ID替换为muse-wonder-1.0。但这条路只能用到Muse Wonder，永远用不到Wonder Full。

ANTHROPIC_BASE_URL 是 Anthropic 官方 SDK 与 Claude Code 支持的端点覆盖环境变量，将其指向兼容 OpenAI 或 Anthropic 消息格式的第三方服务后，客户端便会把请求发往该地址；ANTHROPIC_AUTH_TOKEN 用于提供对应服务的密钥；ANTHROPIC_MODEL 则指定实际调用的模型 ID。三者组合即可在不改动 Claude Code 源码的前提下切换后端，这也是原文所说「把 Claude Code 指向 Meta 的 API」的实现方式。需注意，这种重定向依赖目标服务对 Anthropic 消息协议的兼容程度，工具调用、流式响应和系统提示词的处理可能存在差异；同时 Meta 在 API 层只暴露 Muse Wonder，因此无论怎么配置环境变量，这条路都触达不到仅存在于 Muse Code 订阅内的 Wonder Full。

多代理并行的实践方案

原文作者开发了Hermes IDE，因此这部分需要带着这一背景来看。Hermes在真实终端中运行每个代理，所以即使是它从未听说过的CLI也能工作。按⌘N（Windows和Linux上是Ctrl+Shift+N），选择"Custom agent"，填写名称和命令即可。Hermes不会索取你的token，登录过程在该终端内完成。

Claude Code和Codex作为内置代理出现在同一列表中。每个任务在独立的worktree中获得hermes/<task>分支，三个代理不会触碰彼此的文件。当一个代理触及用量上限时，你可以继续在另一个中完成任务。

局限也很明显：Hermes不知道自定义命令的审批模型，也没有状态信号。注意力收件箱能告诉你Claude Code或Codex何时在等你，但无法告诉你muse的状态，你需要自己盯着那个终端。Hermes本身也很年轻，没有云代理和Docker隔离。

订阅整合时代的真实问题

当最强模型开始只出现在一个代理中而别无他处，"你用哪个代理"就变成了"你订了哪些服务"。每月50美元订阅一个代理，只为用一个无法从自己代码中调用的模型，这个交换是否划算，取决于你的工作是否正好落在Wonder Full赢下的那些基准行上。

更深层的问题在于，Meta等厂商正在将模型能力变成代理订阅的专属权益。对开发者而言，保持代理之间的可替换性，可能比选择"最好"的那个代理更重要。