MiniMax M3 对比 Claude Opus 4.8：SWE-Bench 差 10 分但便宜 10 倍，怎么选（2026）

MiniMax M3 刚以 Claude Opus 4.8 十分之一的价格在 SWE-Bench Pro 拿到 59%——但标题里那句 “M3 干掉 GPT-5.5”，悄悄拿来对比的其实是 Anthropic 的上一代旗舰。

30 秒决策表

结论：负载是价格敏感的 agent 跑批，选 MiniMax M3，ofox 上 model ID 填 minimax/minimax-m3；负载是多文件 PR 上的硬推理，选 anthropic/claude-opus-4.8。最干净的验证方式是改一个字符串，用同一个 prompt 把两个模型都跑一遍——代码贴在文末。

速览：四种场景该选哪个

四个场景大概覆盖了 90% 的真实编码工作，一行决策：

最大的坑是把这个当成一锤子决策。大多数团队真正想要的是两个模型都接好、按任务路由——这也是 ofox 同 base_url 一行切换设计要解决的事。路由模式见后面的 ofox 切换方案。

关键规格对比

价格信息来自 ofox 模型广场 2026-06-13 快照。上下文和输出上限来自厂商文档。

两条规格值得停下来看一眼：

输入价比是 8.3 倍，输出价比是 10.4 倍。 典型编码 agent 每个输入 token 会吐出 0.2–0.5 个输出 token，所以实际生效的价比落在 9 到 10 倍之间——拍脑袋估算就按 10 倍走。

最大输出基本平手。 M3 是 131K，Opus 4.8 是 128K——这 3K 的差对操作形态没影响。两边都能一次吐一个小文件或十来个单元测试，超过约 130K 都要分多次调用。在输出上限上别纠结，按价格或质量选。

SWE-Bench Pro：故事的起点

SWE-Bench Pro 是 SWE-bench 家族里最难的变种——题目来自活跃维护的仓库，多文件 diff，不存在公开 ground truth 泄漏。在编码 benchmark 里，这是目前最难靠死记硬背刷分的一个。

2026 年 6 月初，三家旗舰的分数排队站好：

MiniMax 6 月 1 日发布稿的第一句话大意是：“M3 在 SWE-Bench Pro 上以十分之一的成本超越 GPT-5.5 和 Gemini 3.1 Pro。” 字面意思没错。漏说的是：Anthropic 四天前已经出了 Opus 4.8 拿 69.2%，而 MiniMax 的对比图选的是上一代 Opus 4.7 的 64.3%。

第三方验证状态是另一行小字。MiniMax 是在自己基建上跑的，用 Claude Code 当 agent 脚手架，评测逻辑对齐了官方方法论。SWE-Bench Pro 官方榜到本文成稿时还没收 M3。59.0% 当方向性信号看就行——第三方干净复现可能落在 56% 或 61%，但结论的形状不会变：M3 在 GPT-5.5 同一档，比 Opus 4.8 低一档。

诚实的一句话总结：M3 的数字是真的，但市场表达是有选择的。

Terminal-Bench 2.1 和多模态：M3 拉近差距的地方

SWE-Bench Pro 只是一个信号。在 Terminal-Bench 2.1 上——这是长时长终端执行的 benchmark，比如让 agent “把开发环境装好并跑通失败的测试”——MiniMax 报 M3 拿 66.0%。这个分数和 Opus 4.8 在类似区间打平（按 Anthropic release notes），明显领先 GPT-5.5。原因是 MSA 在长上下文下的解码速度让长工具循环的重试成本更低，agent 能在同一个预算内从更多失败里爬出来。

原生多模态是另一个卖点。M3 既吃图也吃视频。Opus 4.8 吃图但不吃视频。落到编码场景里这两条意义在两件事上：粘贴 stack trace 截图，喂一段 UI bug 的屏幕录像。截图两边都搞得定；屏幕录像只有 M3 能直接处理。

95% 的编码工作里这两条都决定不了选型——你大部分时间在盯文本。但只要你开始造那种”真去看浏览器”的 agent，这两条就开始起作用了。

价格数学：1M token 真实账单

厂商 benchmark 跑在理想基建上，账单跑在生产流量上。三种真实负载形态：

数字基于 ofox 2026-06-13 公布的价格：M3 输入 $0.60/M，输出 $2.40/M，缓存 $0.12/M；Opus 4.8 输入 $5/M，输出 $25/M，缓存 $0.50/M。算法是单价 × token 量，没做四舍五入。

放到团队规模上，画面就变了。拍一组代表性参数——5 名开发，每人每天 100 次 agent 调用，每次 500K 输入 + 100K 输出，每月 22 个工作日：

• M3 单次：$0.30 + $0.24 = $0.54。每月：5 × 100 × 22 × $0.54 = $5,940。
• Opus 4.8 单次：$2.50 + $2.50 = $5.00。每月：5 × 100 × 22 × $5.00 = $55,000。

5 个工程师默认路由到 Opus，每月烧掉一份小房贷。同样团队，M3 当默认、Opus 只在硬问题上调用（比如 10% 占比），账单大约 $11K。M3 的性价比论点不是”便宜就行”，而是省下来的 $44K 让你能在真正需要推理的 prompt 上更多调用 Opus。

“开源权重”那个小字：权重到底在哪？

MiniMax 6 月 1 日发布稿把 M3 定位成”唯一一个同时具备前沿编码能力、1M 上下文和原生多模态的开源权重模型”。权重和技术报告原计划在发布后约 10 天上 Hugging Face 和 GitHub——也就是 6 月 10–11 日窗口。

到 2026 年 6 月 13 日，MiniMax-M3 GitHub 仓库 上还挂着这行字：“this model is not yet released — this repository exists so the community can share what they need next.” API 在 ofox 等聚合商已经能调，但今天没办法自托管。这个仓库挂了占位符将近两周。

这不是致命问题——厂商权重发布迟到是常态，“10 天”是软窗口不是合同。但它确实改变了实际对比。如果你选 M3 就是冲着两周内能把权重拉进私有集群——这个赌还没赢。眼下从部署角度看，MiniMax M3 和 Claude Opus 4.8 都是 API-only，开源权重这条轴在 2026 年 6 月还分不出胜负。

等权重真的出来，账面会再变一次。自托管 M3 集群按你的 GPU 租约摊销，不按 token 计价——对于 24/7 持续负载，这是一条根本不同于 Opus 按 token 算的成本曲线。但那是权重真出现在 Hugging Face 那天再写的文章。

什么时候选 MiniMax M3

满足任一条件就选 minimax/minimax-m3：

1. 跑 agent 量很大。 Lint 修复 bot、格式化循环、codemod agent、“补 docstring” 流水线——这些场景的瓶颈是 token 成本，不是单 prompt 质量。M3 的 10 倍价格优势把 10 分的质量差距按 $/任务 算压平了。

2. 付费在长上下文输入上。 全仓 prompt（1M token 输入，小 diff 输出）是 MSA 解码速度和 M3 输入价格叠加的甜点区。一百万缓存 token 在 M3 上 $0.12，在 Opus 上 $0.50。

3. 视频输入是硬需求。 Opus 4.8 吃图但不吃视频。如果你的 agent 要看 30 秒 UI bug 录屏，本文比的两个模型里只有一个能做。

4. 要对冲 Opus 4.8 价位的风险。 即使主用 Opus 4.8 的团队也会把常规 prompt 路由到便宜模型上。M3 目前是 1M 上下文的子 $1/M 编码选项里最强的一个。

5. 第三方 SWE-Bench Pro 复现一旦走低你就准备切。 59% 当临时数字用，把你的栈搭成能一行 config 把 minimax/minimax-m3 换成下一个便宜的挑战者。

什么时候选 Claude Opus 4.8

满足任一条件就选 anthropic/claude-opus-4.8：

1. 一个错 patch 比 token 账单更贵。 生产 hotfix、安全敏感的重构、任何你 merge 前自己也会过一遍 diff 的场景。约 10 分的 SWE-Bench Pro 差距集中在最难的题上——不是平均题。

2. 造推理重的 agent。 “读这份事故复盘，提三个修法。""审一遍这段 OAuth 流程，找 bug。” Opus 4.8 在推理上相对 4.7 的提升是肉眼可见的，参考 Anthropic release notes 和 Simon Willison 的独立 review。

3. 已经在 Anthropic 生态里。 Claude Code、Anthropic MCP 工具链、动态工作流——都默认 Anthropic 风格的工具语义。M3 配 Claude Code 能跑（MiniMax 自己就用它当脚手架），但工具格式预期上会有边角 case。

4. “Fast mode” 价位刚好对得上你的场景。 Opus 4.8 出了一档 $10/M 输入 / $50/M 输出的 Fast mode，给延迟敏感场景用。比常规档贵，但比降级到 Opus 4.7 等更久强。这层对比的对手不是 M3——是 Anthropic 自家的 Opus 4.8 常规档 vs Fast 档，我们在 Claude Opus 4.8 发布解读 里讲过。

5. 评测套件已经按 Opus 校准过。 如果你的团队有一套”高级评审会不会过这个 PR”的评测，是按 Opus 输出调过的，换模型相当于让评测失效，得重新校准。这是真工程成本，不是手感问题。

什么时候两个都不选（和该用什么替代）

有几种场景，这个对比本身就是问错了问题：

• 每 token 预算低于 $0.10、做简单重构。 看更小的模型，比如 Claude Haiku 4 或 GPT-5.4 Mini——我们在 预算编码模型对比 里写过。lint-fix 用 GPT-5.4 Mini $0.10/M 就够的事，非要花 M3 $0.60/M 是表演。

• 今天就要本地部署。 M3（权重没到）和 Opus 4.8（闭源）都是 API-only。今天能本地跑的前沿编码模型选项是 Qwen 3.7 Max 之类——参考我们 Qwen 对比 Claude Opus 4.6 编码 那篇。

• 优化目标是严格延迟 SLA，不是成本。 M3 和 Opus 4.8 都是质量导向的，不是 p50 延迟导向。更小的快模型在 TTFT 上能把两个都甩开。

• 要一次评估多个前沿模型。 搭对比 harness，别选一个。多 agent 编码工具对比 那篇写过 harness 模式。

通过 ofox 同时跑两边：10 行代码 A/B

整个对比可以收敛成一个字符串改动，前提是你通过 ofox 的 OpenAI 兼容 endpoint 调两个模型。同一个 base_url、同一个 SDK，只换 model 参数。

Python——一个循环跑两个模型

from openai import OpenAI

client = OpenAI(api_key=OFOX_API_KEY, base_url="https://api.ofox.ai/v1")
PROMPT = "把这个函数重构一下，去掉重复逻辑: ..."

for model in ["minimax/minimax-m3", "anthropic/claude-opus-4.8"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
    )
    print(model, resp.usage.total_tokens, resp.choices[0].message.content[:120])

跑一次你能拿到每个模型的 token 用量，和输出前 120 字符——肉眼对比。把 total_tokens 数字塞回上面那张价格表，你得到的是真实 prompt 上的单次成本，不是厂商 benchmark 数字。

Node——同样的形状

import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OFOX_API_KEY, baseURL: "https://api.ofox.ai/v1" });
const prompt = "把这个函数重构一下，去掉重复逻辑: ...";

for (const model of ["minimax/minimax-m3", "anthropic/claude-opus-4.8"]) {
  const r = await client.chat.completions.create({ model, messages: [{ role: "user", content: prompt }] });
  console.log(model, r.usage.total_tokens, r.choices[0].message.content.slice(0, 120));
}

形状一样、endpoint 一样、SDK 调用一样。模型之间的迁移成本就是一个字符串。这也是这种对比能在 10 行代码里被回答，而不是一周对接两家厂商的唯一原因。

带工具调用的多轮 agent 循环也一样——两个模型都通过 ofox 接受 OpenAI 风格的 tools 数组。具体工具的格式建议在你那边测一遍，因为每家 provider 的严格模式处理在边缘上会差一点，但合同是同一份。

兼容性小坑：两个 API 实际差在哪

同一个 endpoint、同一个 SDK 调用——但有几个尖角值得在接生产之前知道。

系统 prompt 处理。 Claude Opus 4.8 把 system 角色当严格系统 prompt，权重最高。MiniMax M3（走 OpenAI 兼容路径时）把 system 折回对话流里，约束更松。如果你的 agent 依赖”系统 prompt 独占约束”——比如”除非用户问，不要调这个工具""永远用 JSON 返回”——M3 大多数时候会遵守，但长 tool 循环上更可能跑偏。解法：把关键约束在第一条用户消息里再说一遍。

工具调用格式严格度。 Opus 4.8 强校验工具参数 schema——你 parameters JSON Schema 把字段标 required 但模型填不出来，它会拒绝调用。M3 更宽松，偶尔会用占位字符串发出工具调用。如果你的工具层把占位串当合法参数，就会静默执行错动作；如果严校验，就会看到更多重试。修法两边都一样：在服务端校验工具参数，不要只靠模型。

缓存语义。 两边都有缓存输入价，但 Anthropic 把账单拆成 write 和 read。Opus 4.8 上你先付一次性的 cache write $6.25/M（5 分钟 TTL）或 $10/M（1 小时 TTL），之后每次 cache read 都按 $0.50/M——也就是上面规格表里的数字。M3 在 ofox 上是单一的 $0.12/M read 价，TTL 隐式，没有单独的写入加价。对那种一分钟里反复命中同一个长上下文 prompt 的负载（比如静态仓库 prompt 的代码评审 agent），M3 在 cache read 层显著更便宜。对那种缓存能保持几个小时、write 成本被多次 read 摊销的负载，Opus 4.8 的 1 小时档在质量之外也有竞争力。

流式 chunk 形状。 两边都流 OpenAI 兼容的 chunks，但 Opus 4.8 启用 extended thinking 时会吐更细的 delta.thinking 事件（在 我们 Opus 4.8 解读 里讲过）。如果你客户端把 thinking delta 跟 content delta 分开解析，那段代码对 Opus 有效，对 M3 是空操作——M3 目前不通过 OpenAI 兼容路径暴露 thinking delta。不是 bug，只是字段没被用。

provider 边缘的限流。 通过 ofox 调两个模型，你共享同一份限流配额，挂在你的 API key 上——不是两家厂商各自的独立配额。这正是网关形态要解决的事：Opus 限流时回落到 M3，M3 限流时回落到 Opus，全都不用倒腾两套凭据。

MiniMax M3 对比 Claude Opus 4.8 的整个问题，可以收敛成同一个 endpoint 上的一次字符串切换——这也是 2026 年选编码模型唯一靠谱的方式。

本文核对的来源

• Anthropic — Introducing Claude Opus 4.8（2026-06-13 验证）
• MiniMax-M3 GitHub 仓库（权重状态 2026-06-13 验证）
• TestingCatalog on X — Opus 4.8 SWE-Bench Pro 69.2% vs 4.7 64.3%
• The Decoder — MiniMax M3：百万 token 上下文的开源权重模型挑战闭源旗舰
• Simon Willison — Claude Opus 4.8: a modest but tangible improvement
• ofox 模型广场快照 minimax/minimax-m3 与 anthropic/claude-opus-4.8（价格 2026-06-13 验证）