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 增加了一條新路線。