OpenRouterの料金・速度・安定性を管理する方法｜キャッシュ・ルーティング・計測

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、夜間バッチでは優先する指標が違います。

Batch APIは、待てる大量処理の料金と完了時間を分けて見る

OpenRouter Batch APIは、corpusのlabel付け、evaluationの採点、埋め込みのbackfill、ticketの一括要約など、各requestをすぐ返す必要がない仕事向けです。submission時にproviderが処理時刻を選ぶ24時間のcompletion windowがあり、通常APIよりper-token料金が低くなるmodelがあります。会話UIや同期処理へ使う機能ではありません。

• モデル一覧で:batch endpoint対応を確認する。同期APIで動くmodelがbatchでも使えるとは限らない
• 1 batchは単一providerで処理され、各requestの失敗は個別結果として返る。custom_idで入力行と結果を対応させる
• OpenRouterのorchestrated web searchはbatchで使えないが、対応するnative provider searchとは区別する
• 24hを待てないtask、audio/video、public URLにできない添付は同期APIなど別の処理経路を選ぶ

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独立記事は増やさず、この親記事と更新メモに確認結果を残します。

公式情報と実務的な推論を分けて運用する

• 公式仕様：endpoint、request field、provider routing、cache指標、Beta・GAの表示をsourceと一緒に記録する
• 実務的な推論：自分のworkloadでTTFT、生成速度、エラー、retry、costを同じ条件で比べる
• 環境依存：provider、model、地域、plan、workspace、data policy、料金は固定の結論にしない
• 未確認事項：実測していない節約率、全model対応、永続的なprovider固定、データ保持なしは断定しない