OpenRouterの代替サービスとして最適なものは、用途によって異なります。コーディングエージェントのトラフィックが多く、300以上のモデルに手数料なしでアクセスしたいならhaimaker.ai。ゲートウェイを自社インフラ内で運用する必要があるならLiteLLM。コンプライアンスチームが確認を求めてくるならPortkey。1つのプロバイダーが1つのモデルを一貫してサーブしてほしいならTogether AIまたはFireworksです。

どれが合うかは、なぜOpenRouterを離れようとしているかによります。理由は大きく3つしかありません。プラットフォーム手数料、不透明なプロバイダールーティング、SLAの欠如です。

このカテゴリの全体像を、包み隠さず整理しました。OpenRouterが依然として正解であるケースも含めて紹介します。

OpenRouterの代替サービスとして最適なのはどれか？

8つの製品がOpenRouterのユーザーを奪い合っていますが、互換性のある代替品ではありません。4つは独自カタログを持つ統一ゲートウェイ（haimaker.ai、LiteLLM、Portkey、Requesty）、2つは自社でモデルをホスティングする直接推論プロバイダー（Together AI、Fireworks）、1つは既存キーのオブザーバビリティレイヤー（Cloudflare AI Gateway）、1つはパフォーマンス重視のセルフホストプロキシ（Bifrost）です。

カタログチャージ時のプラットフォーム手数料プロバイダー制御セルフホストエージェントセットアップ
haimaker300+モデル、29プロバイダーなし自動ルーティングまたは固定ホステッドnpx @haimaker/connect
OpenRouterカテゴリ最大クレジットに5.5%（最低$0.80）自動、デフォルトで不透明ホステッド手動設定
LiteLLM100+プロバイダーなし（セルフホスト）完全制御可手動設定
Portkey広範プランベース完全制御可手動設定
Requesty広範プランベースレイテンシルーティングホステッド手動設定
Together / Fireworks自社ホスティングモデルなし単一プロバイダー不可手動設定
Cloudflare AI Gatewayなし（キー持ち込み）なし該当なし不可該当なし
Bifrost23+プロバイダーなし（セルフホスト）完全制御可手動設定

この表は「どんな選択肢があるか」に答えます。ただし「どれを選ぶべきか」は、OpenRouterのどの問題がきっかけで探し始めたかによって変わります。そこから考えましょう。

開発者がOpenRouterを離れる理由は何か？

大きく3つあります。頻度の高い順に並べると、トークンを購入する前にパーセンテージを差し引くプラットフォーム手数料、どのホスト（およびどの量子化バージョン）がリクエストを処理するかを暗黙的に変えるプロバイダールーティング、そして公開された稼働率SLAの欠如です。「OpenRouterは高い」という投稿の多くは、このうちどれを指しているのか明言していません。

手数料は構造的なものであり、マークアップではない

OpenRouterが推論にマークアップを載せていないという主張は事実です。トークン単価のカタログ価格は、元のプロバイダーが公開しているものと一致します。コストは別の場所に乗ります。OpenRouter自身のFAQによると、カードでのクレジット購入には5.5%（最低$0.80）がかかり、BYOK（キー持ち込み）リクエストは月100万件まで無料、それを超えるとOpenRouterで通常かかる料金の5%が課金されます。

この組み合わせこそが、同じ不満が繰り返し上がる理由です。月$1,000の利用なら、5.5%にあたる$55はトークンには1ドルも回らない計算です。少額チャージはさらに不利で、$10の購入に対する$0.80の最低手数料は実質8%に相当します。

プロバイダールーティングはブラックボックス

OpenRouterはほとんどのオープンウェイトモデルを上流プロバイダーのプール経由でサーブし、価格とキャパシティに基づいてリクエストごとに1つを選択します。これは実際の機能であり、プロバイダーがダウンしたときに可用性を確保する仕組みです。

しかし、モデルの挙動が不安定に感じる理由でもあります。同じモデル名への3回の連続呼び出しが3つの異なるホストに着地し、それらのホストが常に同じ量子化バージョンをサーブするとは限りません。出力品質が変動するのに、コードは何も変わっていません。チャットボットなら許容範囲です。しかし、長いツールユースループを回すエージェントにとっては、暗黙的に劣化したモデルがタスク失敗と1時間のデバッグを意味します。

SLAがない

OpenRouterは契約上の稼働率保証を公開しておらず、サポートは主にコミュニティチャネル経由です。プロトタイプやサイドプロジェクトには合理的なトレードオフです。しかし、顧客に課金しているサービスが依存している場合は、話が別です。

300以上のモデルを1つのキーで

各OpenRouter代替サービスは実際何が得意か？

8つそれぞれが特定の状況で勝ち、それ以外では負けます。ランキングではなく「問題がXならこれを選べ」という読み方をしてください。統一ゲートウェイを先に、次に直接プロバイダー、最後にこれらの検索で上位表示されながらより狭い問題を解決する2つのスペシャリストを紹介します。

haimaker.ai — 1つのキー、300以上のモデル、コーディングエージェントのために設計

haimaker.aiは、単一エンドポイントと1つのキーで29プロバイダーにわたる300以上のモデルに到達する、OpenAI互換の統一ゲートウェイです。base_urlを変更し、既存のOpenAI SDKコードをそのまま使えば完了です。

このリストの他と一線を画す点が2つあります。1つは自動ルーティング。リクエストごとにコスト・知能・速度の観点で最適なモデルに振り分けるため、モデルを呼び出しごとにハードコードする必要がありません。もう1つは、1つのコマンドでコーディングエージェントを接続できること：

npx -y @haimaker/connect

Claude Code、Codex、opencode、OpenClaw、Hermes、Cline、Kilo Codeに対応し、プロバイダー設定をJSONの手動編集なしで自動生成します。

選ぶべきケース： チャージにプラットフォーム手数料をかけずに幅広いモデルを使いたい、コーディングエージェントを多用している、ルーティングでコストを削減したい場合。統合の詳細は/model-api、エージェント接続は/connectを参照してください。

OpenRouter — まだ正解である場合もある

まず、認めるべき点から始めましょう。OpenRouterはカテゴリ最大のカタログ、実際のコミュニティ、優れたモデルエクスプローラー、そしてここで紹介する中で最も多くの人を最も多くのモデルに触れさせてきた無料プランを持っています。プロバイダーフォールバックは正当な可用性機能です。

選ぶべきケース： プロトタイピング中、ロングテールや実験的モデルを含む最大カタログが欲しい、無料プランで新しいものを試したい場合。

LiteLLM — セルフホストの定番

LiteLLMは、ゲートウェイを自社インフラ内に置く必要がある場合にほとんどのチームが最初に手にするオープンソースプロキシです。Python SDKとプロキシサーバーで構成され、100以上のプロバイダーに対してOpenAI形式で通信し、コストトラッキング、ロードバランシング、ロギングを処理します。GitHubで53,000以上のスターを獲得し、このカテゴリで最も広くデプロイされています。

トレードオフは明確です。運用はすべて自分たちの責任になります。アップグレード、障害対応、深夜のオンコール——全部自分たちで抱えることになります。

選ぶべきケース： リクエストパスを自社VPC内に留める必要がある、プラットフォームエンジニアが運用できる、サードパーティを中間に挟めないコンプライアンス要件がある場合。

Portkey — ガバナンスとガードレール

Portkeyは、オブザーバビリティ、プロンプト管理、PIIマスキング、ガードレールを備えたAIゲートウェイで、セルフホスト可能なオープンソースゲートウェイも提供しています。エンジニアではなくコンプライアンスチームが意思決定を主導する場合の定番の選択肢です。

選ぶべきケース： カタログの広さよりも、リクエストレベルのガバナンス、ガードレール、監査証跡が必要な場合。

Requesty — マネージド、エンタープライズ向け

Requestyは、レイテンシベースルーティング、自動フェイルオーバー、プロンプトキャッシュ、ロールベースアクセス制御、EUデータレジデンシーを提供するフルマネージドゲートウェイです。運用するプロキシではなく、契約のあるベンダーを求めるバイヤーをターゲットにしています。

選ぶべきケース： SLA、EUデータレジデンシー、問い合わせ先が必要な場合。

Together AIとFireworks — ゲートウェイではなく直接プロバイダー

Together AIとFireworksはすべての「OpenRouter代替サービス」リストに登場するので、正確に何であるかを明確にしておく価値があります。両者ともオープンウェイトモデルを自社ハードウェアでホスティングする推論プロバイダーです。アグリゲーターではありません。1つのベンダーのサービングスタック、一貫した量子化、ルーティングの予期せぬ変動がない代わりに、カタログは自社でホスティングしているものに限定されます。

選ぶべきケース： 1〜2つのオープンモデルに標準化しており、選択肢の広さよりもサービングの一貫性を重視する場合。実験を終えた本番ワークロードには本当に良い選択肢です。

Cloudflare AI Gateway — 薄いオブザーバビリティレイヤー

Cloudflare AI Gatewayは、すでにキーを持っているプロバイダーAPIの前に置くキャッシュ、レート制限、分析レイヤーです。統一カタログも統一課金もありません。同じ検索キーワードで上位表示される別の製品です。

選ぶべきケース： すでに直接プロバイダーのキーを持っており、集約ではなくキャッシュと可視性が欲しい場合。

Bifrost — プロキシのオーバーヘッドが制約になるとき

Bifrostは、レイテンシを最大の売りとしているGo製のゲートウェイです。持続的な5,000リクエスト/秒のベンチマークで23以上のプロバイダーに対して1リクエストあたり11マイクロ秒の追加オーバーヘッドを公称しています。これが意味を持つかどうかはワークロード次第です。

選ぶべきケース： 大規模なエージェントループを運用しており、1呼び出しあたり40ミリ秒のゲートウェイオーバーヘッドが1タスク全体で数百ミリ秒の純粋なプロキシレイテンシに蓄積する場合。

どのOpenRouter代替サービスを選ぶべきか？

探し始めた理由に合わせて代替サービスを選んでください。手数料が理由なら、手数料率を取らないゲートウェイならどれでも機能し、さらにルーティングがあれば節約幅は大きくなります。出力に一貫性がないなら、プロバイダー制御が必要です。コンプライアンスはセルフホストまたはガバナンスベンダーを意味します。エージェントトラフィックが大部分なら、統合とルーティングを最優先にしてください。

手数料が問題の場合。 OpenRouterはトークンにマークアップを載せていないため、節約はプラットフォームの手数料を取り除くことから生まれ、より安いモデル単価を見つけることからは生まれません。チャージに手数料のないゲートウェイなら、その5.5%をトークン予算に残せます。手数料以上の節約を求めるなら、ルーティングがレバーです。簡単なリクエストを安いモデルに送り、難しいものだけにプレミアム層を使うことで、数パーセントの節約よりはるかに大きく請求額を動かせます。詳細は自動ルーティングで推論コストを削減するで解説しています。

モデル品質の一貫性の欠如が問題の場合。 プロバイダー制御が必要です。上流を固定できるゲートウェイか、Together AIやFireworksのようにモデル自体をサーブする直接プロバイダーのどちらかを選んでください。

コンプライアンスが問題の場合。 LiteLLMをセルフホストするか、Portkeyやマネージドエンタープライズゲートウェイからガバナンスを購入してください。プライバシー条項は必ず読んでください。ゲートウェイ経由の呼び出しは2ホップなので、実効的なデータ保持ポリシーはゲートウェイの条項と下流プロバイダーの条項の和集合になります。

コーディングエージェントが支出の大部分を占める場合。 統合とルーティングを重視して判断してください。セットアップの摩擦もトークン請求額もそこに存在するからです。モデル選びも兼ねているなら、コーディングエージェント向け最安APIとOpenClaw向けベストモデルがモデル側の選択肢をカバーしています。

実際には何も壊れていない場合。 そのまま使い続けてください。ゲートウェイの切り替えは安価ですが無料ではなく、OpenRouterは良い製品です。好奇心は移行の理由にはなりません。

OpenRouterからの移行はどれくらい大変か？

離れることは選ぶことよりはるかに簡単です。このリストのすべての選択肢がOpenAI API形式に対応しているため、アプリケーションコードの移行はベースURLとAPIキーの変更だけで、通常は2行のdiffです。コーディングエージェントの移行は1コマンドです。スタックの他の部分は何も変わりません。

アプリケーションコードの場合、OpenAI SDKを新しいエンドポイントに向けてください：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.haimaker.ai/v1",
    api_key="YOUR_KEY",
)

コーディングエージェントの場合、設定ファイルを完全にスキップできます：

npx -y @haimaker/connect

Claude Code、Codex、opencode、OpenClaw、Hermes、Cline、Kilo Codeを検出し、それぞれのプロバイダー設定を自動で書き込みます。エージェント側の移行こそが、手動切り替えで通常つまずく箇所です。エージェントごとにプロバイダー設定の保存場所も形式も異なるからです。3つのエージェントを手動で設定すれば半日かかります。1コマンドで済むこと——これがエージェントユーザーを別に扱う理由です。

これが移行のすべてであり、両方の要素を含みます。つまり、代替サービスに実際のトラフィックを1日流し、古いキーも温存しておき、比較表ではなくエビデンスに基づいて判断できます。この比較表も含めて。

まとめ

OpenRouterは悪い製品ではなく、正直な記事ならそう書く必要があります。最大のカタログ、実際のコミュニティ、そして多くの良い働きをする無料プランがあります。

持っていないのは、スケールしても見えない手数料構造、決定論的なプロバイダールーティング、SLAです。この3つのうち1つがここに来た理由なら、打ち手は具体的です。プラットフォームの手数料を取り除く、上流を制御する、契約を買う。

そしてトラフィックの大部分がコーディングエージェントなら、プロキシを別のものに置き換えるのは、得られる利益の小さいほうです。各リクエストに実際に合ったモデルにルーティングすることこそが、請求額を下げる本丸です。

1つのAPIキーから始める