Kimi K2.7 Code vs GLM-5.2：エージェント1実行あたり本当に安いのか（2026）

TL;DR. トークン単価では、Kimi K2.7 Code（moonshotai/kimi-k2.7-code）は GLM-5.2（z-ai/glm-5.2）より全軸で安い。ofox.ai では 入力 $0.95 vs $1.40、出力 $4.00 vs $4.40、キャッシュ読み取り $0.19 vs $0.26 だ。しかし「トークン単価が安い」と「エージェント1実行あたり安い」は同じ数字ではない。典型的な実行（入力50K、出力20K、キャッシュなし）では Kimi が $0.1275、GLM が $0.1580 で、19.3%安い。この差はキャッシュヒットが上がると縮み、各モデルがタスク完了までに実際に燃やすトークン数にも依存する。どちらもオープンウェイトで、ofox.ai 上では文字列を1つ差し替えるだけの距離にある。

表示価格は Kimi の勝ちだと言う。だが請求書はもっと複雑だ。実行コストは単価 × 消費トークン数であり、この積の後半はワークロード固有だからだ。この記事では検証済みの価格、1実行あたりの計算例、そして誠実な境界線を示す。どこまで答えを計算でき、どこからは自分のトラフィックで測らなければならないのか。

TL;DR：どちらを選ぶべきか

誠実な結論。256K コンテキストに収まるコーディングエージェント実行では、コスト重視のデフォルトを moonshotai/kimi-k2.7-code にルーティングする。1回の呼び出しで本当に 1M ウィンドウが必要なジョブには z-ai/glm-5.2 を残す。トークン単価の差はどこでも Kimi 有利。1実行あたりの差も現実的なほとんどの比率で Kimi 有利だが、キャッシュとともに縮む。上の使い分けが、実際にお金が動く境界だ。

主要スペック比較

価格は ofox.ai ゲートウェイのレートで、100万トークンあたりの USD、2026年7月16日にモデルカタログから読み取った値だ。スペックは Hugging Face のモデルカードによる。

計算に入る前にこの表から拾っておくことが2つある。Kimi は課金される3軸すべてで安いので、どんなワークロードでもトークン単価は Kimi の方が安く済む。そしてコンテキストウィンドウは接戦ではない。GLM-5.2 の 1M は Kimi の 256K のおよそ4倍で、この1つのスペックこそ、1実行あたりの答えが単純に「常に Kimi」にならない主因だ。256K を超えるプロンプトは Kimi ではチャンク分割して再送するしかなく、入力トークンの再送はまさに Kimi の割引が効く場所なので、十分に大きな単一コンテキストのジョブは差を GLM 側へ引き戻せる。

ofox で提供されるのは Kimi のテキスト専用 Code バリアントのみなので、これはコードとテキストの比較であり、マルチモーダルの比較ではない。エージェントがスクリーンショットや図を添付する必要があるなら、この2つのどちらも、その工程の担当モデルではない。

トークン単価 vs 1実行あたり：多くの人がつまずく区別

間違いは、価格表を実行比較として読むことだ。実行コストは次の式になる。

run_cost = (input_tokens × input_price)
         + (cached_input_tokens × cache_price)
         + (output_tokens × output_price)

価格は固定で検証済みだ。トークン数は固定ではない。トークン数はプロンプトのサイズ、入力のどれだけがキャッシュにヒットするか、モデルがジョブを終えるために何個の出力トークンを吐くかに依存する。Kimi は各項の価格の半分で勝つ。トークンの半分こそ、「安い」モデルでも特定の実行で負け得る場所だ。そこに至るまでに多くのトークンを燃やせばそうなる。

軸ごとの様子は次の通りで、これは Kimi がどこまで勝てるかの上限になる。

不均衡に注目してほしい。Kimi の最大の強みは入力（32%安い）とキャッシュ（27%安い）にある。出力ではわずか9%安いだけだ。だから実行の形が、その強みをどれだけ実際に回収できるかを決める。入力の多い実行は大きな割引を回収する。出力の多い実行は小さな割引を回収する。そしてキャッシュは、直感に反して Kimi の相対優位を削る方向に働く。キャッシュされた入力トークンは $0.95 ではなく $0.19 で済むため、Kimi が32%先行していたまさにその項目を縮めてしまうからだ。

計算例：典型的なエージェント実行

具体的なエージェント実行を1つ取り、両方の請求を計算しよう。以下の形は妥当な単一タスクのコーディング実行だ。コンテキストの一部を読み、推論し、パッチを吐く。

両モデルで固定する実行はこうだ。

• 入力50,000トークン（数ファイル分のコンテキストと指示）
• 出力20,000トークン（推論と吐き出す diff）
• キャッシュは後述で別扱い、まずはキャッシュなしから

同一タスク完了までに各モデルが何トークン消費するかの一次ベンチマークを私は持っていないので、両モデルでトークン数を等しく固定し、価格だけを変える。これで価格効果をきれいに分離できる。またこれは「両モデルが同じトークンを吐くなら、どちらが安いか」に答えるのであって、「どちらが少ないトークンでタスクを終えるか」には答えない。後者の問いには計測が必要で、末尾で明示的にフラグを立てる。

1実行 $0.03 だと絶対値は些細に見える。ボリュームが乗ると些細でなくなる。この形で1日1,000実行を叩き続ける単一コーディングエージェントを考える。

1つのワークロードの形、文字列を1つ変えるルーティング変更で、月900ドル。これがコスト重視トラフィックを Kimi にデフォルト化する根拠だ。

キャッシュの影響：キャッシュが上がると差が縮む

コードレビューエージェントやマルチターンセッションは、呼び出しごとに同じリポジトリコンテキストを再送するので、入力の大部分がキャッシュにヒットする。両モデルともキャッシュ読み取りはフル入力レートより安く課金する。以下は同じ入力50K／出力20Kの実行を、キャッシュヒット率を上げながら見たものだ。

Kimi はどの地点でも安いままだが、差はキャッシュが上がると19.3%から13.6%へ下がる。理由は構造的だ。Kimi の最大の割引はフルプライス入力にある（32%安い）。キャッシュはフルプライス入力をキャッシュ価格の入力に変換し、そこでは Kimi は27%しか安くなく、しかも入力項目全体をゼロに向けて縮める。残るのは主に出力で、そこでの Kimi の強みは薄い9%だ。つまりキャッシュするほど実行コストは出力に支配され、Kimi の入力優位の効きが弱まる。

実務的な読み。ワークロードがキャッシュヒットの高いコードレビューループなら、両モデルは近く、決め手は1実行あたりの価格より、出力品質か 256K vs 1M のコンテキスト上限になりやすい。ワークロードがキャッシュの低い、新規コンテキストの生成なら、Kimi の割引はフルの19%に近づく。

比率感度：入力対出力の形で比率がどう動くか

キャッシュはレバーの1つ。もう1つは、キャッシュとは独立した生の入力対出力比だ。3つの一般的なワークロード形でトークン単価をブレンドすると、Kimi の優位は予測可能な方向に動く。

傾向はキャッシュの傾向の鏡像だ。入力の多い実行は Kimi の分厚い32%入力割引を回収するので、優位は20%へ広がる。出力の多い実行は薄い9%出力割引に頼るので、優位は11%へ狭まる。Kimi はどの形でも安いが、大きなファイルを読んで2行の答えを吐く要約エージェントは、短いプロンプトを読んで大きなファイルを吐くスキャフォールディングエージェントより、比率的により多く節約する。

2つのレバーを合わせると絵はこうだ。Kimi の1実行あたりの優位は、入力主体・低キャッシュの実行で最大、出力主体・高キャッシュの実行で最小になる。どちらの組み合わせも順位を覆さない。どちらも勝ちの大きさを、おおよそ11%から20%の間で動かすだけだ。

請求のスケーリング：比率がボリュームでいくらになるか

1実行あたりの差はセント単位だ。それがルーティング判断に値するのは、エージェント群が1ジョブでは動かないからだ。以下は典型的な入力50K／出力20Kの実行を、キャッシュなしで3つのボリューム帯にスケールしたものだ。自分の支出がどこに位置するか探せる。

19.3%の差はどの帯でも保たれる。これはボリュームではなく実行の形の性質だからだ。スケールするのは絶対支出だけだ。1日1,000実行では節約がモニタリングツール代を賄う。1日10万実行では小さなチームを賄う。あなたの群がこの表のどこに座るかが、モデル選択が丸め誤差でなくなる地点だ。

トークン消費というワイルドカード（私が測れないもの）

上記のすべては両モデル間でトークン数を等しく固定している。これは意図的な単純化であり、この比較全体の要となる但し書きだ。

実行コストは単価 × トークン数だ。価格は検証した。トークンは測っていない。この2モデルが同一エージェントタスクを完了するのに入力・思考・出力の各トークンを何個消費するかについて、公開された一次ベンチマークが存在しないからだ。再現可能なハーネスなしに「Kimi は15%少ないトークンで終わる」といった数字を提示してくる者は、当て推量をしている。

なぜ重要かを、ベンチマークとしてではなく損益分岐点として示す。

入力50Kの実行で、GLM-5.2 は合計 $0.1580 かかる。Kimi の50Kの入力は $0.0475 で、GLM に並ぶまでに $0.1105 の予算が残る。出力 $4.00/M では、この予算で約 27,600 出力トークン が買える。つまり Kimi は GLM の20,000より約 1.38倍多い出力 を吐いても、同額かそれ以下で済む。

逆に言えば、GLM-5.2 が特定のタスクを Kimi より有意に少ない出力トークンで終える傾向があるなら、その高いトークン単価はそのタスクで一部または全部相殺され得る。モデルが異なるトークン数を吐くことを許した瞬間、トークン単価の勝者が自動的に1実行あたりの勝者になるわけではない。この実行の形では、価格優位が逆転するまでに Kimi には約38%の余裕があり、それは快適なバッファだが、バッファであって無限ではない。

出力の数字の内側にもう1つのしわがある。両モデルは思考トークンを吐き、思考トークンは出力として課金される。Kimi K2.7 Code は思考モデルであり、Moonshot はこの世代で前世代比の思考トークン量の削減を文書化している。それ自体が独立したコストの話で、トークン削減の分析 で扱っている。クロスモデル比較においては、「出力トークン」の行が可視の回答だけではなく、回答と推論の合計であり、その内訳がモデルとタスクの難易度で異なることを意味する。同じ答えに至るのに多く推論するモデルは、出力単価が低くても出力で多く払う。これも、方程式のトークン消費の半分は仮定ではなく計測しなければならないもう1つの理由だ。

このギャップを埋める唯一の誠実な方法は、両モデルを自分の実タスクで走らせ、各レスポンスから resp.usage を読むことだ。下の A/B ループがまさにそれを出力する。

判断フロー：どの実行にどのモデルか

flowchart TD
    A[新しいエージェント実行] --> B{入力が256Kトークン超か?}
    B -->|はい| C[GLM-5.2: 1Mウィンドウが必要]
    B -->|いいえ| D{実測トークン差がGLM有利か?}
    D -->|はい| E[GLM-5.2: 少ない出力トークンで価格を相殺]
    D -->|いいえ、または未計測| F{ビジョン/マルチモーダルが必要か?}
    F -->|はい| G[この2つでなくビジョンモデルへルーティング]
    F -->|いいえ| H[Kimi K2.7 Code: 256K以内なら1実行あたり安い]

このフローは議論全体を符号化している。まずコンテキスト上限、次に実測トークン挙動、その次にモダリティ、そしてそこを抜けたすべてに対してコストのデフォルトとしての Kimi。多くのチームが飛ばす分岐は真ん中のものだ。A/B を回さず、GLM が自分のタスクを少ないトークンで終えるかどうかを学ばないからだ。飛ばしても、約38%の出力余裕を考えれば通常はどのみち Kimi 有利になるが、確認に1時間の価値はある。

Kimi K2.7 Code を選ぶべきとき

Kimi が1実行あたり明確な選択になる3つのケース。

1. 256K コンテキストに収まる実行。 ほとんどの単一タスクのコーディング実行は 256K を十分に下回る。そのウィンドウ内では Kimi が全トークンで安いので、どの比率でも1実行あたり安く、32%の入力割引がフルに効く入力主体のジョブで最も決定的だ。
2. 新規コンテキストの出力主体の生成。 スキャフォールディング、テスト生成、コード変換の適用。キャッシュ再利用が低いのでフルの入力割引が効き、薄い9%の出力優位でも数千実行にわたって積み上がる。
3. コストをデフォルト化したエージェント群。 大量のルーティンなエージェント実行をルーティングし、難しいケースだけを別へエスカレートするなら、デフォルト項目としての Kimi は、上でモデル化した形で1日1,000実行のワークロードあたり月$915安い。

Modified MIT ライセンスは4つ目の、より柔らかい理由を加える。Moonshot が後でホスティング価格を変えても、重みがあれば同じモデルでセルフホストのフォールバックが得られる。この選択肢は行使しなくても価値があり、将来の価格変動へのエクスポージャーに上限をかけるからだ。同じ論理は素の MIT の GLM-5.2 にも当てはまるので、オープンウェイトの利用可能性はこの2つの間の決め手にはならない。だが、それ以外でデフォルトにしていたかもしれないクローズド API に対しては、実質的な違いになる。

GLM-5.2 を選ぶべきとき

トークン単価では高いモデルが1実行あたりでは良い選択になり得る2つのケース。

1. 256K を超えるリポジトリ全体プロンプト。 GLM-5.2 の 1M コンテキストは Kimi のおよそ4倍だ。256K を超えるプロンプトは Kimi ではチャンク分割して再送するしかなく、各チャンクは重複する入力を再送する。再送された入力トークンは再び課金され、それはまさに Kimi の割引があった場所なので、十分に大きな単一コンテキストのジョブはトークン単価の差を打ち消すか逆転させ得る。ジョブが本当に1回の呼び出しで 1M を必要とするなら、GLM はそれをネイティブにこなし、Kimi にはできない。
2. トークン消費の差を実測した場合。 自分の A/B が、GLM が自分の特定タスクを、4.4対4.0の出力価格を覆すのに十分なだけ少ない出力トークンで終えると示すなら、この表よりも自分のデータを信じよ。損益分岐点は上の実行の形で出力の約1.38倍の余裕だ。それを上回るワークロードは GLM 有利になる。

どちらのケースも同じテーマを共有する。コスト方程式のトークンの半分が価格の半分を上回る状況だ。1M コンテキストのケースはハードな上書きで、256K に収まらないジョブは1回の呼び出しでは Kimi で単純に走らず、チャンク分割は支払う入力トークンを倍増させる。実測差のケースは、実データがある場合にのみ存在するソフトな上書きだ。そのデータがなければ価格の半分が勝ち、価格の半分は Kimi を指す。覚えておく価値のある非対称はここだ。コストで GLM を正当化するには具体的な理由が要るが、Kimi はレートカード以上の正当化を必要としないコストのデフォルトだ。

どちらも正しい選択でないとき

エージェントがビジョン（スクリーンショット、図、PDF ページ）を必要とするなら、ofox 上のテキスト専用 Kimi Code バリアントはそれをこなせず、GLM-5.2 のコスト優位も、それを主導するようには作られていないジョブには無関係だ。マルチモーダルの工程はビジョンモデルへルーティングし、この2つはテキストとコードの作業に残す。ofox カタログ全体での広いルーティングパターン、Claude モデルがエスカレーションを勝ち取る場所も含めて知りたければ、GLM-5.2 vs GPT-5.5 コスト内訳 を見てほしい。より高い価格帯で、同じ「トークン単価対請求」の論理を通しで扱っている。

ofox で両方を試す：1ループで A/B

moonshotai/kimi-k2.7-code と z-ai/glm-5.2 はどちらも OpenAI 互換プロトコルで https://api.ofox.ai/v1 上に稼働している。モデルの差し替えは文字列1つだ。これが、上の表では答えられないトークン消費の問いに実際に答えるハーネスだ。

Python：両モデルを A/B し、トークン使用量を読む

from openai import OpenAI
import os, time

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.environ["OFOX_API_KEY"])

prompt = "Refactor this module for async I/O and add early returns on empty input: ..."

for model in ["moonshotai/kimi-k2.7-code", "z-ai/glm-5.2"]:
    t0 = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    dt = time.time() - t0
    u = resp.usage
    print(f"{model}: {dt:.1f}s  in={u.prompt_tokens} out={u.completion_tokens}")

prompt_tokens と completion_tokens のフィールドが、コスト方程式の欠けた半分だ。これらを検証済みの価格に掛ければ、自分のタスクでの実際の1実行あたりコストが得られる。上の表の等トークン近似ではない。ルーティングのデフォルトをコミットする前に、自分の実ワークロードから20〜30の代表的なケースで走らせてほしい。

Node：同じ形

import OpenAI from "openai";

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

const prompt = "Refactor this module for async I/O and add early returns on empty input: ...";

for (const model of ["moonshotai/kimi-k2.7-code", "z-ai/glm-5.2"]) {
  const t0 = Date.now();
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  const u = resp.usage;
  console.log(`${model}: ${(Date.now() - t0) / 1000}s in=${u.prompt_tokens} out=${u.completion_tokens}`);
}

本番ルーティング：1行のモデル差し替え

自分のトークン数が得られたら、本番ルーティングは1つの関数で済む。コスト重視のトラフィックを Kimi にデフォルト化し、256K 超のジョブを GLM へ送る。

def pick_model(input_tokens: int) -> str:
    if input_tokens > 256_000:
        return "z-ai/glm-5.2"        # needs the 1M window
    return "moonshotai/kimi-k2.7-code"  # cheaper per run under 256K

resp = client.chat.completions.create(
    model=pick_model(estimated_input_tokens),
    messages=messages,
)

同じキー、同じエンドポイント、同じ請求項目だ。ofox の請求書のモデル列が各リクエストのコストを教えてくれるので、1週間後に実支出に対して使い分けを検証できる。関連する Kimi のコスト作業については、30%の思考トークン削減が実際に K2.7 の請求を下げるか と Kimi K2.7 Code の無料・ゼロコストの経路 を見てほしい。

FAQ

Kimi K2.7 Code はトークン単価で GLM-5.2 より安いですか？ はい、すべての軸で安いです。Kimi は入力で32%（$0.95 vs $1.40/M）、出力で9%（$4.00 vs $4.40/M）、キャッシュ読み取りで27%（$0.19 vs $0.26/M）安くなります。

それでエージェント1実行あたりも安くなりますか？ 現実的なほとんどのワークロード形では、はい、ただし差は変動します。入力50K／出力20Kの実行はキャッシュなしで Kimi が19.3%安く、キャッシュヒット80%で13.6%安くなります。Kimi の最大の割引がフルプライス入力にあるため、キャッシュが上がると節約は縮みます。

GLM-5.2 が1実行あたり安くなることはあり得ますか？ はい、2通りあります。ジョブが Kimi の 256K コンテキストを超えてチャンク分割が必要になると、入力トークンの再送が割引を打ち消し得ます。また GLM が自分の特定タスクを十分に少ない出力トークンで終えるなら、その高い出力価格を相殺できます。判断には自分のタスクでトークン消費を測ってください。

コンテキストウィンドウの差は？ Kimi K2.7 Code は 262,144トークン（256K）。GLM-5.2 は 1,048,576トークン（1M）で、およそ4倍大きいです。この差こそ、1実行あたりの答えが「常に Kimi」でない主因です。

どちらもオープンウェイトですか？ はい。Kimi K2.7 Code は Modified MIT ライセンス、GLM-5.2 は MIT で提供されます。セルフホストは将来のホスティング価格変更に対するフォールバックですが、GPU と運用のコストが加わります。

参考情報源

• ofox.ai モデルカタログ：moonshotai/kimi-k2.7-code
• ofox.ai モデルカタログ：z-ai/glm-5.2
• Kimi K2.7 Code モデルカード（Hugging Face）
• GLM-5.2 モデルカード（Hugging Face）
• GLM-5.2 vs GPT-5.5 コスト内訳
• GLM-5.2 アクセスガイド
• Kimi K2.7 Code トークン削減の請求分析
• Kimi K2.7 Code の無料・ゼロコスト経路