OpenRouter 料金を検証：Jev Routerは本当に無料なのか

Jev Routerは、OpenRouterが管理するtypesafe/jev-routerエンドポイントで、2026年9月25日に公開されました。各ターンに回答するモデルを選ぶチャットエンドポイントです。元のJev decision modelとも、よく似た名前のオープンソースCLIラッパーとも別の製品です。

OpenRouter 料金から見たJev Router無料説の検証結果

検証から言えることは、緑色の「無料」バッジが示す印象よりも限定的です。Jev Routerはプロンプトトークン、完了トークンともに$0と案内されていますが、選択されたモデルの総コストに関する説明は十分に明確ではなく、すべてのルーティング済みセッションが無料とは断定できません。

Jev Routerの公開ページは、2026年9月26日に確認しました。FAQでは、ルーターは無料で、プロンプトトークンと完了トークンに料金はかからないと説明されています。また、1,000,000トークンのコンテキストウィンドウを備え、会話の変化に応じてモデルとreasoning effortを選ぶ単一のエンドポイントだとされています。

一方、カタログには断定を妨げる情報が2つあります。同じ日にOpenRouterの公開Models APIを確認すると、ルーターのプロンプト料金と完了料金には通常の固定値ではなく-1が返されました。エンドポイント情報からは、プロバイダーエンドポイントが返されませんでした。これらの機械可読フィールドは課金の存在を証明しませんが、ページ上の$0表示をセッション別の明細に変えるものでもありません。

この記事の公開環境には、認証済みのOpenRouter APIキーも、ログイン済みのOpenRouterセッションも用意されていなかったため、課金対象になり得るリクエストは実行していません。したがって、この結論を裏づける実測のusage.costやActivity recordはありません。予算上は、$0をエンドポイントの表示価格として扱い、顧客や財務担当に推論が無料だと約束する前に、呼び出し全体を確認するのが妥当です。

9月25日に変わったこと

変化したのは、これまでルーターを作るための部品だったJevが、マネージドチャットエンドポイントの判断レイヤーに組み込まれたことです。

Jev 1.13はSystem Oneモデルで、文章ではなく制約付きの判断を返します。アプリケーションが状態を渡し、型付きのChoice、Score、またはyes/noのNoul質問を行います。モデルは「高性能tierを使う」と判断できますが、そのtierの呼び出し、会話履歴の保持、両方のリクエストのコスト計上は、依然として実装側の役割です。

マネージドルーターでは、この一連の処理がtypesafe/jev-routerに集約されます。OpenRouterの公開スレッドによると、Jevは各ターンの前にプロンプトの難易度と求められる精度を評価し、より大きなモデルや追加のreasoningが役立つか、タスクが変化したかを検討します。その後、OpenRouterが選択したモデルにターンを送り、生成されたテキストを返します。

オープンソースのgargpratyush/jev-routerは、新しいエンドポイントと特に混同しやすい存在です。このプロジェクトは実際のClaude CodeまたはCodex CLIを起動し、新しい各ターンでJevによる判断を1回行い、その結果をアカウント固有のtierに割り当て、CLIの既存認証を引き継ぎます。OpenRouterが管理するモデルslugではなく、課金経路も異なります。

この違いは実装そのものを変えます。従来のJevワークフローが提供するのは判断のプリミティブです。DIYルーターはコーディング用サブスクリプションを囲むローカルポリシーを提供します。マネージドエンドポイントでは、選ばれたモデルが出力を生成する一連の処理を1回のAPI呼び出しで利用できます。

Jev Routerは会話をどうルーティングするのか

Jev Routerは、次のメッセージの見た目が変わったという理由だけでモデルを切り替えないよう設計されています。切り替えによってプロバイダー側の会話キャッシュが失われ、新しいモデルが履歴全体を読み直す場合があるためです。

OpenRouterによれば、ルーターは問題なく機能しているモデルをセッションの残りでも維持し、モデルを替えずにreasoning effortを上げ下げできます。切り替えるのは、改善の見込みが失われるキャッシュのコストに見合う場合だけです。その判断のために会話テキストを読み取ります。公開スレッドでは、添付ファイルはJevに送られず、zdr: trueを使うリクエストにも対応すると説明されています。

これは単なるプロンプト単位の分類ではありません。簡単なフォローアップなら、切り替えよりキャッシュ維持の価値が高いため、低コストのモデルを使い続けることがあります。難しいターンでは、会話全体を別モデルへ移してコンテキストを読み直すコストを負わずに、reasoning effortだけを増やせます。タスク自体が変われば、ルーターはモデルを移せます。

ただし、本番運用には明確な壁があります。Jevの判断がタイムアウトするか無効な出力を返した場合、OpenRouterでは別のルーターにフォールバックせず、リクエスト自体が失敗します。一方、別プロジェクトのDIY版はfail-openで、現在のモデルまたはフォールバックモデルを使い続けます。つまり、マネージドエンドポイントを選ぶことは、単なる価格最適化機能の追加ではなく、クリティカルパスに新しい依存関係を受け入れることです。

OpenRouterの$0表示が対象にする範囲と、証明しないこと

$0表示が対象にしているのは、OpenRouterがJev Routerページで公開しているプロンプト料金と完了料金です。選択された有料モデル、reasoning token、キャッシュ読み取り、ツール、クレジット購入費がその金額の中でどう精算されるかについて、項目別の説明はありません。

OpenRouterの一般的な課金ルールでは、通常のリクエストは選択されたモデルとプロバイダーの料金で課金されます。一方、新しいJevページではルーターは無料とされています。選択モデルの推論を一時的に補助しているのか、別項目として転嫁するのか、それともローンチ固有の仕組みがあるのかは、どちらの情報源にも明記されていません。通常のAuto Routerルールをそのまま当てはめるのも、すべての有料モデル推論まで無料だと宣言するのも、いずれも推測になります。

最初の正解はレスポンスにあります。OpenRouterのusage accountingドキュメントによると、すべてのレスポンスにはプロンプト、完了、reasoning、cached-token、コストの情報が含まれます。usage.costはアカウントに課金された総額です。レスポンスのmodelフィールドは、回答したモデルを示します。

次に確認するのがgenerationの記録です。OpenRouterのLogsでは、モデル、プロバイダー、コスト、トークン数、レイテンシー、キャッシュ割引、BYOKコストのほか、web search、web fetch、file processingの料金も確認できます。集計用のActivity dashboardでは、支出、リクエスト、トークン種別、キャッシュヒット率が表示され、モデル、プロバイダー、キー、アプリ、ユーザーで絞り込めます。

これで、疑問のある各項目をどこで確認すべきかが明確になります。

• 選択モデル： 返されたmodelをusage.costおよびgenerationのtotal_costと照合します。
• Reasoning： completion_tokens_details.reasoning_tokensと、そのターンのルーティング説明を保存します。
• キャッシュ再利用： prompt_tokens_details.cached_tokensを保存し、generation詳細にキャッシュ割引があるか確認します。
• ツール： ベースラインテストでは無効にし、本番で有効にする前にgenerationの個別明細を確認します。
• クレジット手数料： 購入手数料は別に配賦します。OpenRouterの現行FAQでは、カード購入のクレジットに5.5%（最低$0.80）、暗号資産では5%と記載されています。これは資金調達時の手数料であり、Jev Routerの追加料金を示す証拠ではありません。

数字で見る：ルーター判断が無料でもセッションは無料とは限らない

ルーターの判断コストは、もともとごく小さいものです。経済性を左右するのは、Jevが適切なモデルを選び、有効なキャッシュを維持し、採用できる結果を返せるかどうかです。

まず、従来の明示的な判断ルートを見てみます。Jev 1.13は入力100万トークンあたり$0.042、出力100万トークンあたり$0です。ルーティング判断1回につき入力500トークン、合計100,000ターンと仮定すると、Jevの入力は5,000万トークンとなり、判断レイヤーの費用は**$2.10**です。各ターンに回答する生成モデルの費用は別途発生します。

マネージドページの表示料金では、同じルーター部分が$0になります。したがって、このワークロードで見かけ上節約できるのは、100,000回の判断あたり$2.10です。意味のある差ではありますが、それだけで製品を選ぶ根拠にはなりません。不適切なモデル切り替え1回の影響が、数千回分のJev判断を上回ることもあります。

過去のプロンプトが20,000トークンある会話を考えます。選択モデルの入力単価を100万トークンあたり$2とする例では、新しいモデルが履歴を読み直すだけで、キャッシュ割引や新しい出力を考慮する前に**$0.04**かかります。不要な切り替えが53回あれば$2.12となり、100,000ターンの例におけるJev 1.13の判断コスト全体をわずかに上回ります。

ここに、セッションを理解するルーターの長期的なコスト価値があります。適切なキャッシュを保てるかどうかは、ルーティング分類器を無料にすることより重要になり得ます。この計算は条件を明示したシナリオであり、Jev Routerが$2のモデルを選ぶ、あるいは53回の切り替えを回避するという主張ではありません。

性能を示す材料は有望ですが、まだ十分ではありません。OpenRouterは、4つのエージェントベンチマークにおいて、Jev Routerが全423タスク中237件、Auto Routerは130件を解き、82%多かったと報告しています。また、5つのエージェントベンチマークでは、テストした他の全ルーターよりも最初のトークンが返るまでの時間の中央値が短かったとしています。いずれもベンダーによる結果で、独立した再現検証ではありません。

Theo Browneは、9月26日のベンチマーク報告で有用な反証材料を示しました。$1,000を費やした結果、DeepSWEの性能はlow effortのGPT-6 Astraとほぼ同等で、料金はわずかに高く、待ち時間は5倍近かったと述べています。これは出典を明示したベンチマーク結果です。$1,000のルーター料金が発生した証拠ではなく、その投稿だけでは、この記事のコスト疑問を解決できるほど詳細なリクエスト別課金データは得られません。

購入判断で決め手になるのは、採用できたタスク1件あたりのコストです。

(selected-model cost + tools + allocated funding fee + retries + review time) / accepted tasks

$0のルーティング項目は、この分子を改善できます。しかし、残りの項目まで消すことはできません。

開発者・運用担当・購入担当への影響

開発者にとっては、統合が簡単になる一方、依存関係は重くなります。 OpenAI互換のモデルslugを1つ指定するだけで、自作の分類器、ポリシーテーブル、モデル呼び出し、セッションロジックの一部を置き換えられます。その代わり、ルーターはすべての回答の前段に入ります。文書化されたfail-closed動作を踏まえると、Jevの失敗時にアプリケーション側で対応できるようにする必要があります。たとえば1回だけ再試行する、ユーザーに再実行を依頼する、または自社ポリシーに従って固定モデルを意図的に呼び出す方法です。

最低限残すべきログは、response ID、要求したslug、選択モデル、ルーティング理由、reasoning effort、prompt token、cached token、completion token、reasoning token、usage.cost、レイテンシー、結果です。これらがなければ、モデル切り替えは理由不明の料金変動に見え、品質低下はエージェントの不具合に見えてしまいます。

運用担当は、トークン単価の表示ではなくセッション単位で管理すべきです。 サポートコパイロット、リサーチエージェント、コーディングワークフローでは、1つの会話の中に簡単なターン、難しいターン、タスクの転換が混在します。価値があるのは、難しいターンに見合う場合だけ多く支出し、不要な場合はキャッシュを維持することです。採用できたタスク、再試行、人による修正、セッション総額をまとめて測定してください。

購入担当は、予算表で推論、ルーティング、資金調達を分けるべきです。 エンドポイントに表示された$0はルーティング項目に計上します。選択モデルの総額は、実測後にusage項目へ入れます。search、fetch、file processingなどのツールは別項目のままにします。カード手数料5.5%はクレジット購入にかかるもので、架空のリクエスト別上乗せ料金ではありません。

プラットフォーム全体の請求については、既存のOpenRouter料金分析で共有クレジット、BYOK、購入手数料を解説しています。元のdecision modelを使うワークフローについては、Jevの使い方で型付きのチケットルーティングとJev 1.13の$0.042/Mという料金を扱っています。

今すぐ試すべき人、待つべき人、影響を受けない人

範囲が限定され、元に戻せるエージェントワークフローがあり、評価費用を$1未満に抑えられ、各generationをすでに記録しているなら、今すぐ試せます。非クリティカルなコーディングタスク、社内リサーチループ、シャドーモードのサポートアシスタントは、妥当な評価対象です。目的はルーティングが賢そうだと示すことではありません。同じプロンプトを固定モデルにも渡し、採用タスクあたりのコストとレイテンシーを比較することです。

顧客向けリクエストでfail-closedの依存関係を追加できない場合、変動するルートを本番投入する前に財務部門が正式な課金ルールを必要とする場合、あるいはプロンプトに含まれる規制対象データがプライバシーレビューを通過していない場合は、待つべきです。zero data retentionへの対応は有用ですが、自社のデータフロー承認の代わりにはなりません。

固定モデル1つですでに品質とレイテンシーの目標を達成している場合、ワークロードがJev 1.13に適した狭い型付き判断である場合、またはローカルDIYプロジェクトを介してClaude CodeとCodexのサブスクリプションを意図的にルーティングしている場合、影響はほとんどありません。マネージドルーターが安定した直接呼び出しより常に優れているわけではありません。

適応型の選択よりもプロバイダーを固定して制御できることが重要なら、クリティカルパスを移す前にマルチモデルルーティング向けOpenRouter代替サービスを比較してください。

Jev Routerの「無料」で誇張されていること

最も大きな誇張は、$0のモデルカードによってモデルエコシステム全体が無料になるという主張です。OpenRouterは、その主張を裏づけられるほどJev固有の課金詳細を公開しておらず、公開された機械可読カタログにも通常の固定ルートは示されていません。

逆方向の誇張は、隠れたルーター追加料金が必ず存在するという主張です。この検証では、追加料金の記載も実測もありませんでした。予測に勝手な上乗せ料金を加えるのは捏造です。

ベンチマークも、規模感を踏まえて読む必要があります。OpenRouterの82%というタスク改善の主張は、自社のAuto Routerを比較対象としたベンダーテストです。Theoの$1,000を使ったDeepSWEの報告は、ある実践者が1つの固定モデル設定と比較した結果です。どちらも、あなたのエージェントで採用タスクあたりのコストがいくらになるかは示しておらず、短期間のアカウント別照合作業に代わるものではありません。

また、1,000,000トークンのコンテキストウィンドウがあっても、100万トークンの会話が経済的になるとは限りません。長いセッションが効率的かどうかを決めるのは、選択モデル、キャッシュ動作、reasoning effort、タスクの変化です。コンテキスト上限は容量であって、予算ではありません。

月曜に実行する4リクエストのコスト確認

小さな合成リクエストを4つ実行すれば、料金ページをさらに1週間読み解くより多くのことが分かります。ツールは無効にし、機密データを使わず、短い出力を求め、usage.costの累計が$1に近づいたら中止してください。

最初のリクエストには、次の形をそのまま使えます。

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-OpenRouter-Metadata: enabled" \
  -d '{
    "model": "typesafe/jev-router",
    "messages": [
      {"role": "user", "content": "Return only the word READY."}
    ]
  }' | tee jev-router-response.json

続いて、レスポンスIDから対応するgeneration metadataを取得します。

GENERATION_ID=$(jq -r '.id' jev-router-response.json)
curl --get https://openrouter.ai/api/v1/generation \
  --data-urlencode "id=$GENERATION_ID" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

判断ルールは機械的です。

• 4つのレスポンスすべてでusage.cost: 0、4つのgeneration recordすべてでtotal costがゼロとなり、同じキーのActivity viewにも支出が追加されなければ、そのアカウントと日付で合成セッションのコストがゼロだったと実測できます。
• 1件でもゼロ以外の記録があれば、選択モデルとコスト内訳を確認します。カタログのバッジが何を示していても、そのリクエストについてエンドポイント全体が無料だったとは言えません。
• レスポンス、generation、Activityの内容が食い違う場合は、外挿しないでください。IDを保存し、どの記録が課金を決定するのかOpenRouterのサポートに確認します。

ベースラインの照合が済むまで、ツールを追加しないでください。search、fetch、file processingをエージェントに加えるときは、条件を統制したリクエストを1つ再実行し、それらのgeneration明細を別コストとして扱います。Jev Routerのモデルカードから推測してはいけません。

月曜に行うべきことは、4つのリクエストと4つの固定モデル対照リクエストを並行して実行し、セッションコスト、レイテンシー、採用できた出力、失敗率を比較することです。カタログの1行にゼロが2つ並んでいるからではなく、ルーティング判断によって結果全体が改善する場合にのみJev Routerを採用してください。

次に確認されたモデルルーティングの変更と予算への影響は、ニュースレターでお届けします。