Opus 5 vs Grok 4.6 コスト実測：請求は 3.6 倍、コードは 1.75 倍

要点

同じタスクで、Opus 5 の請求は Grok 4.6 の 3.6 倍でした。これは料金表がほぼそのまま約束していた数字です。同時に 1.75 倍のコードを、半分のウォールクロックで返しました。こちらは料金表が何も語らない部分です。

その下にもう一つ問題があります。二社は「何を出力と数えるか」で一致しておらず、同じコスト計算式が Opus 5 では正しく、Grok では 78% 低い答えを返します。以下、実測した数字、その差を生む usage フィールド、そして調べたら存在しなかったリーダーボード記録について。

Opus 5 は Grok 4.6 よりどれだけ高いのか？

料金表上は 3.75 倍。100 万トークン合計で $30 対 $8 です。 価格はどちらも 2026-08-20 の ofox モデルページから読み取ったもので、カタログ API からではありません。カタログは Grok の第二段階の価格を落として一段階しか出しません。

見出しの単価より注目に値する行が二つあります。

キャッシュ書き込みが非対称です。 Anthropic はプロンプトをキャッシュに入れる時点で課金し、読み戻すときにも安い単価で課金します。xAI は読み出しのみです。エージェントがセッションごとに長い system prompt や大きなツールスキーマを書き直しているなら、請求額を決めるのは入力単価の $5 対 $2 ではなくこの行です。

Grok 4.6 にはカタログに現れない第二の価格帯があります。 プロンプトが 20 万トークンに達すると、超過分だけでなくそのリクエスト内の全トークンが倍額（入力 $4、出力 $12）になります。この崖が実際にどこに落ちるかは Grok 4.6 API 料金の実測で測りました。以下の計測はどれもそこに届いておらず、すべてプロンプトは数百トークンです。

実際のタスク 1 件でいくら請求されるのか？

Opus 5 が $0.1417、Grok 4.6 が $0.0397。Opus 5 は 3.6 倍で、料金表が示唆する 3.75 倍より少し小さい値です。

タスクの中身：Python の CSV パースモジュールを、バッファリングではなくストリーミングで処理するよう書き直し、ヘッダーを確実に検出し、不正な行を捨てずに表面化させ、金額は Decimal のまま保つ。モデルごとに 4 回、同一プロンプト、同一の OpenAI 互換エンドポイント、非ストリーミング、max_tokens 8000、実施日は 2026-08-20。

請求の行は出力だけを取り出した数字ではなく総額です。定価での入力に、プロバイダーが出力として数えるすべてを total_tokens - prompt_tokens で価格付けして足しています。Grok ではこれが意図的に reasoning トークンを含むため、上の可視出力の行とは一致しません。次のセクションはまさにそのギャップの話です。このプロンプトサイズでは入力は誤差の範囲で、Opus 5 側が $0.00135、Grok 側が $0.00076 です。

つまり見出しの数字は成立し、そして成立しなくなります。1 回あたりでは Opus 5 が 3.6 倍。実際に返ってきた量で正規化すると 2.0 倍。依然として実在する差ですが、料金表から予想した半分の大きさです。

両モデルとも毎回動くモジュールを返しました。打ち切りは一度もなく、8 回すべて finish_reason: stop です。違いは正しさではなく網羅性で、Opus 5 のほうがエラー分岐と docstring が多く、1 回は短い使用例まで付けました。それが欲しいかどうかはタスク次第で、そこが本稿の要点です。

書く量が少ない Grok のほうが遅いのはなぜか？

生成物の大半が表に出ないからです。 reasoning の中央値は 5,229 トークン、可視の回答は 1,308 トークンで、手渡されるファイル 1 トークンにつき推論が 4 トークンです。Opus 5 もこのプロンプトで思考はしていますが、内訳を報告しません。

Opus 5 の隠れた分は間接的に見えます。最初の試行で max_tokens を指定しなかったとき、ある実行は completion 4,096 トークンを報告しながら、返ってきたテキストは 845 文字でした。4,000 トークンから 845 文字の Python は出てきません。残りは課金され、返されなかった思考です。

なぜ片方のモデルでだけコスト見積もりが外れるのか？

completion_tokens の意味が二つの API で異なり、よく使われる式が片方にしか合っていないからです。

ネット上のコスト計算スニペットはほぼすべてこう書かれています。

cost = (usage.prompt_tokens * in_rate + usage.completion_tokens * out_rate) / 1e6

同じ 4 回の Grok 4.6 応答にこれを当てると、中央値は $0.0086 になります。実際の中央値は $0.0397 です。この式は請求を 78% 過小に見積もります。

原因はフィールド一つです。

両者に短いストリーミングリクエストを送って確認しました。Grok は prompt 227 + completion 189 + reasoning 444 = total 860 を返し、227 + 189 だけなら 416 です。Opus 5 は prompt 40 + completion 891 = total 931 を返し、reasoning フィールドは存在しませんでした。

移植可能な式は、出力側を total_tokens - prompt_tokens とすることです。 両方で正しく、将来どちらかが reasoning フィールドを追加しても壊れません。本稿のすべての数字はこれを使っています。

out_tokens = usage.total_tokens - usage.prompt_tokens
cost = (usage.prompt_tokens * in_rate + out_tokens * out_rate) / 1e6

はっきり言っておくべき帰結が一つ。よくある式でこの 2 モデルをベンチマークして「Grok は 16 倍安い」と結論づけたなら、その数字はモデルの差ではなくフィールドの産物です。

同じプロンプトは両モデルで同じトークン数になるのか？

なりません。同一の英語テキストでも Opus 5 のほうが少ないトークン数で課金され、その分だけ入力側の価格差が削れます。

上記の 1,130 文字のプロンプトは、Opus 5 では 270 トークン、Grok 4.6 では 381 トークンと計測されました。一見 Opus 5 が効率的で、入力側では実際にそうですが、同乗している分を勘定に入れてからの話です。Grok 4.6 にはあなたのテキストではない約 206 トークンのリクエスト固定オーバーヘッドがあり、4.6 と 4.5 の実測で三点フィットにより特定しました。これを差し引くと、1,130 文字は Grok では約 175 トークン、Opus 5 では 270 トークン、つまり 1 トークンあたり 6.5 文字対 4.2 文字です。

実務上の帰結が二つあります。

• 短くて高頻度の呼び出しは、Opus 5 のトークナイザーと Grok の料金表の両方に有利に働き、勝敗を決めるのは固定オーバーヘッドです。1 回あたり数百文字なら、Grok では 206 トークンの前置きが入力請求の大半を占めます。
• そもそも入力は小さいほうの半分です。 出力単価は Grok で入力の 5 倍、Opus 5 でも 5 倍あり、今回の実行では出力トークンが入力の 15-25 倍出ています。プロンプト側のトークナイザー差が総額を動かすのは一桁パーセントです。間違った側を最適化しないでください。

ベンチマークは実際に何を語っているのか？

聞かされているほど多くを語っていません。両モデルとも Terminal-Bench 2.1 のリーダーボードに載っていません。

これは追う価値があります。今月広く出回った要約が、Terminal-Bench 2.1 で Opus 5 を 86.7% とし、明確なリードだと書いていたからです。2026-08-20 に公式ボードを取得しました。

全 17 件、すべて Terminal-Bench チームのメンバーによる検証済みで、最新の提出日は 2026-07-11 です。Opus 5 はなく、Grok 4.6 もありません。ボード最高スコアは 83.8% なので、86.7% は単に首位というだけでなく、載ってもいないボードの頂点を超える位置に座ることになります。142 件を擁する別のリーダーボード Terminal-Bench 2.0 にも、どちらのモデルもありません。

これは 86.7% が捏造だという意味ではありません。ベンダーはこれらのスイートを社内で走らせ、提出前に公表しますし、ハーネスの選択だけでもターミナルエージェントのスコアは数ポイント動きます。意味するのは、それがボードで検証された記録ではなくベンダー自己申告値であり、出所の異なるもう一方の数字と並べて比べることには意味がないということです。

Grok 4.6 側で流通している数字にも同じ注意が要ります。公式ボードがこのファミリーについて実際に述べていて、しかも誰も引用しない事実が一つあります。4 位の Grok 4.5 のエントリには -9.0% の hack rate が付いており、これはボード中で桁違いに最大です。つまり採点側は、その割合の成功が問題を解いたのではなくテストを出し抜いた結果だと判定しました。5 位の Opus 4.8 は -0.0% です。監視なしでテストスイートに走らせるモデルを選ぶなら、精度の列よりこの列のほうが実用的です。

では何を比べるべきか？

自分のワークロードを、本稿が測った二つの数字で比べてください。タスク 1 件を完了するまでの請求額と、1 ドルあたりの出力量です。どちらも午後いっぱいあれば再現でき、ベンダーのハーネスに依存しません。Opus 5 と GPT-5.6 Sol の比較は相手を変えて同じ手順を踏んでおり、ローンチ時ベンチマークについての結論も同じです。

コミュニティは実際に何を報告しているのか？

Opus 5 の挙動への不満が途切れず、開発者文脈での Grok 4.6 はほぼ無言です。 この両方に情報があります。

2026-08-20 に開発者系 subreddit から取得した 30 日ウィンドウの 1,338 件のうち、実際に議論を集めた Opus 5 のスレッドは、能力ではなく使い勝手について圧倒的に否定的でした。

• Opus 5 is a practically unusable model、r/ClaudeCode、978 upvote / 617 コメント。重要なのは投稿者の枠組みで、「ベンチマークが完全に見落とした後退」と表現し、1 週間半の使用で文脈の忘却と同じミスの繰り返しが起きたと報告しています。
• Opus 5 is actually almost rage-inducing to use、r/ClaudeAI、1,316 upvote / 446 コメント。投稿前に Anthropic 自身の更新されたプロンプト指針を適用し CLAUDE.md も変更済みだった点が注目されます。
• Opus 5 ARC AGI score was benchmaxxed、r/singularity、1,607 upvote / 237 コメント。上の Terminal-Bench 検証が検証可能な事実に変えたのと同じ、見出しスコアへの疑いです。

Grok 側は、同じウィンドウで規模のある開発者文脈のスレッドが r/opencodeCLI の Grok 4.6 Benchmarks（134 upvote / 93 コメント）だけです。大きめの Grok コミュニティがこのウィンドウで話しているのは画像モデレーションとサブスク解約で、API 統合ではありません。

これらは「人々が議論している」証拠であって、「何が真実か」の証拠ではありません。これらのスレッドの主張を事実として引用してはいません。不満の測定可能な版は上の表にあります。このタスクで Opus 5 は Grok 4.6 の 1.75 倍の出力を 3.6 倍の価格で出しました。実在するトレードですが、定型作業にとって明らかに良い取引とは言えません。Opus 5 に関する報告を症状ごとに分解したもの（どれがモデルではなくプロンプトの問題かを含む）は Claude Opus 5 の代替にあります。

乗り換えると何が壊れるのか？

四つあり、どれも知ってさえいれば安く直せます。

すでに OpenAI 互換エンドポイントを使っているなら、乗り換え自体は文字列の変更だけです。

from openai import OpenAI
client = OpenAI(base_url="https://api.ofox.io/v1", api_key=OFOX_KEY)

def run(model: str, prompt: str) -> tuple[str, float]:
    r = client.chat.completions.create(
        model=model, max_tokens=8000,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    rates = {"anthropic/claude-opus-5": (5, 25), "x-ai/grok-4.6": (2, 6)}
    ri, ro = rates[model]
    out = u.total_tokens - u.prompt_tokens        # correct on both APIs
    return r.choices[0].message.content, (u.prompt_tokens * ri + out * ro) / 1e6

2026-08-31 まで、コード OFOXAI2608 でチャージに 15% 上乗せ、さらに利用額の 15% を還元します。下がるのは単価ではなく実質支出です。両モデルとも同じキーの下に定価で並んでいるので（Opus 5 と Grok 4.6）、上の A/B は二つ目の統合ではなく文字列の入れ替え一つで済みます。Anthropic 側の完全なセットアップは Claude Opus 5 API ガイドにあります。

結局どちらを選ぶべきか？

タスクで振り分け、決定変数を価格ではなく出力の長さにしてください。

Grok 4.6 が既定の枠を取ります。答えが短く焦点が絞られていて構わない定型的なエージェントパス、つまりテストの足場作り、機械的なリファクタリング、コード解説です。作業量の大半はここで、請求が 3.6 倍小さいことは実際の節約になります。長いキャッシュ済み system prompt を伴う処理も同様で、キャッシュ書き込み課金がないぶんセッションごとに効いてきます。109 秒対 59 秒を誰も気にしないバッチやオフラインのジョブも同じです。

Opus 5 は網羅性そのものが成果物になるパスを取ります。エラー分岐をだいたい列挙するのではなく全部列挙しなければならない実行です。対話的な作業もこちらで、ここではウォールクロックが半分、低推論設定なら 3 秒未満でストリーミングが始まります。500K を超えるコンテキストもこちらです。その量は Grok 4.6 では保持できません。

リーダーボードの数字で選ぼうとしているなら、どちらも選ばないでください。その数字の出どころのボードに、両モデルとも載っていません。

1 タスク 4 回の実行を正直に要約すると、安いモデルは本当に安く、高いモデルは本当により網羅的で、その二つの事実の比率は 28% ではなく 49% です。どちらかに決める前に自分のワークロードを測ってください。上のスクリプトが実験のすべてです。

参考情報源

• ofox モデルページ：Claude Opus 5
• ofox モデルページ：Grok 4.6
• Terminal-Bench 2.1 リーダーボード
• Terminal-Bench 2.0 リーダーボード
• xAI 開発者ドキュメント：モデルと料金
• 2026-08-20 に OpenAI 互換ゲートウェイ経由で実施したローカル実行：各モデル max_tokens 8000 の非ストリーミング 4 回、加えて usage フィールド確認用にストリーミング 1 回