同じ仕事をさせても9倍違う——OpenRouterが映す「エージェントの効率」と、課金曲線の正体

結論：OpenRouterは「モデル比較」ではなく「エージェント比較」の台だ

LLMの新モデルが出るたび、僕らは反射的にOpenRouterを開く。並べて、ダッシュボードを眺めて、どれを使うか決める。この習慣の裏には「モデルの質を比較している」という前提がある。

でも、本当はもっと面白いことが起きている。

同じ仕事をさせても、エージェントによってトークン消費が1桁違う。 そしてOpenRouterは、その差を他の誰も開示しない形で、中立に並べて見せてくれる。これが「OpenRouterは分析能力が高い」と僕が感じる理由の実体だ。

💡 ひとことで言うと

モデルベンダーは自社モデルの宣伝しかしない。エージェント作者は自社の効率を開示しない。OpenRouterは配線役として、両者の実利用データを横並びで出す。それだけのことが、実は稀有（けう）なんだ。

観察①：エージェント別トークン消費——生データ

OpenRouterの公式「Apps & Agents」ディレクトリ。2026年6月18日時点の週次ランキングをそのまま引っ張ってきた。

順位	エージェント	トークン消費	備考
1	Hermes Agent（Nous Research）	842B	永続メモリ+40ツール+サブエージェント
2	Kilo Code	263B	VS Code / JetBrains / CLI 跨ぎ
3	OpenClaw	178B	メッセージアプリ連携
4	Claude Code（Anthropic）	140B	公式コーディングエージェント
5	pi	89.3B	「this one is yours」個人向け
6	Descript	82.1B	動画/音声編集系
7	Pioneer	33.2B	—
8	ISEKAI ZERO	32.6B	キャラクター冒険
9	Janitor AI	32.3B	ロールプレイ
10	Lemonade	32.1B	—

見てほしい。Hermes Agent（842B）とpi（89.3B）で、9.4倍違う。 同じ「AIエージェント」という括りの中で、1桁の開きがある。

観察②：なぜHermesは9倍食うのか

理由は構造的だ。Hermesの公式説明をそのまま訳せば——

永続メモリ：セッションをまたいで文脈を保持する。つまり毎回、過去の記憶をコンテキストに積む。
40以上のツール：web検索、ブラウザ自動化、vision等々。ツール定義だけで入力トークンが膨らむ。
サブエージェント：子エージェントをspawnして並列実行する。親子で往復する分、トークンが乗る。
スケジュール実行：常駐して定期的に動く。裏でコツコツ消費し続ける。

逆にpiが9分の1で済む理由も同じ構造の裏返しだ。「this one is yours（これはあなたのもの）」というコピー通り、個人向けのミニマル設計。入力トークンが膨らみにくい。

💡 家族で言うと

Hermesは「家政婦付き一軒家」。記憶も道具も人手も揃っているから、何かするたびに全家のリソースが動く。piは「自分の単身赴任先」。必要なものだけ手元に置いて、さっと済ませる。同じ「片付ける」という仕事でも、光熱費が全然違う。

観察③：Claude Codeが意外に効率的な理由

僕が一番驚いたのは Claude Code の位置だ。140B。Hermes の6分の1に収まっている。

Anthropicは公式コーディングエージェントとして、コンテキスト圧縮にかなり注力している証拠だ。コードベースを「全部読む」のではなく、必要なファイルだけを必要な時に引っ張る設計が効いているのだろう。自社モデル（Claude）と自社エージェント（Claude Code）を一貫設計できる強みが出ている。

つまり「エージェント効率」は、モデルの性能だけで決まるわけではなく、コンテキスト設計の巧拙で2〜3倍は動く。これが体感として「PiとOpenCode系でトークン量が違う」と感じる原因の正体だ。

観察④：課金曲線は「階段」か「曲線」か——仮説を検証した

ここで一つ、僕の仮説を検証したい。「OpenRouterの課金は階段的ではなく、なだらかな曲線になっているのではないか」という直感だ。

結論から言うと、仮説は本質的に正しい。 細部を詰めよう。

公式ドキュメントが語る制限構造

:free モデルの1日上限はこうなっている。

課金状況	`:free` モデル 1日上限
10クレジット未満購入	50 req/day
10クレジット以上購入	1000 req/day

加えて全アカウント共通で 20 req/min。残高がマイナスになると free モデルも 402 エラー。

「曲線」に見える3つの理由

厳密には「50→1000」の2段階階段である。でも僕の直感が「曲線」と感じたのには理由がある。

① 段差の位置が極めて低い 10クレジットは数ドルだ。一般のSaaSが「Free / Pro / Team / Enterprise」と4〜5段で組む中、OpenRouterは実質2段。階段の数が少ないから、曲線に近く見える。

② 支払い実績で滑らかにアンロックされる 無料枠の広さが「課金しろ」ではなく「払った分だけ広がる」構造。フリーミアムの「壁」ではなく「坂道」になっている。僕が「課金しろ、量に従ってフリーモデルが使える」と言ったのは、この坂道を指していた。

③ サブスクではなく使い切り＋キャッシュ自動割引 月額課金の「アップグレードしろ」という押し売り構造ではない。使った分だけ支払い、プロンプトキャッシュが効いた分は自動で割引。これが「使うほど割安になる」曲線を、ユーザー側の操作なしで実現している。

💡 コスパの境界点

10クレジット（数ドル）を入れるだけで、:free 上限が 50→1000/day（20倍） に跳ね上がる。コスト効率を考えるなら、ここが唯一の「段差」。ここを超えれば、あとは滑らかに広がる。

観察⑤：「平等に扱おうとする姿勢」の正体

僕はOpenRouterに「ユーザーを平等に扱おうとする姿勢」を感じると言った。この正体は何か。

それは**「量に比例した課金」という設計選択**に尽きる。

月額サブスクなら、重いユーザーが得をして軽いユーザーが損をする（累進課税の逆）。
トークン従量課金なら、使った分だけ払う。平等そのものだ。
さらにキャッシュ割引が「同じプロンプトを何度も投げる人」を自動で優遇する。これは「学習コストを払った人」への報酬であり、教育的ですらある。

OpenRouterは「階段で分断しない」ことで、ユーザー間の格差を意図的に小さく保っている。それが「平等」という感覚の源だ。

実用：僕の艦隊でどう振り分けるか

このデータを実務に落とす。僕の環境（Pi + OpenCode + Hermes 艦隊）で取れる一手は3つ。

① 重いタスクはpi系に振る 長文生成・多段推論など、入力トークンが膨らむ作業は pi（89B級）に任せる。Hermes（842B級）は9倍のコストが乗るから、記憶・スケジュール・ツール連携が必須な常駐系に限定する。

② フリーモデルは10クレジット投入後が本番 50→1000/day の20倍跳ね上がりポイントを超えてからが投資対効果の山場。そこまでは「お試し」、そこから先が「実用」。

③ 新モデル登場時は /rankings で即時比較 リリース直後にキャッシュヒット率（%）とトークン量を1画面で見る。「質×コスト」を同時に判断できるのが、OpenRouterの最大の便利さだ。

結び：分析能力の「図一」は、配線役の中立性にある

振り返ろう。

OpenRouterが便利なのは、新モデルを並べてくれるからだけではない。「どのエージェントがどれだけトークンを食うか」を、誰も開示しないデータとして公開しているからだ。

モデルベンダーは自社モデルを売りたい。エージェント作者は自社効率を隠したい。その両者のインセンティブが噛み合わない隙間に、OpenRouterは配線役として入り込み、中立の数字を横並びで出す。これが「詳細な分析能力を持っている」という評価の実体であり、唯一の競争優位だ。

同じ仕事をさせて9倍違う。その事実を、僕らはOpenRouterのおかげで知っている。

それが、階段ではなく曲線だと感じる課金設計とセットになっている。**「量に比例して平等に」**という哲学が、配線役の中立性と呼応している。OpenRouterをただのAPIルーターだと思っている人は、一番面白いところを見逃している。

本記事のデータはOpenRouter公式公開情報（rankings / apps / docs）に基づく。エージェント別トークン量は週次ローリング値のため時期により変動する。