OpenRouterの料金体系を解説:リクエスト費用・入金手数料・BYOKの計算方法
OpenRouterのAPIコストを正確に算出するために、モデルごとの推論料金、クレジット購入時の入金手数料、BYOK(独自キー利用)の免除枠と制限を整理して解説します。具体的な計算例や無料枠の制約、レートリミット時の対応策まで網羅しています。
目次

OpenRouterの予算を正確に計画するには、実際に処理されたリクエストのコストと、アカウント残高に入金(チャージ)する前払い資金とを明確に切り離して考える必要があります。さらに、プロバイダーの独自APIキーを連携する場合は、BYOK(Bring Your Own Key)の適用ルールを個別に検証しなければなりません。単に公開されている「100万トークンあたりの単価」を見るだけでは、これらすべての費用構成を網羅することはできません。
モデル単価とクレジットのチャージは別々の費用項目
公式FAQによると、リクエスト費用は事前購入したクレジット残高から差し引かれ、その料金は対象モデルとプロバイダーによって決まります。OpenRouter側は、プロバイダーの料金を推論マークアップ(上乗せ)なしでそのまま転送しているとしており、プラットフォームの手数料はクレジット購入時に発生します。2026年9月14日時点の料金ページでは、従量課金(Pay-as-you-go)の手数料として5.5%と記載されています。
決済を完了する前に、実際に受け取るクレジット額、表示されている手数料、そして支払い方法に対して最終的に請求される合計金額の3つの数値を必ず照合してください。最低決済手数料、適用される税金、あるいは決済手段ごとの追加手数料については、現在の決済画面の計算で確認する必要があります。料金表に記載されたパーセンテージだけでは、最終的な決済総額の代わりにはなりません。
分かりやすい例を挙げると、100ドルのクレジットを購入し、そこに5.5%のプラットフォーム手数料のみが加算される場合、支払総額は105.50ドルとなります。これは税金や通貨換算、決済手数料を除外した計算上のシナリオであり、実際の決済画面のスナップショットではありません。その後20ドル分のクレジットを消費した場合、残高は80ドルとなります。最初に支払った総額の全額を、これら最初の数回のリクエストのコストとして計上することはできません。
実際のワークロードを見積もる方法
プロンプトキャッシュや追加の有料機能を使用しない、標準的なテキスト処理シナリオの場合:
request_cost = input_tokens / 1000000 * input_price
+ output_tokens / 1000000 * output_price
2026年9月14日に現在の料金カタログで確認された、GLMグループにおけるglm-5.3のBetterTokenの実際の料金を例に取ります。米ドル表記で100万トークンあたり入力は1.232ドル、出力は3.872ドルです。キャッシュされていない入力8,000トークン、出力2,000トークンの場合、計算は以下のようになります:
input_cost = 8000 / 1000000 * 1.232 = $0.009856
output_cost = 2000 / 1000000 * 3.872 = $0.007744
total_cost = $0.0176
1000_requests = $17.60
BetterTokenはこの料金に対して別途手数料を加算しないため、この規模での費用はリクエスト1回あたり0.0176ドル、同一の条件で1,000回リクエストした場合は17.60ドルのままです。これにさらに1.055を掛ける必要はありません。OpenRouterの入金手数料はBetterTokenには適用されないためです。この例におけるトークン数は仮想的なものですが、単価は架空のモデルではなく現在のカタログから直接取得しています。なお、キャッシュされたトークンや追加のツール呼び出しはここには含まれていません。これはBetterTokenの試算例であり、OpenRouter上のGLM-5.3との直接的な価格比較ではありません。
この試算を実務的な運用予算に落とし込むには、会話履歴やシステムプロンプトを含む実際のリクエストサイズを測定してください。短いプロンプト処理と長文コンテキスト処理は分けて算出します。自律型エージェント(Agent)の場合は、最終的な出力結果を受け取るまでに発生したすべての中間呼び出しを合算し、最後の応答のみで予算を組まないようにしてください。また、満足のいく回答が得られずに再試行(リトライ)が発生し、課金対象となるAPI呼び出しが行われた場合も、それらをすべて支出ログに記録する必要があります。
プロンプトキャッシュ、画像入力、Reasoning(推論)トークン、リクエストごとの追加料金によって計算が変わる可能性があるため、モデルカードの具体的な課金単位を確認してください。実際の利用状況はActivityログで照合できます。BetterTokenと比較する場合は、その料金ページおよび利用モデル、トークン量、支出額が確認できるWorkspace内の自身の記録を参照してください。必ず同一のタスクおよび同一の課金単位で比較してください。2つの料金表が存在すること自体は、どちらの選択肢がより安価であるかを証明するものではありません。
無料枠は無制限の利用を意味しない
料金ページでは、無料プランに対して1日あたり50リクエストの上限が示されています。これはすべてのアカウントタイプや有料のフォールバックルートに対して同様の条件を保証するものではありません。レートリミットのドキュメントでは、支出制限とリクエスト頻度(レートリミット)の制限を明確に区別しています。HTTP 402エラーはアカウント残高とAPIキーの利用制限を確認する必要があり、HTTP 429ステータスコードはOpenRouterプラットフォーム側またはアップストリームのプロバイダー側のいずれかから発生する可能性があります。
HTTP 429が発生した場合は、レスポンス本文および利用可能であればRetry-Afterヘッダーを確認し、再試行の間隔を空けてバックオフ遅延を設けてください。無制限のリトライループを実装してはなりません。ルーティング設定によって有料モデルにフォールバックする場合は、本番稼働前にそのモデルのコストをあらかじめ予算に組み込んでおく必要があります。無料ルートは互換性の検証には適していますが、ミッションクリティカルな処理においては、レートリミットの上限到達やサービス障害に対する明確な運用代替手段を用意しておく必要があります。
BYOK:両方の請求書を必ず確認する
BYOK(Bring Your Own Key)とは、独自のプロバイダーAPIキーを使用してOpenRouter経由でリクエストをルーティングする仕組みです。2026年9月14日時点の料金ページによると、従量課金(Pay-as-you-go)では定価ベースで月額最大25,000ドルまでの推論がBYOK手数料なしで利用可能であり、それを超えると5%のプラットフォーム手数料が適用されます。この金額は手数料の免除枠を計算するための金銭的しきい値であり、無料リクエストの回数枠や、プロバイダーへの支払いをOpenRouterが肩代わりしてくれることを意味するものではありません。
キーの管理はワークスペースのBYOK設定画面で行われます。BYOKのドキュメントによると、リクエストのディスパッチは厳格な優先順位に従います。まず優先キー(Prioritized keys)が使用され、次にOpenRouterの共有エンドポイント(shared OpenRouter endpoints)、その後にフォールバックキー(Fallback keys)へと、設定されたモデルフィルターやルーティングルールに基づいてルーティングされます。共有キャパシティへフォールバックした場合は、OpenRouterのクレジット残高が消費されます。さらに、ワークスペース予算やガードレール予算(guardrail budgets)ではデフォルトでBYOK支出が除外されているため、必要に応じて「Include BYOK spend」オプションを明示的に有効にする必要があります。
BYOKパイプラインの設定と検証には、以下の手順を推奨します:
- 権限とフィルターの確認:プロバイダーのAPIキーに必要なモデル利用権限があることを確認し、OpenRouter側で対応するモデルフィルターを設定します。
- キー優先度ポリシーの設定:キーの使用順序を定義し、OpenRouterの共有エンドポイントやFallback keysへの自動切り替えを許可するかどうかを決定します。
- 予算枠の分離:予算の上限を個別に設定します。直接利用するアップストリームプロバイダー側と、共有キャパシティへのフォールバックや免除枠超過後のBYOK手数料をカバーするためのOpenRouter残高側の両方でそれぞれ予算を計画してください。
- 単一のテストリクエストを実行:流量を絞ったテストリクエストを1回送信し、Activityログの「View Raw Metadata」を開いて
provider_responsesブロックを確認し、実際のプロバイダー側の請求明細と照合します。自動算出されたコスト配分と実際の請求金額が完全に一致していると検証なしに思い込まないでください。
単一の直接APIで運用要件を満たせる場合は、その請求総額と、同じ処理量をOpenRouter経由で実行した場合の総額を比較検討してください。複数の異なるモデルの冗長化や柔軟な切り替えが必要な場合は、単一のインターフェースと請求の一元管理という運用の利便性を判断材料に加えてください。初期評価としては、件数を限定した小規模なタスクバッチで十分です。承認された成果物1件あたりの最終的な総コストを比較することこそが、単なる入力トークン単価の比較よりもはるかに多くの実態を示してくれます。