TL;DR
MiniMax M3 は、コーディング、エージェント型作業、長文脈推論、マルチモーダル理解に向けた MiniMax のフロンティアモデルです。2026年6月1日に正式リリースされ、MiniMax が本リリースの中心と位置づけた3つの能力、すなわち最大100万トークンのコンテキストウィンドウ、ネイティブな画像/動画理解、長期ホライズンのエージェント実行を組み合わせています。
オープンウェイトのモデルは総約4,280億パラメータ、アクティブ化パラメータ約230億です。これは公表されたパラメータ容量のうち、典型的なトークンで実際に動作するのは約5.4%に過ぎないことを意味し、非常に大きなモデルでも推論時に実用的である理由の一端を示します。M3 はまた、100万トークン規模のコンテキストに対応したブロックワイズのスパース注意設計である MiniMax Sparse Attention (MSA) を導入しています。
開発者向けには、M3 は MiniMax の API とオープンウェイト配布を通じて利用可能で、また、MiniMax と他プロバイダを単一インターフェースで扱いたいチーム向けに CometAPI からも利用できます。
Key Takeaways
- MiniMax は 2026年6月1日に M3 をリリース し、コーディング、エージェント、長文脈、マルチモーダルにフォーカスしたフロンティアモデルとして位置づけました。
- オープンウェイト公開では、総約4,280億パラメータ、アクティブ約230億 が開示されています。
- M3 は 最大100万トークンのコンテキスト をサポートし、API では 512K を保証された最小ティアとして説明しています。
- MiniMax Sparse Attention は、全域のグローバル注意を、ブロック選択と選択領域に対する厳密なスパース注意へ置き換えます。
- M3 は最初のステップから混合モダリティで訓練され、テキスト・画像・動画入力をサポートします。
- Official launch benchmarks には、SWE-Bench Pro 59.0%、Terminal-Bench 2.1 66.0%、BrowseComp 83.5、OSWorld-Verified 75.2 が含まれます。
- MiniMax は、自律的な論文再現で約12時間、および1,959回のツール呼び出しを伴う約24時間の CUDA カーネル最適化を実演しました。
- API は、設定可能な推論（思考）と、テキスト・画像・動画・関数ツール・標準/優先サービス階層・長文脈課金をサポートします。
What Is MiniMax M3?
MiniMax M3 は M2 世代の後継であり、通常のポイントアップデートを超える大きなアーキテクチャ上の変化を示します。MiniMax M2.7 は既に実世界のソフトウェアエンジニアリング、オフィス生産性、エージェントワークフローに焦点を当てていましたが、M3 は新しいスパース注意アーキテクチャ、ネイティブなマルチモーダル事前学習、100万トークンのコンテキスト目標を追加します。
M3 は100万トークンのコンテキストウィンドウを備えたフロンティアなマルチモーダル・コーディングモデルです。公式のオープンウェイトリポジトリは最重要のスケール数値を加えています：総約4,280億パラメータ、アクティブ約230億。関連する MSA の技術報告は、アーキテクチャが Mixture-of-Experts 設計で動作すると説明しており、総パラメータとアクティブパラメータの差分という開示と整合しています。
これは M3 を「より大きな M2.7」というよりも、収束モデルとして興味深い存在にします。リポジトリ規模のコンテキスト、コーディング、マルチモーダル知覚、コンピュータ指向エージェント、ローカル/オープンなデプロイを1つのシステムにまとめます。MiniMax は、この組み合わせをリリースの主な差別化要因として明確に位置づけており、M3 がすべてのベンチマークで勝っていると主張しているわけではありません。
MiniMax M3 Specifications
| Specification | MiniMax M3 |
|---|---|
| Release date | 2026年6月1日 |
| Model size | 総約4,280億パラメータ；アクティブ約230億 |
| Architecture | MiniMax Sparse Attention (MSA) を用いたスパース Mixture-of-Experts |
| Context window | 最大100万トークン；API で保証された最小は 512K |
| Input modalities | テキスト、画像、動画 |
| Output | テキスト |
| Reasoning control | API パラメータで思考のオン/適応/無効化が可能 |
| Maximum generation | 推奨 128K；API ドキュメントでは最大 512K の max_completion_tokens を許可 |
| Tool use | 関数ツール；エージェント指向のワークフロー |
| Weights | Hugging Face / GitHub の手順によるオープンウェイト |
上記のコンテキスト、モダリティ、API の挙動は MiniMax の公式モデル/API ドキュメントに、パラメータ数値とローカルデプロイ用リンクは公式 M3 リポジトリに記載されています。
From MiniMax M2.7 to M3
| Dimension | MiniMax M2.7 | MiniMax M3 |
|---|---|---|
| Context window | 204,800 tokens | Up to 1M tokens |
| Native image/video input | No; M2.x text/tool workflows | Yes; text + image + video |
| Attention direction | Conventional M2-series serving | MSA sparse attention |
| Thinking control | Reasoning cannot be fully disabled in M2.x | Thinking can be disabled for lower latency |
| Primary positioning | Coding, tool calling, office/agent workflows | Coding + agents + multimodality + million-token context |
| Open-weight emphasis | M2.7 open model ecosystem | M3 weights + dedicated MSA implementation |
MiniMax の API ドキュメントは M2.7 を 204,800 トークンのコンテキストティアに置く一方、M3 は 100万トークンクラスへ移行しています。より大きな違いは質的な面です：M3 は視覚・動画入力を直接受け付けますが、M2.x の API は引き続きテキストとツール中心です。
What Is New in MiniMax M3?
総4,280億規模でアクティブ約230億のモデル
公開された M3 リポジトリは、モデルが総約4,280億パラメータ、アクティブ約230億であると述べています。実務的には、開示されたアクティブ比率は約5.4%です。これはスパースなエキスパート構造の基本的な利点で、総容量は非常に大きくできる一方、特定のトークンの計算経路はモデルの一部のみを通過します。
パラメータ数だけで品質は決まりませんし、「428B」は各トークンごとに4,280億の密パラメータが評価されるという意味ではありません。より有用な解釈は、M3 が大規模なモデル容量を持ちながら、条件付きの有効化と、長文脈のコストを抑えるための注意機構を組み合わせているという点です。
MiniMax Sparse Attention: 100万コンテキストを実用化
中心的なアーキテクチャ変更は MiniMax Sparse Attention (MSA) です。完全な softmax 注意は系列長に対して二乗で増加し、エージェント履歴、コードリポジトリ、ツールログ、画像、長文書が数十万トークンに蓄積すると高コストになります。
MSA は軽量な Index Branch を追加し、キー・バリューブロックをスコアリングして各 GQA（Grouped-Query Attention）グループに対して Top-k のサブセットを選択します。その後、メインブランチが選択されたブロックに対してのみ厳密なブロックスパース注意を実行します。MiniMax の技術報告は、品質を維持しつつフル注意が処理すべきコンテキスト量を削減する、ハードウェア指向の設計であると説明しています。
図1. MiniMax Sparse Attention (MSA) のアーキテクチャ。 出典: MiniMax 公式 MSA 図
100万コンテキストにおいて、MiniMax は M3 が前世代比でトークンあたり計算を約1/20にし、M2 対比でプリフィル9倍超、デコード15倍超の高速化を提供すると報告しています。別の MSA 論文は 109B の MoE テストモデルで追加の統制実験を示しており、その論文の数値と本番の M3 対 M2 の数値は混同すべきではありません。
この区別は重要です。論文は研究設定で注意機構を検証しており、M3 のローンチ数値は本番モデルを説明しています。両者は同じ方向性を示しますが、同一のベンチマークではありません。
最初からのネイティブ・マルチモーダル
M3 は、最後に別のビジュアルアダプタを付け加えたテキストモデルとして提示されていません。MiniMax によれば、M3 は最初のステップから混合モダリティ訓練を受け、インタリーブされたマルチモーダルデータを増やすために事前学習のデータパイプラインを作り直しました。
本番 API はテキスト、画像、動画入力をサポートします。これはコーディングやエージェント作業において重要です。実際の多くのタスクはテキストだけではなく、デバッグにはスクリーンショットが必要だったり、フロントエンド作業には参照画像との比較が必要だったり、リサーチにはプロットや数式が含まれ、コンピュータ利用エージェントは視覚インターフェースを通じて動作します。
M3 のマルチモーダル性を捉える有益な見方は「画像を説明できる」ではなく、「視覚状態を、コード、ツール出力、文書、ユーザーフィードバックと同じ長時間の推論ループ内に保持できる」ということです。
対話型コーディングとエージェント訓練
MiniMax は、古典的なコーディングベンチマークは開発者の実際の作業を表すには単発すぎると主張します。M3 に対しては、要件の明確化、解法の議論、フィードバックに基づく修正、タスクの切替、複数ラウンドのプロジェクト反復にモデルを晒すための対話的ユーザーシミュレータを構築しました。
目標は、受動的な指示実行からコラボレーションへ移行することです。効果的なコーディングエージェントは、タスクを分解し、ツールを呼び出し、失敗を解釈し、計画を修正し、過去の決定を保持し、最初の尤もらしい解答の後も継続できなければなりません。M3 の長文脈とツール指向の訓練は、まさにこのループのために設計されています。
長期自律実行
MiniMax による M3 の最も説得力あるデモは、チャット例ではありません。ツールからの反復的なフィードバックの後でも状態を維持し、改善を継続しなければならない長時間のタスクです。
| Task | Autonomous runtime | Evidence of persistence | Reported result |
|---|---|---|---|
| ICLR paper reproduction | Nearly 12 hours | 18 commits; 23 experimental figures | Core experiments reproduced |
| FP8 GEMM kernel optimization | ~24 hours | 147 benchmark submissions; 1,959 tool calls | 7.6% → 71.3% peak utilization; 9.4× speedup |
| PostTrainBench model training | 12-hour task window | Data synthesis → training → evaluation → iteration | Score 0.37; behind Opus 4.7 and GPT-5.5, ahead of other models in MiniMax report |
論文再現タスクでは、M3 は約12時間稼働し、18件のコミットと23枚の実験図を生成しました。課題は論文読解、図表/数式の理解、コード記述、実験、反復的な解釈を組み合わせたものです。
.png)
図2. 約12時間にわたる M3 の自律的な論文再現の軌跡。 出典: MiniMax 公式 M3 デモ
CUDA 最適化タスクでは、M3 は約24時間で 147 回のベンチマーク提出と 1,959 回のツール呼び出しを完了し、最終的に報告された Hopper FP8 のピーク活用率を**7.6% から 71.3% に向上（9.4倍の高速化）**させました。注目点は最終的な高速化だけではなく、MiniMax によればモデルの最良解は 145 回目の提出で現れ、いくつかの停滞局面を経て到達したという点です。
Benchmark Performance of MiniMax M3
MiniMax のローンチベンチマークチャートは、コーディング、ターミナル、ブラウジング、オフィス、ツール使用、コンピュータ使用タスクにわたり、Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro と M3 を比較しています。これらは M3 の同一リリースパッケージで公開されており、最も有用な直接比較です。
図3. MiniMax の公式 M3 ローンチベンチマーク比較。 出典: MiniMax 公式ベンチマーク画像
| Benchmark | MiniMax M3 | Claude Opus 4.7 | GPT-5.5 | Gemini 3.1 Pro |
|---|---|---|---|---|
| SWE-Bench Pro | 59.0 | 64.3 | 58.6 | 54.2 |
| Terminal-Bench 2.1 | 66.0 | 66.1 | 78.2 | 70.0 |
| VIBE V2 | 50.1 | 55.8 | 50.5 | 28.0 |
| SVG-Bench | 63.7 | 62.3 | 58.2 | 59.2 |
| KernelBench Hard | 28.8 | 30.7 | 20.9 | 18.6 |
| BrowseComp | 83.5 | 79.3 | 84.4 | 85.9 |
| GDPval rubrics | 74.7 | 79.8 | 80.6 | 57.8 |
| BankerToolBench | 76.1 | 81.3 | 75.0 | 67.0 |
| MCP Atlas | 74.2 | 77.0 | 75.3 | 69.2 |
| OSWorld-Verified | 75.2 | 82.8 | 78.7 | 76.2 |
この表のスコアはすべてMiniMax の公式 M3 ローンチチャートから転記したものです。CometAPI による新たな独立再計測ではなく、ベンダー報告のローンチ結果として読むべきです。
ベンチマーク結果が実際に示すこと
第一に、M3 はソフトウェアエンジニアリングにおいて真に競争力があります。SWE-Bench Pro では 59.0 と、MiniMax が報告する GPT-5.5 の 58.6 と Gemini 3.1 Pro の 54.2 を上回る一方、Claude Opus 4.7 の 64.3 には届きません。KernelBench Hard も同様で、M3 の 28.8 は Opus 4.7 の 30.7 に近く、他の2モデルより大幅に高い値です。
第二に、ターミナル実行は M3 の相対的な強みとは言えません。Terminal-Bench 2.1 で M3 は 66.0 と、Opus 4.7 の 66.1 とほぼ同等ですが、GPT-5.5 の 78.2 や Gemini 3.1 Pro の 70.0 よりは低い結果です。
第三に、情報収集において M3 は強いものの支配的ではありません。BrowseComp は 83.5 で、Opus 4.7 の 79.3 より高い一方、GPT-5.5 の 84.4 と Gemini 3.1 Pro の 85.9 よりわずかに低いです。MCP Atlas の 74.2 も、GPT-5.5 の 75.3 や Opus 4.7 の 77.0 に近い位置です。
第四に、ローンチチャートは M3 が SVG-Bench で特に良い結果を示すとしています：63.7 は、Opus 4.7 の 62.3、GPT-5.5 の 58.2、Gemini 3.1 Pro の 59.2 を上回ります。これはより広い M3 の設計と合致しています。ネイティブな視覚理解は、個別のビジョン機能に留まらず、コーディングやエージェントワークフローに直接参加することを意図しています。
結論は「M3 がクローズドモデルに勝つ」と単純化するよりも、より微妙です。M3 は多くのエージェントタスクで同じ性能帯に入り、特定の評価で勝ち、他では負けています。その差別化要因はスコアそのものではなく、オープンウェイト、マルチモーダル訓練、100万トークンのコンテキスト設計、そして積極的なサービング経済性の組み合わせにあります。
MiniMax M3 vs Claude Opus 5 vs GPT-5.6 Sol vs Gemini 3.7 Flash
MiniMax M3 は動きの速い市場に投入され、当初の比較対象は最も有用な参照点ではなくなりました。より関連性の高い現行世代の比較は、Claude Opus 5、GPT-5.6 Sol、Gemini 3.7 Flash——いずれもコーディング、エージェント、マルチモーダル作業を狙った新しいクローズドモデルです。これらのモデルは同一ハーネスで評価されていないため、表では文書化された機能を重視し、数値は直接報告されたベンチマークに限って使用します。
| Dimension | MiniMax M3 | Claude Opus 5 | GPT-5.6 Sol | Gemini 3.7 Flash |
|---|---|---|---|---|
| Weights | Open weight | Closed | Closed | Closed / hosted API |
| Public parameter count | ~428B total / ~23B active | Not disclosed | Not disclosed | Not disclosed |
| Context window | Up to 1M | 1M | 1,050,000 | 1M |
| Input modalities | Text, image, video | Text, image, PDF | Text, image | Text, image, video, audio, PDF |
| Coding / agent focus | Coding + long-horizon agents + multimodality | Complex agentic coding + enterprise work | Frontier coding + tool-heavy professional agents | Fast agentic coding + multimodal workflows |
| Computer / tool use | Function tools + MiniMax Code + computer use | Server/client tools + computer use | Web/file search, shell, computer use, MCP | Function calling, search, computer use |
| Terminal-Bench 2.1* | 66.0 | Not reported in Opus 5 launch | 88.8 | 85.8 |
| Representative coding signal* | SWE-Bench Pro 59.0 | Frontier-Bench v0.1: SOTA in Anthropic report | DeepSWE v1.1 72.7 | DeepSWE v1.1 65.3 |
| Best reason to choose | Open weights + low cost + 1M multimodal context | Judgment + long-horizon autonomy | Raw coding/terminal performance + broad tool stack | Speed/cost + native multimodality |
これらのベンチマーク数値は各プロバイダの評価パッケージからのもので、単一の同期リーダーボードとして読むべきではありません。M3 の Terminal-Bench 2.1 における 66.0 は MiniMax のリリース評価から、OpenAI は GPT-5.6 Sol に 88.8 を、Google は Gemini 3.7 Flash に 85.8 を報告しています。Anthropic の Opus 5 ローンチは Frontier-Bench、GDPval-AA、AutomationBench、OSWorld 2.0 を強調しており、直接比較可能な Terminal-Bench 2.1 の結果は公表していません。モデル選定においては、各社のローンチ数値を恒久的な順位とみなすのではなく、自身のワークロードで単一ハーネスの下で候補をベンチマークしてください。
MiniMax M3 が最も明確な優位を持つ領域
最も明確な M3 の優位はデプロイの選択肢です。なぜ開発者がこのモデルを重視するのかは、ベンチマークチャートやパラメータ数だけでは説明できません。M3 は、通常はホスト型フロンティアシステムに紐づくコンテキスト長とマルチモーダル機能を、オープンウェイトと組み合わせます。これは、ローカルデプロイ、プロバイダの独立性、専用サービング、推論スタックを深く制御したいチームにとって魅力的です。
第二の優位は長文脈のコストアーキテクチャです。MSA は、100万トークン規模で注意計算が爆発しないように明示的に設計されています。これは絶対的に 100 万トークンのリクエストが安価になることを意味しません——KV キャッシュ、エキスパート実行、マルチモーダル入力には依然として計算資源が必要です——しかし、フル注意と比べたときのスケーリング曲線を変えます。
クローズドモデルが依然としてリードする領域
同じ公式ベンチマークチャートは、M3 があらゆるクローズドフロンティアモデルの完全な代替とは言えない理由も示します。MiniMax の比較では、Claude Opus 4.7 は SWE-Bench Pro、KernelBench Hard、GDPval、BankerToolBench、MCP Atlas、OSWorld-Verified で強い結果です。GPT-5.5 は Terminal-Bench 2.1 で大きくリードし、GDPval でも先行します。Gemini 3.1 Pro は BrowseComp で僅差のリードです。
本番チームにとって、クローズドプラットフォームは、成熟したセーフティコントロール、ホスト型ツール、オブザーバビリティ、スループット保証、統合といった点で、オープンウェイト以上に重要な場合もあります。M3 が最も魅力的なのは、ベンチマーク順位が唯一の基準ではなく、デプロイとコスト上の利点が要件に含まれる場合です。
MiniMax M3 API Pricing
MiniMax は現在、2つの標準的なコンテキスト単価ティアを採用しています。公式の料金ページには、入力トークンが 512K 以下のリクエストに対し、$0.30/M（入力）と $1.20/M（出力）の「恒久的な50%オフ」レートが表示されています。512K を超えるリクエストは、$0.60/M（入力）と $2.40/M（出力） と表示されています。プライオリティサービスは標準ティアの 1.5 倍の価格です。
| Route / tier | Input price per 1M tokens | Output price per 1M tokens | Context note |
|---|---|---|---|
| MiniMax official Standard (current discounted rate) | $0.30 | $1.20 | ≤512K input |
| MiniMax official Standard long-context | $0.60 | $2.40 | >512K input |
| MiniMax official Priority (discounted rate) | $0.45 | $1.80 | ≤512K input; priority admission |
| CometAPI MiniMax-M3 page | $0.48 | $1.92 | Unified gateway pricing shown by CometAPI |
*CometAPI の MiniMax-M3 は入力 $0.48/M、出力 $1.92/M で、MiniMax の非割引の定価 $0.60/$2.40 と比較を示しています。MiniMax 自身のプラットフォームでは現在、別途 50% オフの標準レートが表示されているため、開発者は見出しの割引率だけでなく、実際に課金されるライブレートを比較すべきです。
この状況で CometAPI を利用する理由は、必ずしも常に最安のプロモーション価格というわけではありません。価値は、M3 と他プロバイダ間をルーティングする必要があるアプリケーションに対し、単一の API と課金レイヤーを提供する点にあります。
What Can MiniMax M3 Do?
コーディングとリポジトリ規模のエンジニアリング
M3 の最も明確なユースケースは、大規模リポジトリにまたがるソフトウェアエンジニアリングです。100万トークンのコンテキストは、M2 世代の 204.8K ウィンドウに比べ、はるかに多くのコード、ドキュメント、テスト出力、課題履歴、エージェント状態を保持できます。実務では、多ファイル機能実装、リポジトリ全体のリファクタリング、バグ診断、テスト修復、ビルド/ターミナルループ、プルリクレビュー、性能最適化といったワークフローが可能になります。
鍵は持続性です。リポジトリ規模のコーディングエージェントは、ツール出力と修正を蓄積しつつ、元の要件を保持できる場合にのみ有用です。12時間と CUDA のデモは、M3 が中間的な失敗の後でも作業を継続するよう設計されていることを示しています。各ツール呼び出しを個別の短いタスクとして扱うのではありません。
自律的なリサーチと実験
論文再現の例は、リサーチエージェントの良いテンプレートです。M3 は論文を読み、図を検査し、数式を推論し、コードを生成し、実験を実行し、結果が期待に合致するか評価し、実装を継続的に洗練できます。論文本文、コード、実験ログを1つの長いコンテキストに保持できるため、状態を要約したり外部で再構成したりする必要が減ります。
これが PostTrainBench の関連性でもあります。MiniMax は、M3 に学習データの合成、ベースモデルの訓練、評価、人手介入なしの反復を求めました。M3 は 1 位ではありませんでした（MiniMax の報告では Opus 4.7 と GPT-5.5 に続く順位）が、この実験は通常の QA を超えた、より複雑な研究自動化を示しています。
マルチモーダルな技術分析
M3 はネイティブに画像と動画を受け付けるため、テクニカルなワークフローで視覚的証拠をテキストやコードと組み合わせられます。例として、フロントエンド実装とスクリーンショットの比較、研究論文内のプロットの分析、コンピュータ利用中の UI 状態の検査、図からの情報抽出、長い保守ログと動画観測の組み合わせなどが挙げられます。
MiniMax の OpenAI 互換 API ドキュメントは、M3 向けに image_url と video_url のコンテンツパーツを明示的にサポートしており、より大きな動画のアップロードにも対応します。これにより、マルチモーダル入力は製品デモだけでなく、開発者向け API の一機能となります。
コンピュータおよびオフィス業務の自動化
MiniMax Code は、M3 を中核にしたエージェントハーネスとして設計されています。同社は、Agent Team が複雑なタスクを段階的かつ並行ワークフローに分割し、反省と訂正のために Producer + Verifier ループを使えると述べています。M3 のネイティブなマルチモーダル性は、アプリケーション、ファイル、スプレッドシート、デスクトップインターフェースを横断するコンピュータ利用のワークフローも可能にします。
公式の一例は、ローカルの ERP クライアントを開き、Excel スプレッドシートから請求書情報を一括入力する指示です。重要な能力はアプリケーション間の状態管理です。エージェントはスプレッドシートを理解し、インターフェースを操作し、項目間のマッピングを保持し、UI の変更や操作失敗があっても復旧する必要があります。
長文脈の文書および知識業務
100万のコンテキストウィンドウはコード以外にも有用です。契約、ポリシー、技術仕様、研究論文、インシデント報告、顧客記録といった大規模なコレクションを単一の作業コンテキストに収められます。利点は単に「ページ数が多い」ことではなく、長いエージェント履歴を保持しながら遠く離れた証拠をまたいで推論できることです。
ただし実務上の注意点もあります。最大コンテキスト容量は、あらゆる位置での完全な想起を保証するわけではなく、非常に大きなプロンプトはレイテンシとコストを増やします。長文脈は、信頼性を高める場合には、検索、キャッシング、構造化メモリ、タスク分割などと組み合わせるべきです。
Final Verdict: Is MiniMax M3 a Frontier Model?
はい——ただし、その根拠は M3 がすべてのチャートで首位ということではありません。そうではありません。
MiniMax M3 が変えるのはトレードオフです。オープンウェイト、100万トークンのスパース注意設計、ネイティブなテキスト・画像・動画訓練、長期ホライズンのエージェント挙動、そして元の比較対象であるクローズド旗艦モデルよりもはるかに低いトークン単価の API を提供しつつ、ローンチ時点のフロンティア性能で十分に競合します。
SEO情報
Suggested URL: /blog/minimax-m3-specs-benchmarks-pricing
Description: MiniMax M3 の仕様、100万トークンコンテキスト、スパース注意、マルチモーダル機能、ベンチマーク、API 料金、ユースケース、モデル比較を解説。
Keywords: MiniMax M3, MiniMax M3 仕様, MiniMax M3 ベンチマーク, MiniMax M3 API 料金, MiniMax Sparse Attention, 100万トークンのコンテキストウィンドウ, マルチモーダルコーディングモデル, オープンウェイト AI モデル, 長期ホライズン AI エージェント, MiniMax M3 vs GPT-5.5