MiniMax M3 专题：1M context、首周 $0.30/M，coding agent 价格战升级
MiniMax M3 把 1M context、原生多模态、coding agent benchmark、OpenRouter 路由与首周 50% API 折扣放在同一个产品里。它不是直接取代 Claude，而是在压低长任务 agent 的价格下限。
MiniMax 在 2026-06-01 发布了 MiniMax M3。重点不是「又一个新模型」，而是它把 1M tokens context window、原生文字/图片/视频理解、coding agent 定位，以及首周 API 折扣后的 $0.30/M input、$1.20/M output 放在同一条产品线上。
这让 M3 很适合放进 DeepSeek、MiMo V2.5 之后的价格战脉络来看。它不一定能直接取代 Claude Code 或 Cursor 里常用的高价模型；更实际的问题是：M3 能不能成为长 context planning、代码库问答、批量 agent loop 和多模态开发工作流里的低价路由？
1. 为什么 M3 不只是发布新闻
MiniMax 的模型页把 M3 定位为 coding 与 agentic frontier model，基于 MiniMax Sparse Attention，最高支持 1M context，并保证至少 512K tokens。它也强调 M3 是原生多模态：文字、图片、视频都可以作为输入，而这个 text model 的输出仍然是文字。
这个组合重要，是因为 coding agent 的 token 消耗方式和聊天机器人完全不同。真正的 agent 会把 repo context、 指令、日志、diff、工具输出、截图和失败尝试都放进循环。一个模型如果短 prompt 很便宜，但长 prompt 很贵或不稳定， 对 agentic work 来说就不是真的便宜。
MiniMax 也把 M3 的叙事放在多步骤工作，而不是单轮补全。官方博客列出 SWE-Bench Pro、Terminal-Bench 2.1、 MCP Atlas、论文复现、CUDA kernel 优化等内部测试结果。这些数字可以引用，但要当作厂商公布 benchmark， 不能替代自己的 repo eval。
2. 价格很好，但分层很重要
价格上最容易看错的是：M3 对一般输入长度和超长输入长度分开计价。在 MiniMax pay-as-you-go 页面， 截至 2026-06-05，standard service tier 的 M3 是这样列的：
| 输入长度 | Input | Output | Cache read | 备注 |
|---|---|---|---|---|
| ≤512K input tokens | $0.30/M | $1.20/M | $0.06/M | 首 7 日 50% off；原价是 $0.60/$2.40/$0.12。 |
| >512K input tokens | $1.20/M | $4.80/M | $0.24/M | 上线初期供应有限，主要面向超长 prompt。 |
OpenRouter 也把 MiniMax M3 标成 50% off，价格是 $0.30/M input、$1.20/M output，并列出 1M context。对已经用 aggregator routing 的团队来说很方便， 但真正跑量前仍要对照 MiniMax 官方 API 条款，因为折扣、cache 行为、长 context 限制可能不完全一样。
MiniMax 也在 M3 发布时更新 Token Plan：Plus $20/月、Max $50/月、Ultra $120/月。官方博客称三档大约对应 1.7B、5.1B、9.8B 的月度 M3 token 用量。对个人开发者和小团队来说，这可能比 API 表更重要；但前提是工具集成稳定， 而且 quota 规则真的符合你的工作方式。
3. 1M context 和多模态真正买到什么
1M context 不是让你每次都把整个 monorepo 塞进去。它真正买到的是：模型不必太早忘掉有用的工作状态。 好的 M3 测试案例应该是长但有结构的输入：repo map、设计文档、失败日志、选中的源代码、截图、API trace， 再加上清楚的目标任务。
原生多模态尤其适合跨越「代码」和「产品状态」的开发任务。例如：让 agent 看 UI 截图后找出相关 CSS， 对比生成图表和测试期望，或从产品 demo 的视频帧里整理 bug report。不要把这里的「multimodal」理解成图片或视频生成； M3 text model 的定位是文字输出，输入可以包含文字、图片和视频。
Cache 价格是另一个杠杆。Coding agent 经常重复发送同一份 repo summary、system prompt 和任务规则。 如果 cache hit 稳定，重复输入的成本会明显下降；如果 cache hit 率不好，标题价格就会低估真实账单。
4. M3 在 M2.5、M2.7 之后的位置
M2.5 和 M2.7 已经让 MiniMax 在低价 coding 与 agent 实验里变得有存在感。M3 的不同点在于 MiniMax 同时推三件事： 更强的 coding-agent benchmark、更大的 context 叙事、原生多模态输入。这更像新旗舰路线，而不是单纯小改版。
代价是 M3 不一定永远是最便宜的 MiniMax 路径。官方 API 页面仍然保留 M2.5 和 M2.7，一些高频、纯文字任务的 cache/read 经济性可能仍然有吸引力。如果你的任务只是简单抽取或分类，旧路线仍可能胜出；如果任务包含多步骤 repo 工作、长日志、截图或工具密集 planning，M3 才是优先测试的模型。
还有一个 open-weight 限制需要讲清楚。MiniMax 把 M3 称为 open-weight model，产品页也链接到 Hugging Face 和 GitHub。但截至本文撰写时，公开 GitHub repo 仍写着 M3 is coming，也没有发布 release。换句话说， self-hosting 可以先观察，但不要在权重和部署文档真正上线前，把它当成 production-ready 预算方案。
5. 能不能替代 Claude 的 coding 路由
更好的说法是「路由选择」，不是「替代」。Claude、GPT、Gemini、DeepSeek、MiMo、MiniMax 可以在同一个工程工作流里分工。 当失败成本很高，例如架构调整、安全敏感修改、高风险迁移或最终 review，premium model 仍然有价值。M3 更适合测试在成本、 context 和迭代次数占主导的环节。
| 工作负载 | M3 适配度 | 原因 |
|---|---|---|
| 代码库问答与 planning | 很值得测 | 长 context 和较低 input 成本比完美 edit quality 更重要。 |
| 批量重构草稿 | 值得测试 | 便宜迭代有帮助，但最终 diff 仍要测试和 review。 |
| 带截图的 UI bug triage | 有潜力 | 原生图片输入可以把视觉状态接回源代码。 |
| 安全敏感的生产修改 | 谨慎使用 | 厂商 benchmark 不能替代本地 eval、规则检查和 review gate。 |
MiniMax 模型页明确列出 API integration、AI coding tools、MiniMax Code 和未来 local deployment 等路径。 但接第三方工具时，要确认具体协议支持：OpenAI-compatible、Anthropic-compatible、tool calling、streaming、 reasoning fields、patch application 都会影响 coding agent 的真实可用性。
6. 采用前检查清单
- 开跑前同时看 MiniMax API 与 OpenRouter 实时价格；首周折扣有时限。
- 把 ≤512K input 和 >512K input 的任务分开算，因为后者价格更高。
- 用真实 agent session 测 cache hit rate，不要只看一次性 prompt。
- 做一个小型内部 eval：代码库问答、一次重构、一个 failing test、一个截图驱动 bug。
- 高风险 patch 保留 premium model 最终 review 路由。
- M3 权重和部署文档真正发布前，不要把 self-hosting 当成已落地方案。
实用结论是：MiniMax M3 让「低价长 context coding agent」第一次像一个严肃采购品类。它不会让 Claude 或 GPT 从高风险工作里消失，但它给 exploration、planning、多模态 triage 和高频 agent loop 增加了一条新路线。