ルーティングDSL: Fable 5のように考えるモデルのパネルを構成する
ここ2年間、「より多くの知能」のための戦略は「次のモデルを待つ」ことだった。我々はそれが間違った進歩の単位だと思う。フロンティアは単一のチェックポイントではなく、それはパネルである。三つの優れたモデルに同じ難題を与え、意見を対立させ、答えの間を調停すれば、そのパネルはどのメンバー単体よりも優れた結果を出す。しばしば、価格表で一つ上のモデルをも凌ぐ。
そのルーティングDSLはそのパネルを構築する方法です。それはプログラマブルなルーティング戦略 — YAML + CEL — であり、OrcaRouterエンドポイントを推論グラフに変換します: 難易度でルーティング、タスクでルーティング、複数のモデルに一度にファンアウトし、その出力を判定または投票し、信頼度が低い場合にフォールバックし、コスト、レイテンシ、または品質のために全体を調整します。ルールを記述します; ゲートウェイがそれらをコンパイルし、各リクエストで約5ミリ秒で実行します。
この投稿はエンジニアリングツアーです：文法、分岐可能な変数、4つのアービター、カスケード、そして最後に完全なプロダクションルールセット。
結果を先に
2つの例示的なベンチマーク。(数字は例示です — それらは示すことを意図している 形状 の効果、公式スコアとして引用されるものではありません。)
フロンティア比較 — 難易度ルーティングされたDSLエンドポイント対単独フロンティア:
Fusionパネル vs. ソロモデル — 100タスク中93タスクでスコア (OpenRouterより):
見つめる価値のある三つのもの：
すべての融合パネルは、その構成メンバーのそれぞれを上回る。 Opus 4.8 + GPT-5.5 (~67.5%) は、Opus単独 (~58.5%) と GPT-5.5単独 (~60%) の両方を7–9ポイント上回る。不一致はシグナルであり；仲裁がそれを収穫する。
Fusionは次の段階に到達する。 3つの異なるパネルが超える Fable 5ソロ(~65.5%) モデルのみを使用して 以下の それ。
高額な会員は必要ありません。Opus + Opus 自己融合（約65.5%）は、1つのモデルと1つのサンプラーでFable 5に匹敵します。パネル（安価なモデル — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro（約64.5%） —）は、Fable 5をわずかに下回り、トークンあたりのコストはほんの一部です。それが全体の主張です： 知能をトポロジーで買い、次の価格帯ではありません。
ルーティングDSLは、トポロジーを効果的な部分にだけ適用できるようにする制御面です。つまり、簡単な80%には安価なモデルを、難しい部分にはフュージョンパネルを使う、といった具合です。
30秒で学ぶ文法
ルールセットは、バージョン、ルールのリスト、および必須のデフォルトで構成されます。ルールは評価されます上から下へ。最初のwhen:が真であるものが優先されます。 when:がない場合は「常にマッチ」を意味します。
バージョン: 1
rules:
- id: only_rule
use: { model: "claude-sonnet-4-6" }
default:
delegate: balancedwhen: は CEL ブール式 — サンドボックス化され、RE2のみの正規表現、ループなし、I/Oなし、マイクロ秒単位の評価、ルールセット全体で共有される単一の5ミリ秒のデッドラインを持つ。The use: は 効果: リクエストの送信先とその調整方法を指定します。制限は意図的に小さく設定されています（ルール数≤30、ソースサイズ≤16 KiB、when:あたり≤200文字）。これにより、ルールセットは監査可能な状態を維持します。
プリミティブ1 — 難易度とタスクでルート
ディストリビューターは、ルーティングの前にすべてのリクエストを分類し、その機能をCELに公開します。それらを直接分岐させることができます：
バージョン: 1
rules:
- id: hard_reasoning
when: difficulty > 0.8
use:
model: "claude-opus-4-8"
reasoning_effort: "high"
thinking_budget_tokens: 32000
- id: code_path
when: task_class == "code" && code_keyword_density > 0.5
use: { model: "gpt-5.5" }
- id: cheap_chat
when: difficulty < 0.3
use: { model: "gemini-3-flash" }
default:
delegate: balancedwhen: で読み取れる変数（省略形 — 詳細はドキュメントの完全なリファレンスを参照）：
グループの例
リクエスト形状
request.input_tokens, request.output_max_tokens, request.stream, request.vision, request.message_count, request.has_tools分類
task_class (chat/code/agent/vision/audio/rag/creative), difficulty (0.0–1.0), code_keyword_density, reasoning_cue_count, log_prompt_tokens, tool_countセッション
agent_state.turn, agent_state.tools_used, agent_state.has_edited, agent_state.last_test_failed, agent_state.consecutive_errors, agent_state.models_triedコンテキスト
headers["x-…"], user.group, token.name, time.hour, workspace.id
…plus six macros for the things regex-over-payload is good at: system_prompt_matches(re), user_message_matches(re), tool_definitions_include(name), tool_calls_present_any([…]), tool_results_from_any([…]), header_matches(name, re).どの宛先でも運べる呼び出しごとのノブは、リレーアダプターによって各プロバイダーのネイティブパラメータに変換されます: reasoning_effort (low/medium/high)、thinking_budget_tokens (1024–64000)、samples (1–16)、temperature (0.0–2.0)、さらに拒否リストで保護されたparam_override / header_override。これだけで、表Aの難易度ルーティングエンドポイントを構築するのに十分です。簡単な問題には安価なモデル、難しい問題には思考予算付きのOpusという具合です。
プリミティブ2 — パネルへのファンアウト（フュージョン）
これがベンチマークリフトの由来です。並列効果はリクエストを2～5本のレッグに同時に、その後アービターがクライアントが実際に見るものを決定します:
- id: hard_tail_panel
when: difficulty > 0.7 && task_class == "agent"
use:
parallel:
- { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
- { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
- { model: "google/gemini-3.1-pro", temperature: 0.3 }
arbiter:
strategy: best_of_n
model: "anthropic/claude-sonnet-4-6" # the judge
template: judge_code
max_latency_ms: 120000
on_disagreement: # majority-only escape hatch
model: "anthropic/claude-opus-4-8"
reasoning_effort: "high"4つの調停戦略、それぞれが「誰の出力が勝つか？」に対する異なる答えです：
最初に — 脚を競わせ、最初の成功を提供し、敗者をキャンセルします。最適化するレイテンシを (あなたはNの中で最速を得る).
多数決は — 各脚の出力にわたる構造化投票、追加のモデル呼び出しなし。脚が絶対多数とならなかった場合、オプションの on_disagreement: ブランチは、同点決着を提供する代わりに、新しくより強力な試行を再ディスパッチします。最適化する ロバスト性を 正解が一意に定まるタスクに対して
best_of_n — LLMジャッジは、すべての候補を読み込んでランク付けします。これはTable BのOpus + GPT-5.5 → judge構成です。最適化品質をオープンエンドな作業で行い、ジャッジがエラーを起こした場合は最初に成功したものにフォールバックします。
テスト合格 — 実行基盤: 実際にテストスイートを通過させるパッチを持つ候補を提供します。判定者は推測せず、ハーネスが決定します。これはコード/エージェント作業において最も強力な判定者です。検証者はゲートウェイの外部に存在し（VerifierProviderを介して配線）、配線されていない場合は最初の成功に劣化します。
max_latency_ms（1000～600000、デフォルト120000）はファンアウトを制限し、1つの遅いレッグがレスポンスを停滞させないようにします — 遅延要素はドロップされます。parallel内にparallelをネストすることはlintで拒否されます。パネルは意図的に1階層のみです。
可用性に関する注意: N-way fan-out ランタイムはサーバーフラグで制限されています ROUTING_DSL_ENSEMBLE_RUNTIME 一方、レッグごとの課金はステージングで強化されています — そのためフュージョンは プレビューであり、GAではありません。フラグがオフの場合、parallel: ルールは最初のレッグをクリーンに提供するため、今日パネルを作成してシャドウし、フュージョンがあなたのリージョンで利用可能になったらそれらを有効にすることができます。
プリミティブ3 — フォールバックと信頼度カスケード
Fan-out は upfront に N倍のコストがかかります。ある カスケード 余分に費やす 最初の回答が間違っている場合のみ。応答後、on_low_confidence: シグナルを評価し、いずれかが発火すると、より強力な宛先に再ディスパッチします：
- id: agent_with_safety_net
when: task_class == "agent"
use:
pool: "@pool:fast"
on_low_confidence:
signals: [patch_invalid, self_doubt, next_turn_test_failed]
threshold: { low_logprob: -1.5 }
use:
model: "claude-opus-4-8"
reasoning_effort: "high"シグナル： patch_invalid （差分が git apply --check に失敗する）、 self_doubt （控えめな表現の正規表現セット）、 low_logprob （平均トークン対数確率が閾値未満、プロバイダーがそれを公開している場合）、および next_turn_test_failed （クロスターンラッチ — 今回のターンのプロンプトは前回のターンの失敗テストの形状を引き継いでいます）。カスケードは設計上 depth-1 です。それらを agent_state.models_tried と組み合わせて取得します リトライ時の多様性 — 失敗したばかりのモデルに修復を送信しないでください。
ダイヤル調整：コスト、レイテンシ、品質
同じDSLは3つの目的すべてを表現します；ルールごとに選択します：
コスト — 委任: 最も安いモデルを選択し、簡単な要求には安価なモデルを維持し、困難度が0.7を超える場合にのみファンアウトを予約する。テーブルBの安価なパネル（約64.5% ≈ Fable 5 solo）はその存在証明である：小さなモデルの融合が、フロンティアモデルを1トークンあたりのコストの一部で置き換えられる。ただし、明確に認識すべきは、融合はその "各レッグへの課金" モデル：3レッグのbest_of_nパネルは、3つの候補と判定者に課金する。経済性が機能する理由は、(a)困難な少数のリクエストにのみファンアウトし、(b)融合する より安い メンバーを、置き換えるフロンティアモデルよりも。
レイテンシ — arbiter: { strategy: first } と厳しい max_latency_ms により、ハードシーリング付きでN個の中で最速のものを提供します。
品質 — best_of_n はオープンエンドの作業向け、tests_pass は基準となるスイートがある場合に使用します。samples と thinking_budget_tokens は一回のレグ内でより多くのものを購入します。
本番環境を壊さずに運用する
ルーティング変更は怖いものですので、DSLにはSREが期待する安全レールが搭載されています:
保存のたびにLint — スキーマ、CEL型チェック（すべてのwhen: boolに評価される必要があります）、参照解決、ノブの範囲、ヘッダー/パラメータ拒否リスト。エラーは{line, column, message, rule}として返され、エディタのガターにチップとして表示されます。
ドライラン — 合成リクエスト（task_class、難易度、agent_state、…）をPOSTし、何かが出荷される前に、一致したルール、解決された効果、および評価時間を取得します。
シャドウモード — 最初の保存後24時間、DSLは評価されるが使用されない; シャドウログは仮の選択を記録し、コンソールには差分（経路変更率、予測日次コスト変動、ルール別発火回数）が表示されます。
カナリア — 0～100のトラフィックスライダー。スライスごとのメトリクスを監視しながらランプ5→25→50→100; スライドで0に戻してロールバック。
監査 + ロールバック — すべての保存/ロールバックは同じトランザクション内で監査行を書き込みます。同時編集の場合は現在のバージョンとともに409が返されるため、新しい状態に対して再試行してください。
テストケース、トレースリプレイ、そしてAIの「このルールセットを説明する」ビューが揃っています。ダッシュボードで、以下のパスの下にあります：ルーティング → ストラテジ → DSL.
完全なルールセット
安いのは簡単、中程度は普通、難しいエージェントテールには判断された融合パネル、その下に信頼カスケードがある：
バージョン: 1
rules:
- id: trivial
when: difficulty < 0.3 && !has_tools
use: { model: "gemini-3-flash" }
- id: standard
when: difficulty < 0.7
use:
model: "gpt-5.5"
on_low_confidence:
signals: [self_doubt, low_logprob]
use: { model: "claude-opus-4-8", reasoning_effort: "high" }
- id: hard_agent_panel
when: difficulty >= 0.7 && task_class == "agent"
use:
parallel:
- { model: "anthropic/claude-opus-4-8", reasoning_effort: "high" }
- { model: "openai/gpt-5.5", thinking_budget_tokens: 16000 }
- { model: "google/gemini-3.1-pro" }
arbiter:
strategy: tests_pass # execution-grounded; judged fallback if no harness
max_latency_ms: 180000
on_disagreement:
model: "claude-opus-4-8"
reasoning_effort: "high"
default:
delegate: balancedそのエンドポイントは、より優れたモデルを見つけたからではなく、適切なリクエストに適切なモデルを割り当て、パネルが最も効果を発揮する箇所に正確にパネルを統合するからこそ、Table Aの先頭に位置しています。
作成を開始
次の能力向上の飛躍は、次のチェックポイントを待つ必要はありません。それは今日の午後に書けるグラフです：難易度でルーティングし、難しい部分でファンアウトし、出力を判断またはテストし、信頼度が下がったらカスケードします。
ドキュメント: https://docs.orcarouter.ai/routing/routing-dsl
UI: ルーティング → ルーターを作成 -> ルーティング戦略 → DSL (エキスパート)
フロンティアはパネルです。あなたのものを構築してください。
