AIREITER目前，买家在查看 Muse Spark 1.3 API 定价时，最常见的数字是：每百万输入 Token 1.25 美元、每百万输出 Token 4.25 美元。这可以作为预算起点，但未必算得上一份在所有公开渠道中都完整明确的 1.3 价目表：Meta 表示其价格与 1.2 一致，而部分目录中仍只列出了前代模型。价格更低的 Contributor 路线对 1.3 来说更不确定，同时还涉及数据使用方面的取舍。
现在可以据此做预算的价格
Muse Spark 1.3 于 2026 年 9 月 2 日发布，可通过 Muse Code 和 Meta Model API 使用。Meta 的发布材料称，新版本定价与前代相同。根据 Model Price Watch 于 9 月 5 日记录的价格快照，其查阅 Meta 自身定价页面后，发现 Standard 档位费率如下：
| Token 类型 | 当前预算费率 | 可信度与适用范围 |
|---|---|---|
| 输入 | 每 1M Token 1.25 美元 | 据报为 Meta Model API 的 Standard 定价 |
| 输出 | 每 1M Token 4.25 美元 | 据报为 Meta Model API 的 Standard 定价 |
| 缓存输入 | 每 1M Token 0.15 美元 | 据报为缓存读取费率 |
这里的单位是每百万 Token，不是每千 Token。该追踪网站按输入与输出 3:1 的权重计算，得出约每百万 Token 2.00 美元的混合成本；下文账单示例则采用 5:1 的工作负载比例。该网站还称，Standard 档位没有单独的长上下文溢价。
不过有一点需要特别留意。AI on Mac 的技术评测发现，公开开发者目录里仍明显展示的是 Muse Spark 1.2，而不是完整的 1.3 定价条目。该评测认为，由于 Meta 表示定价不变，1.3 采用 1.25/4.25 美元是合乎逻辑的预期；但在该评测进行时，这组具体数字的证据链仍是间接的。
实用建议：初步测算可按输入 1.25 美元、输出 4.25 美元计算；正式将生产流量迁入前，务必核对 Meta 的实时价目表。不要因为某个第三方页面列出了这一价格，就把它当成永久保证的 1.3 价格。
三种工作负载的账单示例
计算方式很简单：
输入百万 Token × 输入费率 + 输出百万 Token × 输出费率
| 工作负载 | 输入 | 输出 | Standard 预估 | Contributor 参考价* |
|---|---|---|---|---|
| 轻度 | 1M | 0.2M | 2.10 美元 | 0.14 美元 |
| 中等 | 10M | 2M | 21.00 美元 | 1.40 美元 |
| 高强度 | 100M | 20M | 210.00 美元 | 14.00 美元 |
\*Contributor 一栏采用目前已有文档记录的 Muse Spark 1.2 参考价格，即每百万输入 Token 0.10 美元、每百万输出 Token 0.20 美元，数据来自 Model Price Watch。这并非已经确认的 1.3 Contributor 报价。
以上示例固定采用 5:1 的输入输出比例。缓存命中、重试、推理输出和工具调用循环都会显著改变实际账单。对于反复读取同一个代码库或指令前缀的 Agent 而言，缓存行为的重要性可能超过标价中的输入 Token 单价。
Contributor 不只是折扣，更是数据策略选择
从纸面价格看，Contributor 很有吸引力。Model Price Watch 报告称，Muse Spark 1.2 的输入价格约为每百万 Token 0.10 美元，输出价格约为每百万 Token 0.20 美元；但这一低价档位的限流也低得多：每分钟 100 个请求，而 Standard 为 3,000 个请求。其数据使用条款也有所不同。
因此，Contributor 不适合被默认视为生产环境的自动选择。如果该档位的数据政策与专有代码、客户记录或受监管工作负载相冲突，再低的 Token 成本也没有实际意义。
本文收集到的证据无法确认 1.3 Contributor SKU 是否存在、最终费率是多少，或当前限额为何。更稳妥的做法，是把它视为一个需要单独评估的采购选项：
- 确认模型目录中确实提供 1.3 Contributor 标识符。
- 发送私密内容前，阅读最新的数据使用和训练相关条款。
- 根据 Agent 的并发需求，核对每分钟请求数和每分钟 Token 数限制。
- 在完全相同的提示词和工具配置下，分别运行 Standard 与 Contributor 的相同工作负载。
- 比较每个成功完成任务的总成本，而不是只看 Token 单价。
r/opencode 中的一则真实用户讨论说明，政策问题并非纸上谈兵。u/MorpheusN_ 表示自己将该模型用于公开数据工作，并提到其速度优势，同时也对 Meta 的数据处理方式和较严格的护栏表达了担忧。该讨论没有正式的隐私分析，因此它只能证明用户存在顾虑，不能证明某项具体的数据保留政策。
“如今它大约比 Claude code 快 50 倍”——u/Routine-Gas-8264，同一 Reddit 讨论中的说法；这是一项未经验证的用户主张，并非受控基准测试。
这次 API 发布究竟带来了什么
Meta 官方的 Muse Spark 1.3 公告将其定位为面向长周期 Agent 工作、编程、工具调用和多任务处理的模型。该版本可通过 Muse Code 和 Meta Model API 使用。
现有证据支持以下四项实际特征：
- Agent 执行能力：Meta 表示，1.3 经过训练后可维持更长时间的目标，在规划出现缺口时恢复推进，主动请求澄清，并确认影响重大的操作。
- 编程：Meta 称，相比 1.2，1.3 在代码库规模和工具驱动的编程工作流中有所改进。
- 多模态输入：不要直接假设某种格式或端点已经启用，应先核实当前 API 文档。
- 长上下文：发布评测覆盖了 1M Token 量级，但评测范围不等于生产 API 必然保证的上限。
请直接从 Meta 当前开发者目录复制模型标识符，因为服务商目录、直连 API 和聚合平台使用的标识符可能不同。
AI on Mac 的评测提到，发布时 max reasoning 仍在等待额外的安全测试；如果你的应用依赖这一能力，应测试实时端点，而不是默认公告中的时间安排仍然有效。
不同工作负载该如何判断
优先在那些更看重工具调用、持续上下文和编程可靠性，而非一次性回答润色度的工作流中试点 Muse Spark 1.3。Meta 自己的对比结果称，相比 Muse Spark 1.2，它的工具调用次数减少约 20%、Token 使用量减少约 25%。这些都是厂商侧对比，应视为待在生产环境验证的假设，而非独立的成本保证。
用户反馈的大方向相近，但并不均衡。在该 Reddit 讨论中，u/MorpheusN_ 称赞 Muse Spark 1.3 适合“大规模网页研究”、审查、分类，以及原始工具调用速度；同一报告也批评它拒答过于严格、偏爱使用 Python 而非原生 Linux 工具，以及在细腻表达上较弱。这些观察均属轶事，可能高度依赖测试框架、套餐和具体任务。
| 工作负载 | 初步建议 | 原因 |
|---|---|---|
| 长时间运行的编程 Agent | 试点 1.3 | 发布重点及 Meta 的工具/Token 对比与此类工作负载契合 |
| 高吞吐量公开数据研究 | 仅在非敏感数据上测试 Contributor | 较低的参考价格可能重要，但数据条款和限额同样关键 |
| 私有代码库 | 从 Standard 或获批的企业路径开始 | 不要为了未经确认的折扣而牺牲治理确定性 |
| 需要细腻表达的写作或解释 | 不要默认它是升级 | 早期用户反馈不一，且 1.3 优化重点在执行与 Agent |
| 现有 1.2 生产 Agent | 切换前做回归测试 | 澄清行为、工具调用频率和拒答模式都可能变化 |
看基准测试，要看证据而不只是分数
发布时呈现的基准测试覆盖面很广，但证据状态比表格行数更重要。AI on Mac 的评测区分了 Meta 自测、发布材料数据和公开榜单核查。在 9 月 2 日检查时，若干 1.3 成绩尚未同步到对应的独立公开排行榜。
| 能力 | 报告的 1.3 成绩 | 引用检查时的证据状态 |
|---|---|---|
| Agent 与工作成果任务 | GDPval-AA v2 1,754 Elo；JobBench 64.9；OSWorld 2.0 66.9 | 发布材料数据；复查公开页面时未看到可见的 1.3 GDPval 条目 |
| 编程与工具调用 | DeepSWE v1.1 75.4%；SWE Atlas 59.4；Terminal-Bench 2.1 88.8% | Meta 或发布材料报告；公开排行榜尚未同步 |
| 长上下文检索 | MRCR v2 在 256K–512K 达到 98.5；在 512K–1M 达到 98.1 | 发布材料中的检索评测，并非通用推理测试 |
这些基准衡量的是不同能力，不能平均计算，也不应直接横向比较。98.1 的检索分数，不代表任意百万 Token 内容的综合推理也会同样可靠。
Agent 基准测试尤其依赖测试框架。请在自己的代码库中测试，并跟踪完成率、人工干预、工具调用、Token、延迟与实际成本。
迁移决策：选 1.3、继续 1.2，还是都不选
对于已经部署 1.2 的团队，这并不是一次理所当然的升级。建议通过灰度测试完成以下验证：
- 选取 10 个有代表性的代码库任务，其中至少包含 2 个故障恢复案例。
- 使用相同的工具定义、系统提示词、上下文预算和超时设置。
- 先采用 Standard 档位定价，避免 Contributor 折扣掩盖质量回退。
- 记录成功率、工具调用次数、输出 Token、干预次数、延迟和成本。
- 审查拒答、澄清请求，以及虽能编译却改动了无关行为的代码修改。
应选择每个成功任务成本更低的档位，而不是 Token 单价更低的档位。Contributor 最适合的场景是使用公开数据的高吞吐、低敏感性工作负载；最不适合的则是提示词或输出中包含你无法接受按该档位当前数据条款共享的内容的任何工作流。
Muse Spark 1.3 API 定价 FAQ
1.25/4.25 美元是确认后的 1.3 价格吗？
这是目前最有依据的 Standard 档位预算数字：每百万输入 Token 1.25 美元、每百万输出 Token 4.25 美元，缓存输入据报为 0.15 美元。由于一些公开目录仍展示 1.2 条目而非完整的 1.3 条目，仍应核对 Meta 的实时价目表。
1.3 Contributor 的价格已确认吗？
根据本文审查的证据，尚未确认。常被引用的每百万输入 Token 0.10 美元、输出 Token 0.20 美元，是 Model Price Watch 报告的 Muse Spark 1.2 Contributor 参考价格，不是确认后的 1.3 报价。在当前服务商目录明确列出该档位、且数据使用条款清晰前，任何 1.3 Contributor 列表都应视为暂定信息。
缓存输入会更便宜吗？
会，当前 Standard 参考价格显示，缓存输入为每百万 Token 0.15 美元。不过，缓存资格、缓存时长和实际命中率仍会影响账单，因此应依据请求日志估算，而不要假定每个重复前缀都会命中缓存。
API 是否保证一百万 Token 上下文上限？
Meta 的发布评测覆盖到 1M Token 量级，但这一结果不保证生产 API 的上下文上限。围绕该能力进行系统设计前，应先查看实时端点规格。
Muse Spark 1.3 一定比 1.2 好吗？
对于新的长周期编程或 Agent 工作流，它是更合理的首测对象。但现有 1.2 系统仍需要回归测试，因为即使提示词不变，工具调用频率、澄清行为、拒答模式和输出风格也可能发生变化。
Contributor 档位能用于私有源代码吗？
不要因为价格更低就默认它适用。请与 Meta 确认当前的数据使用、训练、保留、安全和限流条款；若这些条款不符合你的要求，应使用获准用于该代码库的档位，或将工作负载限制在非敏感数据上。
对 1.3 应先按 Standard 费率预算；在 Meta 的实时目录确认 SKU 与数据条款前，将 Contributor 的节省视为潜在收益即可。