jev-model-routing

Jev によるモデルルーティング

Jev は1回の約0.4秒のリクエストでターンを読み取り、3つの質問に答えます。難易度はどの程度か、どのような種類の作業か、間違えた場合にどれほどの損失があるか、です。その後、コードがそのティアと専門分野に対応するプールを順に確認し、条件（画像、コンテキストサイズ）に合う最初のモデルを選びます。感覚でモデルを選ぶのではなく、尋ねて選びます。

Hermes では自動で行われます

hermes-jev プラグインが有効な場合、新しいユーザーターンごとに、最初のモデル呼び出しの前に1回だけルーティングされます。ツールループ内の後続リクエストでは、プロバイダー、エンドポイント、ホストモデル、送信リクエストのモデルが変わらない限り、その判断が再利用されます。不一致があると、そのターンの残りの間はルーティングが無効になります。A → B → A と戻る場合も同様で、分類器にもう一度回答させることはありません。最初の送信モデルがホストのメタデータと一致しない場合は、送信リクエストをそのまま使用し、分類は行いません。同等のプロバイダープレフィックスは正規化されます。次のターンでは判断がリセットされます。エンドポイントのバインディングはメモリ内に保持され、テレメトリには書き込まれません。プロファイルごとの切り替え項目は次のとおりです。

/jev                    status
/jev routing shadow     decide and log, but do not switch (start here)
/jev routing on         switch models
/jev routing off
/jev notice on          show "[Jev] medium · coding → kimi-k2.7-code · confidence 0.97" on routed replies

プラグインで切り替えられるのはモデルであり、プロバイダー接続ではありません。OpenRouter では、それでもすべてのベンダー（DeepSeek、GLM、Kimi、MiniMax、Grok、Qwen、Gemini、GPT）が対象になります。自分で /model を実行した場合は、その選択が優先され、Jev は介入しません。

Hermes の custom プロバイダーでは、プラグインは背後で使われている models.dev のプロバイダーを推測できません。その場合、現在のモデルを維持し、無関係なプールを原因として挙げる代わりに custom provider needs an explicit provider_aliases.custom とログに記録します。そのエンドポイントが実際にプールのモデルを提供している場合に限り、routing.json に "provider_aliases": {"custom": "venice"} を設定します（venice は実際のプールプレフィックスに置き換えてください）。ルーティングを有効にする前に、エンドポイントとプール内のすべてのモデルを確認してください。エイリアスは運用担当者による宣言であり、プロバイダーを横断した検出機能ではありません。これは、現在有効なルーティングモードを編集するものではありません。

直接尋ねる（あらゆるエージェント向け）

タスクを委任したり、サブエージェントを起動したりする前に、どのモデルに任せるべきかを尋ねます。

jev route --prompt "<the task, in the person's words>" --current "<provider:model you are on>"

回答の model_id を使用してください。routed: false の場合は、現在のモデルを使い続けます。reason に理由が記載されています。ルーティングの情報を相手に伝えたい場合は、notice を伝えてください。

努力レベルの引き継ぎと根拠

none や off を含め、明示的に手動設定された努力レベルは保持してください。Chat Completions ではトップレベルの reasoning_effort を使用します。Responses では、推論オブジェクトがすでに有効であり、努力レベルが明示的に設定されていない場合に限り、reasoning.effort を使用します。無効になっている推論を有効にしたり、変更のないリクエストに対して適用済み努力レベルの通知を出したりしないでください。Shadow は引き続き観察のみを行います。利用可能なプールは有効な設定ではありません。また、モデルの確信度はタスクに応じて限定的に解釈する必要があります。フリートのガイダンスと測定／プロヴェナンスを参照してください。

レーン：タスクを委任し、その後の各ステップを進める

サブエージェントやワーカーに任せる作業では、正しく完了できる範囲で、最小のモデルと最低限の労力で仕上げます。Jev は判断を行いますが、コードを書いたり、パッチを作成したり、設計したりすることはありません。

jev lane classify --task "<the work, in the person's words>"        # first lane + model/effort
jev lane step --task "..." --lane <lane> --attempt <n> \
    --run "<test cmd>" --run "<lint/typecheck cmd>" --scope "<path glob>"   # after each cycle

レーン	Claude Code（サブエージェント）	Hermes Kanban カード（デフォルトのマップ）
small	jev-lane-small：Haiku、低	gpt-5.6-luna、中
medium	jev-lane-medium：Sonnet、中	gpt-6-sol、中（本日のデフォルト）
high	jev-lane-high：Opus、中	gpt-6-sol、中
escalate	jev-lane-escalate：Opus、高	gpt-6-astra、高

jev lane targets --host hermes で有効なマップを確認できます。<hermes root>/jev/lanes.json（または ~/.config/jev/lanes.json）を使って各フィールドを上書きできます。Hermes のマップは、あるフリートの実績を基に調整されています（docs/lanes.md を参照）。jev lane replay-build / replay-report を使って、ご自身の環境で再測定してください。

• 依頼は一度に、質問はすべてまとめて。 classify は、レーン（先に人が確認すべき作業向けの other という選択肢を含む）、セキュリティ上の機微度、仕様不足について一度に尋ねます。コードがしきい値を適用します。small を選ぶには信頼度が 0.7 以上必要です。medium の信頼度が 0.5 未満の場合は high に進みます。セキュリティの値が 0.7 以上なら、少なくとも high です。keep_current は現在のモデルを維持するという意味です（自分で作業するか、依頼してください）。
• まずコードで判断。 人が指定したモデル、2 回の失敗、またはご自身によるセキュリティ経路の確認があれば、Jev に尋ねずに判断します。
• まず決定的なチェックを実行。 step は、指定されたテスト、コンパイラー、型チェッカー、リンターを実行し、git diff を読み取ります。チェックに失敗した場合は retry（同じレーンで 2 回失敗した場合は escalate）です。--scope の範囲外のファイルがあれば retry、未実行のチェックがあれば verify です。small または medium でセキュリティ関連ファイルが変更されている場合は escalate です。Jev に尋ねるのは、残った点だけです。実装されているか、範囲内か、次に何をするかを確認します。
• 根拠がある場合に限り、レーンを一段ずつ上げます。 最上位のレーンから escalate した場合は person が返されます。
• 完了は、条件を満たして初めて認められます。 チェックが実行されて成功し、diff が範囲内に収まっていない限り、complete は拒否され（verify に変わり、complete_refused が付与されます）。チェックに失敗した場合は、その旨を伝えてください。決して隠してはいけません。
• 長いチェック出力の末尾だけが Jev に渡されます。エージェント自身の推論を要約したり、フィルタリングしたりしてはいけません。
• Jev が停止している場合、classify は現在のモデルを維持し、step は verify を返します。
• --run は一行のコマンドではなく、スクリプトにしてください。 シェルで実行されるため、パイプや && は使えますが、根拠として出力されるコマンドは途中で切れてしまい、どの処理が成功したか読み手にはわかりません。正確なコミットと各終了コードを確認し、各ゲートについて ok: / FAIL: を出力する小さなスクリプトを使うと、根拠が読みやすくなります。同じログに以前の失敗した試行が残っていると、別の実行の結果を誤って失敗または成功と判定するため、必ずこのサイクルの結果だけを読み取るようにしてください。
• 読み取り専用の作業には --no-changes-expected を指定。 レビューや報告の場合は、その旨を伝えてください。そうしないと、空の diff が何もしていないように見えます。
• 判断がまだ確定していない状態で escalate した場合は person です。 事実を確認済みのレビュー後に、オーナーが選ぶべき判断（受け入れるリスクや選択するアプローチ）が残っている場合、より強力なモデルでも決着はつきません。レーンを上げて作業を再実行するのではなく、判断を人に委ねてください。

Hermes では、jev lane shadow（cron から実行）が新しい Kanban カードを分類し、選択するはずの内容を記録します。/jev lanes shadow|on|off で切り替えます。<hermes root>/jev/LANES_OFF が優先されます。on にすると、ディスパッチ前にカードのモデルと労力が設定されます。jev lane shadow-report で、初回の成功率を維持したままトークン数が減ることを確認し、オーナーの承認を得てから有効にしてください。

プール

jev models list は、このマシンから呼び出せるすべてのモデル（models.dev のカタログを、キーを持っている、またはログイン済みのプロバイダーに絞り込んだもの）を、価格、コンテキスト、機能とともに表示します。プールは ~/.hermes/jev/routing.json（または ~/.config/jev/routing.json）に保存されています。

{"tiers": {"simple": {"general": ["openrouter:deepseek/deepseek-v4.1-flash"], "coding": ["..."]},
           "medium": {"general": ["..."], "coding": ["..."], "research": ["..."], "writing": ["..."], "vision": ["..."]},
           "hard":   {"general": ["..."], "coding": ["..."]}},
 "exclude": ["*:free"], "private_profiles": ["billing"], "mode": "redacted-text"}

• jev models suggest --write は、価格帯に基づいて最初の案を作成します。その後、編集してください。順序が重要で、最初に条件に合ったモデルが選ばれます。
• 専門分野は general、coding、writing、research、vision です。専門分野が指定されていない場合は general にフォールバックします。プールが下位の階層に下がることはなく、上位に移動するのみです。
• ユーザーが用途に合うモデルを指定した場合は、そのモデルを該当するプールの先頭に配置してください。モデル ID を推測で作らず、jev models list --search <name> からコピーしてください。

信頼できる保証

• Hard は根拠に基づいて選ばれます。Jev が返すレベル別の分布を読み取り、「substantial」または「expert」に実質的な確率質量（デフォルトでは 0.6）がある場合に限られ、平均スコアから判断されることはありません。
• Unsure は hard ではありません。無害なターンについて unsure の回答が返った場合は現在のモデルを維持し、リスクのあるターンの場合は medium を選びます。
• リスクを示す語（production、delete、migration、security、payment、legal など）があれば、プロンプトがどれほど短くても最低ランクは medium になります。ただし、それだけで hard ランクになることはありません。
• Jev が判定するのは依頼内容です。長いターンは、冒頭と、主に末尾（ask_chars）を読み取って判断します。途中の定型文がスコアの対象になるわけではありません。
• 推論の労力設定はデフォルトでオフであり、ルーティングが on の場合にのみ標準の reasoning_effort フィールドを書き込みます。正確なプロバイダー:model の機能マップを指定してオプトインします。例："effort": {"enabled": true, "levels": ["low", "medium", "high", "high"], "models": {"openrouter:your-verified-model-id": ["low", "medium", "high"]}}。例の ID は、これらのレベルを受け入れることを実際に確認済みのモデルに置き換えてください。xhigh はサポートされていると想定されません。要求するレベルは、該当するモデルの許可リストに含まれている必要があります。また、既存の reasoning_effort または extra_body.reasoning が常に優先されます。Shadow/off はリクエストを変更しません。この選択では、追加の Jev 呼び出しを行わず、ルーティングの難易度判定の回答を再利用します。設定が未対応または不正な場合は、設定なしとして続行します。インストールによって fleet の労力設定やライブのルーティングが有効になることはありません。
• テンプレートターンはルーティングされません。skip_prefixes の項目（[kanban]、[SESSION HANDOFF など）で始まるものや、skip_session_prefixes のセッション（cron）からのものは、プロファイルまたはジョブで設定されたモデルを維持します。
• コンテキストが大きい場合（sticky_context_tokens を厳密に超える場合。デフォルトは約 32k）：プロンプトキャッシュの再構築に節約額以上のコストがかかるため、より安価なモデルには決して切り替えません。どちらかのモデルのカタログ価格が不明な場合も、安全策として現在のモデルを維持します。キャッシュキーには、大まかなコンテキスト区分だけでなく、このガード条件のどちら側に該当するかが正確に含まれます。
• オプトインした労力設定ルーティングでは、解決済みのルーティングランクより低く設定することはできません。medium では難易度バケットの最低値が routine に、hard では substantial になります。unsure によって維持された判断にも、少なくとも routine が適用されます。大きなコンテキストでモデルを維持する場合は、モデルの切り替えやエスカレーションを行わず、effort_tier を通じて解決済みの最低ランクが維持されます。呼び出し元が明示した労力設定と、正確なモデルの機能チェックは引き続き優先されます。
• 秘密情報が含まれているように見えるターンや、private_profiles に記載されたプロファイルでは、Jev に送信されるのは粗い特徴（長さ、コードの有無、リスクを示す語）のみで、テキストは送信されません。これらのターンと、mode: features のプロファイルは、以下の統合リクエストの対象からも除外されます。
• 通常、Jev への 3 つの質問は、スキル選択のステージ 1（jevkit/turn.py）と同じリクエストで送信されます。Jev は質問ごとではなくリクエストごとに課金し、その下の接続はプールされるためです（以前は呼び出しのたびに新しい TLS セッションを確立しており、判断にかかる約 520 ms のうち約 275 ms を占めていました）。2026-09-21/22 のライブ計測では、ウォーム時の質問 1 件あたり約 180～250 ms、両方を必要とするターンでは 1 ターンあたり 1784 ms → 672 ms、リクエスト数は 3 件から 2 件になりました。各特徴は、引き続きそれぞれ独自のしきい値を使って回答を読み取ります。/jev merge_requests off で再び個別にできます。
• Jev が停止中、応答が遅い（2.5 秒の予算を超える）、または形式が不正な場合は、現在のモデルを維持し、予算を超える遅延は発生しません。回答に矛盾がある場合（分布が選択肢を網羅していない、確率質量の合計が 1 にならない、選択された項目が最大ではない、スコアが自身の分布と一致しないなど）は、invalid_response として拒否され、同様にここへ該当します。

調整

プロンプトテキストを含めずに、判断内容が <hermes home>/logs/jev-decisions.jsonl に記録されます。1 日間 shadow で実行し、実際のターンがどのランクに分類されるかを確認してから、モデルをプール間で移動してください。しきい値は勘ではなく、自分のトレースに基づいて変更してください。