OrcaRouter ルーティング基盤: セッション対応ルーティングとフロンティアエスカレーション

ORCAROUTER · ルーティングアーキテクチャ

プロンプトをキャッシュするLLMゲートウェイは、会話を単一のモデルに固定しなければならない。会話を固定するすべてのゲートウェイは、その会話の中で最も情報量の少ないターンに基づいてルーティング判断を行う。本稿は、そのトレードオフと、OrcaRouterがそこから逃れるために搭載している階層型スティッキネス機構についての報告である。

件名： OrcaRouter LLMゲートウェイ (Go / Gin / Redis) · コンポーネント： セッションアフィニティ + Frontier Escalationエンジン · 方法： 本番判定コードに対する400セッションのリプレイ · 日付： 2026年8月14日

要約リクエストレベルでのLLMルーティング——各リクエストを独立に評価し、最も安価で適切なモデルへ振り分ける——は、発表されたルーター研究のほぼすべてが扱う方式である。しかし、この方式は、現在ゲートウェイのトラフィック量の大半を占めるトラフィック、すなわちマルチターンのエージェントセッションにとっては、誤った方式でもある。そこでは、プロンプトの90%が引き継がれたコンテキストであり、プロバイダーのプロンプトキャッシュが継続性に報いる。会話の途中でモデルを切り替えると、共有プレフィックスに対する10倍の割引を失うため、ゲートウェイはセッションを固定する。しかし、ターン1での固定は、最も根拠が少ない時点での固定であり、会話の存続期間中ずっと持続する。

100 / 100 — ターン1のスコアが自明なものと区別できない潜在的に難しいセッション

+16% — 同一のタスク難易度において、文字起こしの長さだけから生じる難易度スコアの変動

45% — always-frontier コストに対する割合で、そのハードターン適用範囲の 67% をカバー

0.019 — 出荷時ゲートと現実的なスコアの上限の差

1 2つのルーティング方式

多数のプロバイダーを束ねるLLMゲートウェイは、リクエストごとに1つの問いに答えなければならない：どのモデルがこのリクエストを処理するのか？ それに答える方法には構造的に異なる2つがあり、どちらが重要かについては、文献と実際の運用現場で認識が乖離している。

リクエストレベルのルーティングは、各リクエストを独立したものとして扱います。スコアラーはクエリの難易度や予測応答品質を推定し、リクエストはそれを処理できると期待される最も安価なモデルに割り当てられます。これは、発表されたほぼすべてのルータ研究が該当する枠組みです：RouteLLMは選好データルータを訓練し、GPT-4の品質の95%を14%の強力モデル呼び出しで達成しますsup>[1]/sup>；FrugalGPTは、受理/拒否チェックを伴う安価から高価へのカスケードを行い、最大98%のコスト削減を報告していますsup>[2]/sup>；RouterArenaは、ルータをまさにこの軸で比較するための8,400クエリのベンチマークを構築していますsup>[3]/sup>。分析の単位はクエリです。

セッション対応ルーティング

セッション認識ルーティングが存在する理由は、優雅さではない。それは算術だ。

2 粘着性を必須にするキャッシュ経済

マルチターンのエージェントセッションでは、ターンnのプロンプトはターンn−1のプロンプトにデルタを加えたものになります。ターン10までには、引き継がれたプレフィックスが入力トークンの圧倒的大部分を占めます。現在、主要プロバイダーはすべて、キャッシュヒットかどうかに応じてそのプレフィックスに異なる料金を設定しています：

表1.プロバイダー別のプロンプトキャッシュのセマンティクス。キャッシュは正確なプレフィックスとサービングキーをキーとしており、モデルの切り替えやキーのローテーションは全額課金のコールドリードとなる。

OrcaRouterは、これらの生存期間をピンTTLとして正確にエンコードします。プロバイダーのキャッシュウィンドウのチャネルタイプ別マップであり、OpenAI、Anthropic、Geminiは5分、DeepSeekは60分、マップ未登録プロバイダーのデフォルトは5分です。チャネル+キーのピンはこのウィンドウで失効します。古いキーインデックスにはキャッシュ価値がなく、ロードバランシングを歪めるだけだからです。モデルのピンは、Redisバックエンドのデプロイメントにおいて、長期ピン対象セッションIDの場合、30日間持続します。これはキャッシュ価値のためではなく（キャッシュ価値はとっくに消えています）、リクエスト形式の継続性のためです。会話途中のモデル切替は、データ非互換となり得るリクエスト形式の変換を強制します。思考ブロックとツール呼び出しIDは、プロバイダースキーマ間の変換後には必ずしも存続しません。

過小評価されがちなディテール

プロンプトキャッシュのキー設定はAPIキーごとであり、モデルごとではありません。モデルを固定するものの、同じチャネル上の3つのキーに負荷分散するゲートウェイでは、それでも3回中2回はコールドリードになります。これが、OrcaRouterのチャネルピンがチャネルIDではなく{ChannelID, KeyIndex}を格納する理由であり、記録されたキーインデックスが有効なキーに解決されなくなったときにピンが破棄される理由でもあります。というのも、ブーストされたがローテーションされたキーは、バランシングを迂回しながらコールドキャッシュに偏り、両方の悪い点を併せ持つ最悪のケースとなるからです。

ピンは全体を通じてソフトです。解決できないセッションIDはノーオペレーションとなり、無効または不健全なピン留めチャネルは通常のバランス選択に縮退し、混合プール内のウェイトゼロのチャネルへのピンは破棄されるため、チャネルをドレインしている管理者が粘着性によって妨げられることはありません。これらがリクエストを失敗させることは決してありません。

3 罠：スティッキネスがルーターを無効にする

失敗モードは次のとおりです。OrcaRouterのエスカレーション前のコードパスでは、任意の非DSLストラテジー上のセッション対応ルーターについて、session→modelピンが返されました

ターン1が代表的であるなら、それは許容できるだろう。しかし、2つの複合的な理由により、それは体系的にそうではない。

3.1 ターン1は最も情報が少ないターンです。

難易度スカラー（service/model_router_difficulty.go）は、6つの語彙特徴量に対する重み付き線形結合です：

LogPromptTokens × 0.20 上限 log(8001) ≈ 8.99

ReasoningCueCount × 0.15 上限5

SystemPromptLogLen × 0.10 上限 log(2001) ≈ 7.60

CodeKeywordDensity × 0.20 上限5.0（100文字あたりの一致数）

HasTools × 0.15 既に 0/1

MathMarkerCount × 0.20 上限 5

履歴のない短い冒頭発言は、ほぼ構造上、低いスコアになります。重み0.20のトークン項は下限に近く、推論・数学系の項は、ユーザーがまだ使う理由のなかった語彙に対して発動するからです。したがってセッションは、情報が最も少ない時点で弱いプールモデルにコミットすることになり——そしてRedisバックアップによる30日間のモデルピンがあるため、そのコミットメントは長く続きます。

図1. 会話ターンごとの最新ターンの難易度の平均（潜在的に難しいセッション100件と本当に易しいセッション200件にわたり、本番スコアラーによってスコアリングされた）。ターン1（スティッキーピンが書き込まれるターン）では、2つの集団は区別できない（0.210 対 0.208）。難しい集団はターン5でゲートを通過する。ピンのみのポリシーの下では、100件の潜在的に難しいセッションすべてが、そのような証拠が一切存在しないうちに安価なプールにコミットされる。

3.2 長さは難しさを装う

2つ目の問題はより微妙で、明白な修正策を損なう。毎ターン単に難易度ゲートを再実行するなら、その再実行は連結されたトランスクリプト全体に基づいて計算されたスコアを用いて行われることになる。そのスコアには上昇ドリフトが組み込まれている。重み0.20のLogPromptTokens項は会話の長さとともに単調に増加し、どのエージェントセッションでも重み0.15のHasTools項と重み0.10のSystemPromptLogLen項は事実上一定の下限である。長く退屈なセッションは、次第に難しく見えてくる。

図2.長さバイアスのアーティファクト。些細な編集（「この変数の名前を変更」「nilチェックを追加」）のみからなる60セッションで測定した。完全なトランスクリプトのスコアは、タスク難易度が一定のまま25ターンにわたって+16%ドリフトし、最新ターン（デルタ）のスコアは横ばいである。毎ターン完全なトランスクリプトのスコアを単純に再評価すると、セッションが長いという罪でエスカレーションされてしまうだろう。

OrcaRouterが提供する修正は、独立したdelta抽出器（service/model_router_delta.go）であり、最後のアシスタントメッセージの後に付加された新しいユーザーテキストとツール結果、つまり最新のターンのみをスコアリングします。同じ重みと上限を再利用しますが、deltaの一部ではないSystemPromptLogLenは意図的にゼロにします。図2の平坦な青い線がこの抽出器です。

4 デザイン：段階的スティッキネス

{{1}}ターン1ロックイン{{/1}}から逃れる素朴な方法は、毎ターンを再ルーティングすることだ——それは単なる{{2}}リクエストレベルのルーティング{{/2}}であり、キャッシュを失う。逆方向の素朴な修正は、ピンを{{3}}「このセッションは難しくなった」{{/3}}という記憶にすることだ——しかしこれではデエスカレーションを表現できず、上限も設けられない。{{4}}OrcaRouterの設計{{/4}}はその両方を拒否する。

捉え直し：セッションはティア内のモデルに固定される。そして、小さなRedisのティア状態が唯一のエスカレーションメモリである。モデルの固定は決してメモリではない。

ティアプール。強ティアは、解決済みのエスカレーションプールです（escalation_pool。デフォルトではルーターのstrong_poolになります）。ベースティアはAllowedModels \ 強ティアプールです。両方に含まれるモデルは強ティアに属します。ベースティア内では、gated_adaptiveの弱/中/強の難易度バンディングが、以前とまったく同じように機能し続けます。

階層スコープのピン。 強力階層のモデルピンキーには :t:strong サフィックスが付きます。基本階層は従来のキーをそのまま保持します。したがって、エスカレーションが保持するのは基本ピンであり、そのため、エスカレーション解除されたセッション（または、階層状態の有効期限が切れた後に再開されたセッション）は、任意の再選択ではなく、開始時とまったく同じモデルに戻ります。強力なピンはプロバイダーウィンドウの短いTTLのみで書き込まれます。30日間の強力なピンは、それを正当化した4時間の階層状態よりも長く存続することになります。

ゲートは最初に実行される。selectByStrategy (service/model_router.go:1374) では、最初にティアが特定され、候補セットはそのティアのプールに絞り込まれ、そしてそのときになって初めて、そのティア内でスティッキーピンが参照される。これが§3に対する構造的修正である：難易度計算とエスカレーションのトリガーは、ピンがそれらを短絡させる前に、毎ターン実行される。

4.1 信頼度でランク付けされた3つのトリガークラス

表2.エスカレーションのトリガー。曖昧なシグナルが単独でエスカレーションすることは決してありません。明示的なクライアントの要請のみがn=1でコミットされ、それも上限に従います。

3つの衛生不変条件が構造を支えている。ストライクはリングバッファを通じてリクエストIDによって重複排除されるため、インターリーブされたクライアントのリトライが二重カウントされることはない。インフラストラクチャ障害は決して能力障害ではない — 429、5xx、チャネルフォールバックは決してストライクにならず、成功後の品質シグナルのみがカウントされる。また「ターン」とは、ストライク評価を実行した、完了済みかつ課金成功済みのリクエストとして定義される。したがって、失敗したリクエストは、ストライクの減衰もクリーンターンカウンターも進めない。

4.2 解決は純粋であり、コミットは延期される

このエンジンで最も重要な構造的特性は、ResolveEscalationが何も書き込まないことである。ResolveEscalationは、決定と保留中のインテントのリストを返す。ディストリビューターは、post-successブロック内で、それらのインテントをRedis WATCHトランザクション内の新しい読み取りに適用する。これは重要な意味を持つ。なぜなら、リゾルバーは状態を決して変更してはならないパス上で実行されるからである。すなわち、投機的なフォールバックチェーン解決、読み取り専用の診断エンドポイント、および後で403を返すか上流で失敗するリクエストである。インテントを新しい状態に再適用することは、古い並行ライターがコミット済みのエスカレーションを上書きできないことも意味し、競合する2つの同一のエスカレーションは冪等的にマージされる。

4.3 Capsと、なぜそれらがすべてを束縛するのか

偽陽性エスカレーションは、(strong − base) 価格 × 残りのウォームエピソードトークンをコストとして発生させ、しかもそれを静かに発生させる — 何も失敗しない。爆発半径は上限によって制限される。それらが適用されるのはすべてのクラス:

escalation_max_per_session（デフォルト: 1）。デエスカレーションとクライアントのリセットではそれが返金されないため、リセットループを悪用する経路は閉ざされます。

ルーターごとのエスカレーションシェア上限（デフォルト20%）は、Redisの日次バケットの直近24〜48時間のウィンドウにわたって適用され、さらにワークスペース全体のクロスルーター上限もあります。上限に達すると、すべてのエスカレーションルーティングが抑制されます（明示的なリクエストやワンスブーストを含む）。

デエスカレーションはキャッシュ・コールド境界でのみ行われるため、誤検知は1回のウォーム・エピソードに限定される。

Class Aがキャップに従う理由は、ポリシー選好ではなく脅威モデルに基づく結論である。APIゲートウェイでは、ワークスペーストークンを保持する者がヘッダーを制御できるため、「クライアントが要求した」というキャップ適用除外の経路は未計測の支出経路となる。§7は、すべてのクライアントがそれを悪用した場合に何が起こるかを測定する。

4.4 デエスカレーションは設計上、非対称である

裏付けのある証拠に基づいてエスカレーションし、無料の場合にのみデエスカレーションする。強いセッションがベースに戻るのは、すべての条件を満たした場合のみである: セッションがキャッシュコールドであり（エスカレーション時に記録されたプロバイダーウィンドウを超えてアイドル状態）、ストライクなしの評価ターンを3以上蓄積しており、かつ最新のデルタ難易度がT1未満である。ウォームウィンドウ内では、切り替えは全額のコールド再読み取りを伴う — フラッピングは、エスカレーションのコストをマイナスにする唯一確実な方法である。

5 方法

私たちは、合成セッションコーパスをリプレイし、そのメカニズムを計測しました。その際に経由したのは実際の本番判定コードです。ハーネスは、サービスパッケージ内のGoテストであり、miniredisをバックエンドとするティアストアに対して、毎ターンResolveEscalationとCommitEscalationDecisionを呼び出し、実際の難易度スコアラー、実際のリクエスト側ストライク生成器、実際のシェアキャップ機構を使用します。決定パスに関しては、監査イベントシンクを除いて、再実装もモックもされていません。

何が現実で、何が現実でないのか

実際:すべてのルーティング決定、難易度スコア、ストライク検出、ストリークルール、キャップ評価、そして Redis 状態遷移—これらが出荷された機能です。合成:トラフィック。コーパスは生成されたものであり、本番ログからサンプリングされたものではありません。そのアーキタイプ構成（ハード50%）は、メカニズムを動かすために選ばれたストレス構成であり、実トラフィックの推定ではありません。§6.4 はその選択に対する感度を報告しており、その感度は大きい。以下のクリーンな精度数値は、構成上クラスが分離可能なコーパスを反映しており、「メカニズムが設計された箇所で作動する」という意味で読むべきであり、本番の精度推定としては読むべきではありません。

5.1 コーパス

400セッション、3,968ターン、シード付きで決定論的。各ターンは、累積履歴、2つのツール定義配列、現実的なシステムプロンプトを運ぶ完全なchat-completionsリクエストボディ — コーディングエージェントが実際に送信する形式だ。5つのアーキタイプがあり、それぞれにグラウンドトゥルースラベルが付いている：

表3.コーパス構成。「Needs strong」は、適合率とカバレッジのスコアに使用されるグラウンドトゥルースです。

ハードターンには、散文に加えて、貼り付けられたgoroutineダンプまたは3〜8KBのソースコード抜粋が含まれる。なぜなら、それが実際の困難なデバッグターンに含まれるものだからだ。この詳細は非常に重要であることが判明した — §6.2を参照。

5.2 コストモデル

コストは公開されたリスト価格からプロバイダーごとのキャッシュセマンティクスにより計算され、モデルは完全に記述されているため、異議を唱えることができます。

表4.コストモデルのパラメータ。価格は100万トークンあたり米ドル、2026年8月時点のリスト価格。

ウォームターンのコストは 0.1·p_in·prefix + write·p_in·delta です。コールドターンのコストは write·p_in·prompt です。ターン1は常に完全なキャッシュ書き込みです。エスカレーションポリシーによるティア切り替えターンは明示的にコールドとして課金されるため、このメカニズムは自身のキャッシュ無効化のコストを負担します。

品質は、ハードターンカバレッジとして報告されます。これは（強力なモデルが実際に応答したグラウンドトゥルース上でハードなターンの割合）であり、精度の数値として報告されるものではありません。私たちは上流の推論を実行していないため、精度の数値をでっち上げることは控えます。

6 結果

6.1 メカニズムは設計された場所で作動する

表5.アーキタイプ別のエスカレーション結果、自動モード、カナリア100%、T2 = 0.70（出荷時デフォルト）。

200件の易しいセッションで偽陽性ゼロ。その中には、全文書き起こしスコアラーなら高難易度帯域に入り込んでいたであろう60件の長時間セッションも含まれる。トリガークラスは綺麗に特化しており、重複もない：難易度は推論を多用する作業を捉え、ストライクは失敗ループを捉える。なお、failure_loopのピーク難易度スコアは0.262であり、難易度ゲートはそれらのセッションを一切見ることがない。コンパイルエラーループに陥ったエージェントは、推論の手がかりが密集した散文を生成しているのではなく、異なるスタックトレースを持つ同じ短いプロンプトを生成している。クラスCストライクがなければ、それら60件のセッションはすべて低コストモデル上で延々と稼働し続けることになる。

図3。セッションがエスカレーションする場合、トリガー別に分割する。ストライク駆動のエスカレーションは、ターン4（減衰ウィンドウ内に2回のストライクが蓄積され得る最初のターン）に著しく集中している。一方、難易度駆動のエスカレーションは、コーパスの開始分布に従って、ターン2〜11にわたって分散している。2ターン連続のストリークルールでは、難易度エスカレーションの発生は最も早くてもターン2になる。

6.2 所見：出荷されたゲートは崖の端に位置している

最初のコーパスが生み出したのはゼロ件の難易度駆動エスカレーションでした。レースコンディション、不変条件、複雑性解析、証明の語彙を満載したハードなターンは、0.70のゲートに対して0.658でピークに達しました。実際のデバッグターンに付随する貼り付け済みスタックトレースを追加すると、それらは0.719に押し上げられました。ゲートは0.019の差で通過しました。

図4.難易度予算が実際にどこに使われるのか。難しいターン855回と簡単なターン3,113回の平均。現実的な難しいターンは、理論上の最大デルタ0.90に対して0.719に達する。CodeKeywordDensity項は0.20の予算のうち0.069を寄与し（測定密度は飽和上限5.0に対して100文字あたり1.72マッチ）、SystemPromptLogLenの0.10はデルタ抽出器では構造的にゼロである。スコアの公称レンジの約3分の1は、現実的なテキストでは到達不能である。

しきい値スイープにより、これは勾配ではなく崖であることが確認される。{{1}}T2を0.35から0.65まで変えても結果は同一で{{/1}}、400セッション中200セッションがエスカレーションし、見逃しはゼロである。{{2}}出荷時の0.70では分類器がセッションを失い始め{{/2}}、{{3}}0.75では困難度によるエスカレーションが122セッションから23セッションへと激減する{{/3}}。

図5．閾値感度。0.35–0.65の範囲全体は挙動として同一である。現実的なデルタテキストがこの範囲に入ることはないためだ。スコア分布は二峰性で、簡単なターンは0.23付近に、難しいターンは0.72付近に集中し、その中間には何もない。出荷時のデフォルト値は、上位モードの上端に位置する。

工学的含意

T2は較正されており、その較正対象は全文トランスクリプト分布（gated_adaptive bandsが調整されたもの）である。また、このT2はデルタ抽出器のしきい値として再利用されている。設計ドキュメントは、デルタ抽出器が「独自のチューニングを必要とする」と指摘しており、この測定はその程度を定量化する。デルタゲートには独自のより低いT2が必要である（0.45〜0.60のどこでも、実際のマージンを持って同一の挙動が得られる）か、あるいはすでにフェーズ3で予定されているパーセンタイルベースのしきい値（「このルーターの最近のトラフィックの上位X%」）が導入されるべきである。それにより、エスカレーション率が運用者の調整手段となり、絶対的な較正を完全に回避する。

6.3 コストと適用範囲

図6.同じ400セッションにおける5つのポリシー。左：1,000セッションあたりのコスト（対数目盛）。右：強力なモデルが対応した真に困難なターンの割合。

表6.ポリシー比較。表4モデルにおける1,000セッションあたりのコスト。

分けて考える価値のある結果が2つあります。まず、同一モデル選択において、セッションアフィニティだけで24%の節約 (16.64 → 12.63) 、フロンティアペアでは35% (290.93 → 188.30)。これは純粋なキャッシュ経済です。モデルもその他すべて同じで、キーの粘着性だけが異なります。フロンティアペアでの節約が大きいのは、Anthropicの1.25倍の書き込みプレミアムにより、コールドターンが不釣り合いに高コストになるためです。

第二に、エスカレーションは救助メカニズムが果たすべき役割を果たします：常時フロンティアのコストの45%で、そのハードターンカバレッジの67%を実現し、強力なモデルをわずか21.4%のターンでのみ利用します。

カバレッジの欠けている3分の1は欠陥ではない。それはラチェットの代償である。誤検知を一切生じさせない裏付け規則は、その機構が問題の最初の段階では行動できないことも意味する：

表7. エスカレーション遅延 — ラチェットが発動する前に安価なモデルで処理されたハードターン

2ターンは、2連続ターンのストリークルールが指定するとおりの値であり、1ターンは、two-strikes-to-ratchetルールが指定するとおりの値です。この遅延は設計によるものであり、それはゼロ誤検出を生み出したのと同じ特性です。より速いレスキューを望む人なら誰でも、n=1で動作するClass Aヘッダーを持っています。それがまさに、手動脱出ハッチが最初に出荷された理由です。

6.4 ヘッドライン比率はトラフィックに完全に依存します

コーパスは、設計上50%がハードセッションです。実際のルーターのトラフィックはそうではなく、コスト比較はその点に非常に敏感です。ハードセッションの割合の範囲にわたって、測定されたアーキタイプ別コストを再重み付け：

図7. 強力なモデルを本当に必要とするトラフィックの割合に応じた、1,000セッションあたりのコスト。クラス内の挙動は測定値に固定され、ミックスのみが変化します。

表8.有病率感度、$／1,000セッションあたり。

設計文書自体の目標エスカレーション率（セッションの5%以下）では、エスカレーションコストはcheap-poolの請求額の1.6倍、frontierの請求額の12%です。ストレス混合50%では、コストはcheap-poolの請求額の6.7倍になります。どちらも真実で、異なる質問に答えています。運用上関連するのは最初のものであり、それがシェア上限が「オフ」ではなく20%にデフォルト設定される理由です。実際に請求額を制限するのは、トリガーの精度ではなく、上限なのです。

6.5 敵対的な乱用下でも上限は維持される

私たちは、実際のシェアキャップ機構（スタブではなく、実際のRedisデイバケット）を用いて、§8の脅威モデルの下でコーパスを再実行した。すべてのクライアントが、すべてのターンでX-OrcaRouter-Tier: strongを送信する。

図8.20%のエスカレーション割合上限に対する敵対的ヘッダー悪用。最初の20リクエストは設計上制約を受けない。ウォームアップ下限により、「2件中1件のエスカレーション」が50%と解釈されて新しいルーターで機能がロックされるのを防ぐ。その後、割合は収束して維持される。最終状態: 1,439リクエスト中296件がstrongで処理され(20.6%)、1,143件の明示的リクエストが拒否され、denied_capイベントとして監査された。

残存する0.6%のオーバーシュートは、近似トレーリングカウンターに対する厳密大なり比較の意図された動作であり、セッションごとの上限1により、個々のセッションがバジェットを消費し尽くすことはありません。すべての拒否は、X-Orca-Session-Tier: base; reason=denied:share_cap レスポンスヘッダーでクライアントに、また監査テーブルでオペレーターに可視化されます。抑制されたエスカレーションが黙殺されることは決してありません。

7 私たちが変えたいこと

デルタ抽出器に独自の閾値を与えてください。完全なトランスクリプトのT2を再利用すると、0.019のマージンが残ります(§6.2)。0.45–0.60のデルタ固有のT2は、このコーパスでは挙動が同一で、ヘッドルームが2桁大きくなります。すでに予定されているパーセンタイル閾値の作業はこれを包含しており、より良い修正です。

コード密度という項を飾りのままにしておくべきではない。この項は、私たちが構築できる最も密度の高い現実的なテキストにおいて、その0.20の予算のうち0.069を占める。なぜなら、その飽和上限が100文字あたり5マッチということは、およそ20文字ごとに1つのコードキーワードがあることを意味するからだ。対応として、計測された本番分布に基づいて上限を再設定するか、その重みを再配分するかのいずれかを選ぶべきである。

クラスCはエージェントトラフィックの主力であり、最も開発が進んでいない。 failure_loop集団は難易度ゲートでは検出できず（ピーク0.262）、完全にストライクで捕捉される。エージェントセッションは、語彙的に難しくなることではなく、ループによって失敗する。残りのレスポンス側プロデューサー、そしてまだ実装されていないネイティブGeminiのストリーミングキャプチャフックは、さらなる難易度調整よりも価値がある。

エスカレーションのレイテンシを公開する。安価なモデルでの2回の処理は、裏付け用ラチェットの正直なコストであり、オペレーターはそれを精度の隣の分析パネルで確認できるようにすべきであって、自ら発見するものではない。

8 制限事項

このコーパスは合成データである。完全に分離できるように構築されているため、誤検出ゼロという結果は、分離可能な入力に対するメカニズムの特異性を示すものであり、本番トラフィックに対する精度を示すものではない。実際の精度の数値は、設計が定めるシャドウモードのラベリング作業、すなわち完全なトリガーパイプラインを実行して何もルーティングせず、決定を事後的にラベリングするという作業によってのみ得られる。そして、ラベル精度≥70 %をゴーライブのゲート条件とする。

コストモデルは、ターンごとの出力トークンを固定の500と仮定している。これにより実際の効果が抑えられている。すなわち、フロンティアモデルはより多くの推論トークンを生成するため、真のフロンティアプレミアムは過小評価される。また、リクエストレベルのキャッシュの温まり具合を、キースロット全体で一様な1/Nとしてモデル化している。加重プールであればハーフィンダール指数Σw²を用いることになり、シングルキーチャネルでは、チャネル層におけるセッション親和性のキャッシュ優位性はまったく見られないだろう。ただし、モデル層のピン留めは適応戦略にとって依然として重要である。

我々は上流推論を実行していないため、精度やタスク成功に関する主張は行わない。ハードターン・カバレッジは品質の代理指標であり、強力なモデルがそうしたターンで実際により優れていることを前提としている。これは構築されたアーキタイプについては妥当と思われるが、ここでは未検証である。

最後に、これはある一つのゲートウェイ実装における測定結果である。ターン1のロックイン失敗モードは、セッションを固定するキャッシュ認識ルーター全般に一般化されるはずだが、具体的な数値は、これらの閾値、これらの重み、そしてこれらの価格に依存する特性である。

9 関連研究

リクエストレベルルーティングは十分にカバーされている。FrugalGPTsup>[2]/sup>はLLMカスケードを導入した——安価なモデルに問い合わせ、回答をスコアリングし、低信頼度ならエスカレーションする——同等の精度で最大98％のコスト削減を報告している。RouteLLMsup>[1]/sup>はChatbot Arenaの選好データでルーターを訓練し、14％の強力モデル呼び出しでGPT-4品質の95％を報告している。また、このルーターは再訓練なしでモデルペア間で転移する。RouterArenasup>[3]/sup>は、これまで欠けていた評価基盤を提供する：ドメインと難易度をカバーする8,400件のクエリを、精度、コスト、ルーティングの最適性、堅牢性、そしてルーターオーバーヘッドの観点で評価する。

これらのいずれも、会話をルーティングの単位として扱ってはいない。カスケードはリクエストをエスカレーションし、そのことを忘れる。次のターンでは、同じ安価なモデルが、今や困難だと判明している同じタスクに対して再実行される。選好学習されたルーターが評価するのはクエリであり、軌跡ではない。このレポートが扱うギャップは、ルーターがターン間で何を記憶すべきか、どのくらいの期間なのか、そして何がその判断を変えることを許されるべきか、という問いである。この問いは、プロンプトキャッシュが忘却を高コストにするようになって初めて緊急性を帯びる。

OrcaRouter は、オープンデータセットに対して cheapest、quality、balanced、linucb、gated_adaptive の5つのリクエストレベル戦略を、アップストリームリポジトリを変更することなくベンチマークする、ツリー内の RouterArena ハーネス (eval/) を同梱しています。ここで説明するセッションレベルメカニズムは、これら5つすべてと直交し、かつ組み合わせて使用できます。

10 結論

プロンプトキャッシングは、LLMルーティングの経済性を、ルーティングに関する文献がまだ追いついていない形で変えた。継続性が入力トークンの大半に対して10倍の割引に値するものになれば、ルーターはピン留めするほかない。そしてピン留めした瞬間、ルーターは最も情報が少ないターンで決定を下し、その決定を会話が続く間ずっと背負い続けることになる。リクエストレベルのルーティングにはこの問題はなく、その代償としてキャッシュミスを払う。素朴なターンごとの再評価はミスを再導入し、その上に長さバイアスというアーティファクトを加える。

ティア型スティッキネスは、1つに見える2つのものを分離することでそれを解決する。すなわち、このセッションを担当するモデル（ティア内で安定しているピン）とこのセッションが属するティア（小さく、上限付きで、裏付けがあり、期限付きの状態の断片）である。私たちのリプレイでは、この分離により、ターン1では難しさを検出できないセッションの87%を回復し、200件の簡単なセッションでは偽陽性ゼロ、常にフロンティアを使う場合のコストの45%で実現した。さらに、それを打ち破ろうと積極的に試みるクライアントに対しても20%の支出上限を維持する。

このメカニズムの正直な弱点は、アーキテクチャではなくキャリブレーションにある。すなわち、チューニングされていない分布から再利用された難易度ゲート、予算に到達できないフィーチャー項、そして回避不能なレスキュー待ち時間の2ターンである。これらは解決可能だ。アーキテクチャ上の主張——エスカレーションメモリはピンから分離されていなければならない、あいまいなシグナルが単独でラチェットを進めてはならない、そしてクライアントがトークンを保持している以上、キャップはクライアント自身の明示的なリクエストを拘束しなければならない——こそが、私たちが維持したい部分である。

11 出典

1. LMSYS Org. RouteLLM: コスト効率的なLLMルーティングのためのオープンソースフレームワーク。 a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · コード: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia & Zou. FrugalGPT: コストを削減しつつパフォーマンスを向上させる大規模言語モデルの使い方. arXiv:2305.05176. a href="https://arxiv.org/abs/2305.05176">u>arxiv.org/abs/2305.05176/u>/a>

3. Lu, Liu, Yuan, Cui, Zhang, Liu & Xing. RouterArena: LLMルーターを包括的に比較するためのオープンプラットフォーム. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. APIにおけるプロンプトキャッシング。 a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — 自動キャッシュ、1,024トークン以上のプレフィックスを128トークン単位で、5〜10分のアイドル状態で退避、最大1時間。キャッシュ入力はモデル層に応じて割引。料金: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic。プロンプトキャッシュ。 a href="https://platform.claude.com/docs/en/build-with-claude/prompt-caching">u>platform.claude.com/docs/en/build-with-claude/prompt-caching/u>/a> — キャッシュ読み取りは基本入力の0.1倍、書き込みは1.25倍（TTL 5分）または2倍（TTL 1時間）で、使用時に更新されます。料金：a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek。 DeepSeek API は Context Caching on Disk を導入します。 a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — 自動で、実際のキャッシュヒットに基づいて課金され、ヒット時には桁違いの削減が実現されます。

7. Google。 Gemini API コンテキストキャッシュ。 a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — 暗黙的および明示的なキャッシュ（ストレージ価格のTTL付き）。

8. OrcaRouter ソース、このリポジトリ: service/session_affinity.go (ピン、TTL、ティアスコープのキー) · service/session_escalation.go (エンジン) · service/model_router.go:1374 (selectByStrategy: ピン読み取り前のティア絞り込み) · service/model_router_difficulty.go (重みと上限) · service/model_router_delta.go (デルタ抽出器) · service/escalation_strikes.go (リクエスト側プロデューサー) · service/escalation_caps.go (シェア上限) · docs/features/frontier-escalation.md (設計、レビューラウンド1〜4)。

再現性。計測ハーネスは、サービスパッケージ内のGoテストであり、miniredisに対してResolveEscalation / CommitEscalationDecisionを駆動し、Pythonによる解析および図表作成パイプラインを備えています。コーパス生成はシード化されており（rand.NewSource(20260814)）、実行全体は決定論的です：400セッション、3,968ターン、3つの実験（メインリプレイ、敵対的キャップ実行、9ポイント閾値スイープ）。図表はCVD検証済みのカテゴリカルパレットを使用しており、各図表にはその基となるテーブルが対応付けられています。本番データには一切アクセスしておらず、本分析のいかなる部分もリポジトリにコミットされていません。