GLM-5.2・DeepSeek V4・MiniMax M3・Kimi K2.6 を 1 つの API でルーティングする（2026年）

TL;DR — GLM-5.2、DeepSeek V4（Pro と Flash）、MiniMax M3、Kimi K2.6 を 1 つの ofox API キーの背後に置き、すべてのジョブに 1 モデルの価格を払うのではなく、タスクごとにルーティングします。input と output が 2:1 のミックスでのブレンド単価は $0.19/M（V4 Flash）から $2.40/M（GLM-5.2） までで、12.86倍の差です。以下の 1,000 ジョブ/日のルーティング試算では、全 GLM-5.2 だと月 $4,205 の請求が $1,453（-65.5%） まで下がります。ルーティングルールは短く、バジェット／バッチ → V4 Flash、長 context（最大 1M トークン）→ V4 Pro か GLM-5.2、推論／コード → GLM-5.2 か Kimi K2.6、画像 → MiniMax M3 か Kimi K2.6。4 モデルとも同じ OpenAI 互換 endpoint 上にあるので、ルーティングは文字列 1 つの変更——Python と Node のループ付きです。

チームがよくやる失敗は、1 モデルを選んですべてをそれに通すことです。バッチの要約ジョブと難しい推論タスクが、同じトークン単価に値するわけがありません。4 モデルすべてを 1 つのキーで使えるなら、最安ティアは最も高性能なものより 12.86倍安く 動きます——だからゲームの全体は、各ジョブクラスを、品質基準をクリアできる最安のモデルに割り当てることに尽きます。

これは「どのルーターが最強か」のまとめ記事ではなく、再現可能なコスト試算付きのハウツーです。以下の数字はすべて 2026年6月23日に確認した ofox の掲載トークン単価に基づいており、各表はスペック表から再計算できます。

TL;DR：どのジョブにどのモデルか

一言での結論：バッチトラフィックは既定で最安ティアに流し、必要なジョブだけエスカレーションする。 タスクの形ごとのルーティングマップはこちらです。

2026年のほとんどのチームにとっての正直な既定値はこうです。トラフィックの大部分を deepseek/deepseek-v4-flash か deepseek/deepseek-v4-pro に送り、本当に難しい推論だけ z-ai/glm-5.2 にエスカレーションし、画像が絡むものはすべて minimax/minimax-m3 に送る。これで、ベンダー移行なしに、混在ワークロードの現実的な 90% を 1 つのキーでカバーできます。

クイックスペック比較

2026年6月23日に ofox の /v1/models カタログと照合して確認しました。価格は 100 万トークンあたりです。

以下のルーティング判断すべてを動かす構造的な事実が 3 つあります。

1. DeepSeek V4 Flash が価格の底値。 $0.14/$0.28 で、GLM-5.2 よりブレンドで 12.86倍安い。トップティアの推論を必要としないものは、すべてここから始めます。
2. DeepSeek V4 の cache 読み取りは実質無料。 V4 の両ティアとも cache 読み取りをゼロに丸まるレートで課金します（GLM-5.2 は $0.26/M）。context を繰り返すワークロードでは、これは大きく、しばしば見落とされる節約です。
3. 画像を受けるのは MiniMax M3 と Kimi K2.6 だけ。 GLM-5.2 と DeepSeek の両ティアはテキスト専用です。ビジョンタスクの有効なルートはちょうど 2 つしかなく、MiniMax M3 がそのうち安いほうです。

ブレンド単価：ルーティングを動かす数字

モデルの表向きの input 価格は話の半分でしかありません。実際に払う額は input と output の比率で決まります。コーディングエージェントは大量に読み（大きな context）、少しだけ書く（diff）——おおむね input:output が 2:1 です。チャットは 1:1 に近く、短いプロンプトからの純粋なコード生成は output 重めで、1:3 あたりになります。

コーディングに典型的な 2:1 ミックス（input が 3 分の 2、output が 3 分の 1）でのブレンド単価（100 万トークンあたり）と、推論ティアのアンカーとして GLM-5.2 に対する倍率はこちらです。

Pull quote： このリストで最安のモデルは、最も高性能なものより 12.86倍安い。その差こそがルーティングの経済的な論拠のすべてだ——どのモデルが「勝つ」かではなく、誰にも気づかれずに安いティアに乗せられるジョブはどれか、である。

順位はワークロードの形で少し動きます。output 重めの 1:3（コード生成）では、GLM-5.2 は $3.65/M、Kimi K2.6 は $3.24/M まで上がり、V4 Flash は $0.245/M にとどまります。output 重めの作業が DeepSeek ティアにさらに強く傾くのは、その output トークンが 5 モデル中最安だからです。1 つだけルールを覚えるなら、ジョブが書く量が多いほど、GLM-5.2 と Kimi K2.6 から外してルーティングする価値が増すということです。

推計をやめて自分のトラフィックでこれらの数字を測りたいなら、5 モデルすべてを 1 つの ofox キーでルーティングしてください——従量課金、月額料金なし、OpenAI SDK と同じ形で、本記事末尾の A/B ループは文字列 1 行の変更でモデルを入れ替えます。

タスクごとのコスト：エージェント 1 回の実行が各モデルでいくらか

ルーティングの判断は、100 万トークンあたりのレートより、1 回あたりのドルで感じるほうが分かりやすいものです。代表的なエージェントの実行を取ります：input 50,000 トークン、output 15,000 トークン（コードベースの一部を読み、変更を生成する）。

そうした実行を月 10,000 回行うと、同じ作業に対して V4 Flash なら $112、GLM-5.2 なら $1,360 です。その実行の半分でもバジェットティアで十分なルーティンなら、ルーティングの判断は何倍にもなって元を取ります。要点は V4 Flash が常に正しいということではなく——V4 Flash で処理できるジョブに GLM-5.2 の価格を払うのは純粋な無駄だということです。

ルーティング判断マトリクス（試算例）

「ルーターを使え」系の記事の多くが飛ばす部分はここです。実際の日次の試算です。次の現実的な分布で 1 日 1,000 ジョブが混在 すると仮定します。

すべてを GLM-5.2 で回す場合（1 モデルの罠）と、各クラスをコストに見合ったモデルにルーティングする場合の比較です。

ルーティング後の合計の内訳です。

バッチジョブ 600 件——ボリュームの 60%——は V4 Flash で 1 日 $1.18 です。同じ 600 件を GLM-5.2 で回すと 1 日約 $13.68 で、おおよそ 11.6倍になります。この 1 つのルーティングルール（安いバッチ → V4 Flash）が作業の大半をこなします。実際にドルが集中するのは長 context クラスで、だからこそ次のセクションが重要になります。

flowchart TD
    A[受信リクエスト] --> B{画像 input が必要か？}
    B -->|はい| C[minimax/minimax-m3]
    B -->|いいえ| D{難しい推論<br/>またはエージェント型コーディングか？}
    D -->|はい| E[z-ai/glm-5.2]
    D -->|いいえ| F{context > 200K<br/>トークンか？}
    F -->|はい| G[deepseek/deepseek-v4-pro<br/>cache 読み取り無料、1M ctx]
    F -->|いいえ| H[deepseek/deepseek-v4-flash<br/>最安ティア]

cache 読み取り：DeepSeek V4 の静かなコスト優位

上の長 context クラスこそ、caching が計算を変える場所です。DeepSeek V4 Pro と Flash は cache 読み取りを実質 $0/M で課金します。GLM-5.2 は $0.26/M、MiniMax M3 は $0.12/M、Kimi K2.6 は $0.16/M です。

ルーティング表の 300K input の長 context ジョブを取り（1 回あたりのコストには output 8K を含む）、input の 80% が cache から提供される場合（リクエストをまたいで同じコードベースの context が繰り返されるコードレビューのループでは現実的）を見ます。

V4 Pro は出発点が安く、節約できる割合も大きい——cache 読み取りがゼロに丸まる一方、GLM-5.2 は cache された分にも依然 $0.26/M を払うからです。同じ長 context を再送するワークロード——固定コーパスへの RAG、反復的なコードレビュー、ドキュメント Q&A——はすべて DeepSeek V4 Pro にルーティングすれば、無料の cache 読み取りが積み重なります。 これは、GLM-5.2 の強い推論力が常に上書きを正当化するとは限らない、ルーティングの入力です。

推論ティアを分ける：GLM-5.2 vs Kimi K2.6

ルーティングマトリクスは「難しい推論／エージェント型コーディング」を GLM-5.2 か Kimi K2.6 に送りますが、この「か」はコイン投げではなくルールに値します。両方ともこのラインナップの高い側——GLM-5.2 が $1.40/$4.40、Kimi K2.6 が $0.95/$4.00——で、2:1 ミックスでは input レートが低い分、実は Kimi K2.6 のほうがわずかに安くブレンドされます（$1.97/M vs $2.40/M）。ルートを決める具体的な要因が 3 つあります。

実用的なルール：推論ジョブが大きな context（>256K トークン）を抱えるなら、2 つのうち収まるのは GLM-5.2 だけ——Kimi K2.6 は input を弾きます。 context が余裕で 256K 未満で、ジョブが画像を含むか、より安いトークン単価が欲しいなら、Kimi K2.6 のほうが良いルートです。短い context のエージェント型コーディングのターンの多くでは、Kimi K2.6 の低い input 価格が推論ティア内でのバリュー選択になり、GLM-5.2 は、その 1M ウィンドウだけが収められる長 context の推論に取っておきます。Kimi K2.6 リリースガイド では、そのエージェント挙動をさらに掘り下げています。

これこそ、クライアント側ルーティングが 1 モデル固定に勝つ理由です。「最強の推論モデル」は推論ジョブの 形 次第で変わり、model 文字列はその間を切り替える、考えうる最も安いスイッチなのです。

レイテンシとスループットもルーティングの入力

コストは最も大きなルーティングシグナルですが、唯一のものではありません。実際のルーティング判断を変える運用上のメモが 2 つあります。

• インタラクティブ vs バッチ。 first-token のレイテンシが体感されるユーザー向けアシスタントでは、最安のモデルが自動的に正解ではありません——少し高くても速く返すモデルが、インタラクティブな面では価値があり得ます。一方、夜間バッチジョブは速度に関係なく最安ティアに乗せるべきです。価格だけでなく面でルーティングしましょう。インタラクティブなトラフィックは高いトークン単価を許容でき、バッチトラフィックは許容しません。
• output 上限という硬い制約。 単一の応答が 128,000 トークンを超えなければならない場合——ファイル全体の書き換え、大きな構造化エクスポート——GLM-5.2 と MiniMax M3 は上限に達して呼び出しが切り詰められます。1 回の呼び出しでその基準をクリアするのは DeepSeek V4 ティア（384K）と Kimi K2.6（262K）だけです。これはコストのトレードオフではなくバイナリのルーティングゲートで、超大出力のジョブは物理的にトークンを吐けるモデルに送ります。

どちらも、pick_model 関数が単純な条件分岐としてエンコードできる判断です——面の種類と期待される出力サイズは、たいていリクエスト時点で分かっています。

ルーティングすべきでないとき（と、代わりに使うもの）

ルーティングはタダのエンジニアリングではありません。マルチモデルの分割が誤りになる 3 つのケースです。

• 単独の開発者、1 日 1,000 呼び出し未満、タスク種類が 1 つ。 ルーティングのロジックとモデルごとの品質テストは、節約できる時間より多くの時間を食います。強くて安い既定として deepseek/deepseek-v4-pro を選んで先に進みましょう。ブレンド $0.59/M はすでに十分低く、分岐コードでマイクロ最適化する価値はありません。
• 本当にサーバー側の自動融合が必要。 ofox は あなたの model フィールドでルーティングします——モデルを自動で選んだり、出力を融合したりはしません。品質ベースの自動選択や応答の融合（OpenRouter Auto / Sakana 風の発想）が具体的に欲しいなら、それは別の製品カテゴリです。そうしたツールを使うか、自動ルーターが予測不能さに見合うか決める前に、OpenRouter は信頼できるかの正直なレビュー を読んでください。
• すべてのジョブが本当にトップティアの推論を必要とする。 トラフィックが 100% 難しいエージェント型コーディングで、バジェットティアの作業がないなら、ルーティングするものは何もありません——GLM-5.2（か Kimi K2.6）を回してマトリクスは飛ばしましょう。ルーティングが効くのはワークロードが 混在 しているときだけです。純粋な 2 モデルの推論分割については、Claude Code ハイブリッドルーティングパターン がその狭いケースを扱っています。

ルーティングの見返りは、トラフィックがどれだけ不均質かに比例します。均質なトラフィック → 1 モデル。混在トラフィック → 上のマトリクス。

ofox で試す：5 モデルを 1 つのループでルーティング

5 モデルとも https://api.ofox.ai/v1 と 1 つの ofox キーを共有します。ルーティングはクライアント側の判断で、リクエストごとに model フィールドを設定します。ルーティング関数と A/B ループを、Python と Node の両方で示します。

Python — タスクでルーティングし、候補を A/B

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="<OFOXAI_API_KEY>")

def pick_model(task):
    if task["has_image"]:         return "minimax/minimax-m3"        # only M3/Kimi take images
    if task["hard_reasoning"]:                                       # split the reasoning tier
        return "z-ai/glm-5.2" if task["context"] > 256_000 else "moonshotai/kimi-k2.6"
    if task["context"] > 200_000: return "deepseek/deepseek-v4-pro"  # free cache reads, 1M ctx
    return "deepseek/deepseek-v4-flash"                              # cheapest tier

def run(task, messages):
    model = pick_model(task)
    return client.chat.completions.create(model=model, messages=messages)

自分のトラフィックで候補を比較するには、固定したプロンプトでモデル ID を回します——文字列を入れ替え、それ以外はすべて一定に保ちます。

CANDIDATES = ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro", "z-ai/glm-5.2"]
for model in CANDIDATES:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Refactor this function for readability: ..."}],
    )
    u = r.usage
    print(model, u.prompt_tokens, u.completion_tokens)  # log tokens to price each route

Node — 同じ形

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOXAI_API_KEY });

const pickModel = (t) =>
  t.hasImage        ? "minimax/minimax-m3"
  : t.hardReasoning ? (t.context > 256000 ? "z-ai/glm-5.2" : "moonshotai/kimi-k2.6")
  : t.context > 200000 ? "deepseek/deepseek-v4-pro"
  : "deepseek/deepseek-v4-flash";

const r = await client.chat.completions.create({
  model: pickModel(task),
  messages: [{ role: "user", content: "Summarize this changelog: ..." }],
});

マルチモーダルのみ：MiniMax M3 か Kimi K2.6 にスクリーンショットを添付

GLM-5.2 と DeepSeek の両ティアはテキスト専用で、下の呼び出しはそれらでは物理的に失敗します。画像 input は minimax/minimax-m3 か moonshotai/kimi-k2.6 にルーティングします。

import base64

img = base64.b64encode(open("screenshot.png", "rb").read()).decode()
r = client.chat.completions.create(
    model="minimax/minimax-m3",   # or moonshotai/kimi-k2.6
    messages=[{"role": "user", "content": [
        {"type": "text", "text": "What error is shown in this screenshot?"},
        {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{img}"}},
    ]}],
)

ルーターはこれで全部です。pick_model 関数と 1 つの OpenAI クライアント。新しい SDK も、モデルごとの API キーも不要で、請求ラインは 1 つです。各モデルの詳細ページは表内にリンクしています——z-ai/glm-5.2、deepseek/deepseek-v4-pro、deepseek/deepseek-v4-flash、minimax/minimax-m3、moonshotai/kimi-k2.6。

代替手段

単一キーのクライアント側ルーターがワークロードに合うなら、ofox が最もシンプルな道です。1 つの OpenAI 互換 endpoint、1 つの残高、5 つのモデル ID すべて。それ以外の形については：

• ofox — 1 つのキー、100 以上のモデル、OpenAI 互換。ルーティングは model フィールドであなたが制御し、課金と endpoint は統一されます。自分で書く、コスト予測可能で決定論的なルーティングが欲しいときに最適です。マークアップと信頼性での比較は OpenRouter 代替の徹底比較 を参照してください。
• OpenRouter — 大きなカタログに、モデルを自動で選ぶ任意の Auto サーバー側ルーターを備えます。自動選択を具体的に欲しく、予測しにくいルーティングとプラットフォームのマークアップを許容できるなら有用です。
• プロバイダー直 API — DeepSeek、Zhipu（GLM）、MiniMax、Moonshot をそれぞれ直接呼べば最も生の価格が得られますが、4 つのキー、4 つの SDK、4 つの請求ラインを照合することになります。単一プロバイダーの非常に高いボリュームでのみ見合います。
• セルフホスト — GLM と DeepSeek はオープンウェイトを公開しているので、エアギャップやフォーク必須のデプロイが可能です。経済性が成り立つのは規模が出てからです。ホスト版のトークン単価に対する損益分岐の計算は GLM-5.2 セルフホストのハードウェアコスト分析 を参照してください。

モデルごとのより深い文脈については、GLM-5.2 アクセスガイド、GLM-5.2 vs GPT-5.5 コスト比較、DeepSeek V4 Pro vs Flash 比較、DeepSeek V4 リリースガイド、MiniMax M3 vs GPT-5.5 コーディングベンチマーク が、それぞれこのルーティング概観より 1 段深く掘り下げています。

FAQ

上部の frontmatter FAQ ブロックが、最もよくあるルーティングの質問に答えています（1 キーでのルーティング、最安モデル、最長 context、ビジョン対応モデル、実際の節約、無料 cache 読み取り、サーバー側自動ルーターがないこと、最大 output、A/B のやり方）。これらの回答は本記事の表を反映しており、コストの数字・model ID・ルーティングルールは全体で一貫しています。

今回の確認で参照したソース

• ofox /v1/models ライブ API カタログ — 5 つの model ID、context window、最大 output、トークン単価（input / output / cache 読み取り）を 2026-06-23 に確認
• ofox llms-full.txt — OpenAI 互換の base_url https://api.ofox.ai/v1 と、モデル横断の単一キーを確認（2026-06-23）
• ofox のモデル詳細ページ（z-ai/glm-5.2、deepseek/deepseek-v4-pro、deepseek/deepseek-v4-flash、minimax/minimax-m3、moonshotai/kimi-k2.6）— すべて HTTP 200 を返した（2026-06-23）
• OpenAI Python SDK（PyPI の openai 2.43.0）と OpenAI Node SDK — コード例で使った SDK の形（2026-06-23）
• すべてのコスト表は、クイックスペック表のトークン単価から再計算可能