OpenRouterの料金・速度・安定性を管理する方法｜キャッシュ・ルーティング・計測
OpenRouterを個人開発で使うときの料金、速度、安定性の見方を、Prompt Caching、Sticky Routing、provider選び、Classifiers、音声・マルチモーダルAPIから整理します。
公開 2026.07.29 / 更新 2026.07.29
OpenRouterを安く速く使うには、モデル単価だけで決めず、cache hit、providerの待ち時間、fallback、再試行、利用目的を分けて記録します。まず全体像を読み、Prompt CachingとSticky Routing、provider性能とClassifiersの各論へ進んでください。
- 料金・cache・provider routingの判断軸
- provider performanceとClassifiersの役割分担
- Transcription・マルチモーダルAPIの統合範囲
- 特定モデルの最安・最速ランキング
- 未測定の節約率や性能保証
- OpenRouter公式情報にないendpoint・料金の断定
この記事のポイント
- Prompt CachingとSticky Routingは、長い固定入力を繰り返すagent loopで条件が揃ったときに効く
- provider performanceは平均速度だけでなく、latency、throughput、uptime、quantizationを分けて見る
- Classifiersは料金を自動で下げる機能ではなく、AI利用を分類してログと集計で観測するBeta機能
- Transcriptionとマルチモーダル入力は一つのbase URLで扱えるが、endpointとcontent typeは同じではない
問題ごとにOpenRouterの機能を選ぶ
| 同じ長文を何度も送る | Prompt Caching。provider・モデル・cache条件とcache hitを確認 |
| 会話を同じproviderへ戻したい | Sticky Routing。session_id、会話単位、fallbackの挙動を確認 |
| 速度・安定性を比べたい | Provider Performance。latency、throughput、uptime、quantizationを同じworkloadで測る |
| どの作業が料金を使ったか知りたい | Classifiers。Betaの分類タグ、sampling、classifier自体の課金を確認 |
| 音声・画像・動画を扱いたい | 同じbase URLでもendpointとcontent typeをモデルごとに分ける |
OpenRouterを安く速く使う答えは、安いモデルを一つ選んで固定することではありません。同じ入力を繰り返すならcache、会話をまたぐならsticky routing、provider差を見たいなら性能指標、使い道と請求を知りたいならClassifiers、というように問題を分けます。
料金を下げる前に、何が繰り返されているかを見る
AIエージェントでは、モデルの入力単価だけでなく、固定system prompt、tool定義、会話履歴、出力、リトライ、fallbackが請求と待ち時間を作ります。Prompt Cachingは同じ長い入力を再利用できる可能性がありますが、cache hitが見えなければ節約したとは言えません。
速度は『最速provider』ではなく、workloadの分布で見る
公式のprovider performance説明では、同じmodelでもprovider endpointごとにlatency、throughput、uptime、quantizationが変わります。平均だけを見ると、たまに極端に遅いp90・p99の尾を見落とします。チャットUI、長文生成、tool call、夜間バッチでは優先する指標が違います。
Classifiersは、料金を自動で下げる機能ではない
Classifiersは、generationをtask type、agent complexity、department、compliance categoryなどのtaxonomyで分類し、Activityやログで集計するworkspace機能です。分類は元の推論リクエスト後に非同期で行われるため推論経路にlatencyを足さないと公式説明されていますが、classifier modelのtokenは課金対象です。sampling rateを含め、観測コストも一緒に見ます。
Transcription・マルチモーダルは『一つのAPI』でも同じrequestではない
OpenRouterは一つのbase URLでimage、video、audio、embeddings、transcriptionへ接続できます。ただし、画像・音声・動画の入力は主にchat completionsのcontent typeを使い、transcriptionは専用のaudio/transcriptions endpointを使います。音声はbase64入力、動画URL、対応model/providerなど条件が分かれるため、統一APIを完全互換と読み替えないことが重要です。今回は検索意図が親記事と重なるため、Transcription独立記事は増やさず、この親記事と更新メモに確認結果を残します。
| 用途 | 公式に確認できる入口 | 実装前の確認 |
|---|---|---|
| 音声を文字にする | POST /api/v1/audio/transcriptions | base64、model、format、usage.cost、timeout、provider制御の範囲 |
| 音声を理解する | POST /api/v1/chat/completions + input_audio | 対応model、音声形式、content array、provider差 |
| 画像・PDF・動画入力 | 主にchat completions + content type | modelごとの対応、URL/base64、動画URL制限 |
| 画像生成・embeddings・TTS | 専用endpoint | request shape、response形式、価格の単位 |
公式情報と実務的な推論を分けて運用する
- 公式仕様：endpoint、request field、provider routing、cache指標、Beta・GAの表示をsourceと一緒に記録する
- 実務的な推論：自分のworkloadでTTFT、生成速度、エラー、retry、costを同じ条件で比べる
- 環境依存：provider、model、地域、plan、workspace、data policy、料金は固定の結論にしない
- 未確認事項：実測していない節約率、全model対応、永続的なprovider固定、データ保持なしは断定しない
よくある質問
OpenRouterを安く使うには、安いモデルを選べば十分ですか？
十分ではありません。固定入力のcache hit、出力長、tool call、retry、fallback、provider、請求経路を分けて確認します。未測定の節約率は記事からは判断できません。
Classifiersを使えばAPI料金は下がりますか？
自動で下がる機能ではありません。generationを分類して、どの作業・難度・部門が費用を使ったかを見えるようにするBeta機能です。classifier modelのtokenも課金されるため、sampling rateと観測効果を比べます。
Transcription APIと音声入力は同じですか？
違います。音声を文字列へ変換する場合はaudio/transcriptions、音声をモデルに理解させる場合はchat completionsのinput_audioが入口です。対応model、format、provider制御、response形式を分けて確認します。