Muse Ember：Agent 执行、API 价格与 200K 输入成本门槛

让 Agent 分类一千条记录，与让助手解决一个极难的问题，需要不同的成本设计。Meta 在 2026 年 11 月 9 日发布的 Muse Ember，重点就是大量重复的执行任务。它的起步单价很低，但同样需要关注 200K 输入门槛：超过后，整次请求都会采用更高费率，而不是只给超出部分加价。

先说结论

• Meta 官方 API 的准确 ID 为 muse-ember-1.0。
• 输入不超过 200K 时，每百万 token 的输入、输出价格分别为 0.10、0.50 美元。
• 超过 200K 后，整次请求改按输入 0.30、输出 1.50 美元计费。
• Ember 面向边界明确的重复 Agent 工作；困难的单次编程等任务，官方仍建议考虑 Spark 或 Wonder。
• 11 月 13 日 SandBase 目录未检索到准确 Ember 条目，Meta API 示例不等于 SandBase 已接入。

本文依据 11 月 13 日核查的官方文档，包含假设算例和评估建议，没有自测吞吐量或模型质量结论。

Ember 适合放在什么位置

Meta 的发布公告与模型文档把 Ember 定位为高效率执行模型，覆盖路由、抽取、工具调用和更大模型分派下来的具体任务。对于大量小请求占据主要账单的应用，这个定位有实际价值。

11 月 13 日的官方模型页，说明准确 ID 与功能范围，不代表应用级成功率测试。

例如，一个问题分拣队列可以让每次请求只处理一条工单，提供简短仓库背景和允许的标签。结果除了标签，还应给出支持判断的证据；信息不足的案例再交给更强模型或人工处理。这是建议的应用设计，不是本文已经跑通的 Ember 案例。

分工的前提是交接成本足够低。如果每个工作者都收到完整长对话，要重新推导任务目标，输出又必须由大模型全部重写，原本预期的节省很容易消失。先把任务包缩小、验收条件写清楚，再谈换模型。

官方规格与使用边界

最大输出是一项上限，不应该自动变成所有任务的默认预算。分类请求通常应返回一个小型、可验证的对象；代码任务可以留更多空间，但预算仍应对应预期产物，以及被截断后会发生什么。

默认思考档位也值得主动选择。高频业务应测试额外思考是否提高了足够多的合格率，以抵消耗时和输出费用。最低档与默认档都不能未经测试就叫作“最划算”。

对于最困难的单次编程、知识密集型问题和视觉编程，Meta 文档建议考虑 Spark 或 Wonder。并不是说 Ember 不能试，而是官方本身也没有把它定位为所有场景的统一最优解。

200K 门槛会让成本发生跳变

Meta 官方定价与限流文档列出的每百万 token 价格如下：

门槛计算包含缓存输入和已保存的历史对话。超过后，较高费率作用于整次请求，而不只是超出的 token。使用联网 grounding 时还有单独的查询费用，需要另算。

假设一次请求为 10,000 非缓存输入、2,000 输出 token，模型费为：

10,000 ÷ 1,000,000 × 0.10 + 2,000 ÷ 1,000,000 × 0.50 = 0.002 美元

如果输入变成 210,000，输出仍为 2,000，则为：

210,000 ÷ 1,000,000 × 0.30 + 2,000 ÷ 1,000,000 × 1.50 = 0.066 美元

这两个数字是算例，不是实际账单，也没有包含工具、重试和其他服务费用。它说明：即使期望的答案很短，直接转发长历史也可能改变成本结构。

不要为了卡在门槛以下就删除必要事实。更合理的办法是拆分独立任务、只检索相关资料，并把摘要策略纳入评估。便宜的请求如果丢掉了做判断必需的信息，就没有节省出一个可用结果。

Cloudflare 也有 Muse Ember 模型页。它可以作为接入线索，但不同服务应按各自计费规则核对，不能假定所有平台价格与限制完全一致。

11 月 13 日截取的另一条接入路径。上面的完整长上下文规则来自 Meta 官方定价文档。

官方直连示例：把供应商边界写清楚

下面依据 Meta 的 Responses 示例整理，未在本文中实际执行。MODEL_API_KEY 应是 Meta 的密钥，不是 SandBase Key。

curl --fail-with-body https://api.meta.ai/v1/responses \
  -H "Authorization: Bearer $MODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-ember-1.0",
    "input": "将这条工单分类为 billing、bug 或 feature request，并用一句话说明依据：十月份被重复扣款。"
  }'

接入工作队列前，还应增加有限重试、超时处理、结构校验，并记录失败尝试的费用。成功返回文本只能证明连接可用，不能证明标签正确，更不能证明更复杂的工具动作可以安全重放。

Model API 的账单也不同于 Muse Code 订阅。成本记录要写明实际产品入口，不能把订阅内的使用额度描述为任何 API 用户都能得到的折扣。

哪些任务交给工作者，哪些留在主流程

代码工作者应返回真实文件改动和测试结果，不能只给一段看起来完整的总结。信息抽取应返回来源片段或文档位置，让错误可以被复核，而不必重新运行整个流程。

用同一批样例比较现有模型，指标是每个验收通过输出的总成本。别只放容易成功的正例，也要包括信息缺失、无法归入标签、工具返回空结果的情况。正确行为有时是升级处理，不是强行猜一个答案。

如果要在 SandBase 上选择已经列出的候选，可以查看 GPT-6 Luna。它是另一款模型，不是 Ember 路由。Ember 的集成尚未核实时，Luna 卡片只能作为现有选项的评估入口。

11 月 13 日的 Luna 卡片，只代表替代路线，不证明 Muse Ember 已在 SandBase 上架。

另一种“大模型规划、快速模型执行”的思路可以看 Gemini 4 Hydrogen 解读。Meta 的开发工具背景则可参考 Muse Code 终端编程指南。

工作队列还需要应用层控制

每个任务应有稳定 ID，并区分“提出动作”和“执行动作”。如果模型请求超时，但外部工具已经写入成功，下一次尝试要先核对状态，再决定是否重放。换成某个模型不会自动解决幂等性。

同时限制工具步数并设置升级处理条件。高频任务里，少数循环作业就可能占掉大量费用与人工精力，应单独统计，不能用平均值掩盖。把原始输入、结构化结果和验收结论放在一起，才能看清错误是否集中在模糊标签、长历史或特定工具响应上。

常见问题

Muse Ember 是开放权重模型吗？

本次来源确认的是托管 API 访问，没有核实到可下载的 Ember 权重。不能从 Meta 的其他模型推导它也开放权重。

一百万输入的请求也按 $0.10/$0.50 算吗？

不是。这组单价适用于输入不超过 200K 的情况；超过门槛，整次请求按较高费率计算。

缓存历史也会触发门槛吗？

会。官方规则把缓存输入和已保存的历史对话计入门槛。

是否应该把每个 Agent 步骤都迁过去？

应先评估。重复、边界明确的任务值得试，但规划、重试和复核成本会决定最后是否真正节省。

建议从一条队列开始，同时测量合格率和完整成本，再逐步扩大流量。