Routing DSL: ein Panel aus Modellen zusammenstellen, das wie Fable 5 denkt

Zwei Jahre lang lautete das Rezept für "mehr Intelligenz": "Warte auf das nächste Modell." Wir halten das für die falsche Fortschrittseinheit. Die Grenze ist kein einzelner Checkpoint – sie ist einPanel. Gib drei guten Modellen dasselbe schwierige Problem, lass sie uneinig sein, schlichte zwischen den Antworten, und das Panel schlägt jedes einzelne seiner Mitglieder. Oft schlägt es das nächste Modell in der Preistabelle.

Die Routing-DSL ist, wie du dieses Panel erstellst. Es ist eine programmierbare Routing-Strategie — YAML + CEL — der deinen OrcaRouter-Endpoint in einen Inferenzgraphen verwandelt: nach Schwierigkeit routen, nach Aufgabe routen, gleichzeitig auf mehrere Modelle aufteilen, ihre Ausgaben bewerten oder abstimmen, bei niedrigem Vertrauen zurückfallen und das Ganze für Kosten, Latenz oder Qualität optimieren. Du schreibst Regeln; das Gateway kompiliert und führt sie bei jeder Anfrage in etwa 5 ms aus.

Dieser Beitrag ist die Engineering-Tour: die Grammatik, die Variablen, nach denen Sie verzweigen können, die vier Entscheidungsinstanzen, die Kaskade und ein vollständiges Produktionsregelwerk am Ende.

Das Ergebnis zuerst

Zwei anschauliche Benchmarks. (Die Zahlen sind nur zur Veranschaulichung gedacht – sie sollen die Form des Effekts zeigen, nicht als offizielle Ergebnisse zitiert werden.)

Frontier-Vergleich — ein schwierigkeitsgesteuerter DSL-Endpunkt gegenüber der Solo-Frontier:

Fusion-Panels vs. Solo-Modelle — bewertet bei 93 von 100 Aufgaben (von OpenRouter):

Drei Dinge, die man anstarren sollte:

Jedes Fusion-Panel schlägt jedes seiner eigenen Mitglieder. Opus 4.8 + GPT-5.5 (~67,5%) übertrifft sowohl Opus solo (~58,5%) als auch GPT-5.5 solo (~60%) um 7–9 Punkte. Uneinigkeit ist Signal; Schiedsverfahren erntet es.

Fusion erreicht die nächste Stufe. Drei verschiedene Panels überschreiten Fable 5 solo (~65.5%) nur mit den Modellen unter ihm.

Du brauchst keine teuren Mitgliedschaften.Opus + Opus Selbstfusion (~65,5%) gleicht Fable 5 mit einem Modell und einem Sampler. Ein Panel von günstig Modelle — Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro (~64,5%) — liegen knapp unter Fable 5 bei einem Bruchteil der Kosten pro Token. Das ist die ganze These: Kaufe Intelligenz mit Topologie, nicht mit der nächsten Preisstufe.

Die Routing-DSL ist die Steuerungsoberfläche, die es Ihnen ermöglicht, diese Topologie nur dort einzusetzen, wo sie sich auszahlt – günstige Modelle für die einfachen 80 %, ein Fusion-Panel für den schwierigen Teil.

Die Grammatik in 30 Sekunden

Ein Regelsatz ist Version, eine Liste von Regeln und ein erforderlicher Standardwert. Regeln werden von oben nach unten; das erste when: das zutrifft, gewinnt. Kein when: bedeutet "immer zutreffen."

Version: 1

rules:
  - id: only_rule
    use: { model: "claude-sonnet-4-6" }
default:
  delegate: balanced

Das when: ist ein CEL boolescher Ausdruck – sandboxed, RE2-only Regex, keine Schleifen, keine E/A, Mikrosekunden-Auswertung, mit einer einzigen 5-ms-Frist, die über das gesamte Regelset geteilt wird. Das use: ist der Effekt: wohin die Anfrage geht und wie sie abgestimmt wird. Die Grenzen sind bewusst klein gehalten (≤30 Regeln, ≤16 KiB Quelltext, ≤200 Zeichen pro when:), sodass ein Regelset überprüfbar bleibt.

Primitive 1 — Route nach Schwierigkeit und Aufgabe

Der Verteiler klassifiziert jede Anfrage vor dem Routing und stellt die Funktionen CEL zur Verfügung. Sie verzweigen direkt darauf:

Version: 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: balanced

Die Variablen, die Sie in when: lesen können (abgekürzt — siehe vollständige Referenz in der Dokumentation):

Gruppenbeispiele

Anfrageform

request.input_tokens, request.output_max_tokens, request.stream, request.vision, request.message_count, request.has_tools

Klassifizierung

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

Sitzung 

agent_state.turn, agent_state.tools_used, agent_state.has_edited, agent_state.last_test_failed, agent_state.consecutive_errors, agent_state.models_tried

Kontext

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).

Jedes Ziel kann Pro-Aufruf-Regler, die vom Relay-Adapter in die nativen Parameter jedes Anbieters übersetzt werden: reasoning_effort (niedrig/mittel/hoch), thinking_budget_tokens (1024–64000), samples (1–16), temperature (0.0–2.0), plus durch Denylist geschützte param_override / header_override. Das reicht bereits aus, um den schwierigkeitsbasierten Endpunkt aus Tabelle A zu erstellen: günstiges Modell für das einfache Ende, Opus mit einem Thinking-Budget für das schwierige Ende.

Primitive 2 — auf ein Panel ausfächern (Fusion)

Dies ist der Ursprung des Benchmark-Auftriebs. Ein paralleler: Effekt sendet die Anfrage an 2–5 Beine gleichzeitig, dann ein Schiedsrichter entscheidet, was der Kunde tatsächlich sieht:

- 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"

Vier Arbiter-Strategien, jede eine andere Antwort auf "wessen Ausgabe gewinnt?":

Zuerst — rennen Sie die Beine, servieren Sie den ersten Erfolg, stornieren Sie die Verlierer. Optimiert Latenz (Sie erhalten den schnellsten von N).

Mehrheit — Strukturierte Abstimmung über die Ausgaben der Zweige, kein zusätzlicher Modellaufruf. Wenn die Zweige ohne strikte Mehrheit auseinandergehen, sendet der optionale Zweig on_disagreement: einen neuen, stärkeren Versuch aus, anstatt einen Tie-Break zu liefern. Optimiert Robustheit bei Aufgaben mit einer kanonischen Antwort.

best_of_n — ein LLM-Richter liest alle Kandidaten und bewertet sie. Dies ist die Opus + GPT-5.5 → judge Konfiguration aus Tabelle B. Optimiert die Qualität bei offenen Aufgaben; fällt auf first-successful zurück, wenn der Richter Fehler macht.

tests_pass — execution-grounded: bediene den Kandidaten, dessen Patch tatsächlich die Testsuite bestehen lässt. Kein Schiedsrichter-Raten – das Test-Framework entscheidet. Dies ist der stärkste Schiedsrichter für Code/Agent-Arbeit. Der Verifier befindet sich außerhalb des Gateways (verbunden über einen VerifierProvider); ohne Verbindung fällt er auf first-successful zurück.

max_latency_ms (1000–600000, Standard 120000) begrenzt das Fan-Out, sodass ein langsamer Zweig die Antwort nicht blockieren kann — Verzögerer werden verworfen. Die Verschachtelung von parallel in parallel wird beim lint abgelehnt; das Panel ist absichtlich nur eine Ebene tief.

Verfügbarkeitshinweis: die N-Wege-Fan-Out-Laufzeit ist hinter dem Server-Flag geschaltet ROUTING_DSL_ENSEMBLE_RUNTIME während die Abrechnung pro Leg im Staging gehärtet ist – daher ist Fusion Vorschau, nicht GA. Wenn das Flag deaktiviert ist, bedient eine parallel: Regel sauber ihr erstes Leg, sodass Sie heute Ihre Panels erstellen und im Schattenmodus testen können und sie aktivieren, wenn Fusion in Ihrer Region verfügbar ist.

Primitive 3 – Fallbacks und Konfidenzkaskaden

Fan-out gibt N× im Voraus aus. Eine Kaskade gibt zusätzlich aus nur wenn die erste Antwort falsch aussieht. Nach der Antwort wertet on_low_confidence: Signale aus und sendet bei einem Auslösen erneut an ein stärkeres Ziel:

- 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"

Die Signale: patch_invalid (der Diff schlägt bei git apply --check fehl), self_doubt (ein Set von Hedging-Phrasen als Regex), low_logprob (mittlerer Token-Logprob unter dem Schwellenwert, sofern der Anbieter diesen offenlegt), und next_turn_test_failed (ein turnübergreifender Riegel – die Aufforderung dieses Turns trägt die Form der fehlgeschlagenen Tests des letzten Turns). Kaskaden sind von Natur aus auf Tiefe 1 ausgelegt. Kombinieren Sie sie mit agent_state.models_tried für Vielfalt beim erneuten Versuch — senden Sie die Reparatur niemals an das Modell, das gerade fehlgeschlagen ist.

Feinabstimmung: Kosten, Latenz, Qualität

Dieselbe DSL drückt alle drei Ziele aus; Sie wählen pro Regel:

Kosten — Delegieren: am günstigsten, behalte das günstige Modell auf dem einfachen Ende und reserviere Fan-out für Schwierigkeit > 0,7. Tabelle Bs günstiges Panel (~64,5 % ≈ Fable 5 Solo) ist der Existenzbeweis: Eine Fusion kleiner Modelle kann ein Frontier-Modell zu einem Bruchteil der Kosten pro Token ersetzen. Sei dir jedoch im Klaren – Fusion verwendet das "jedes Bein berechnen" Modell: Ein 3-Leg-best_of_n-Panel berechnet drei Kandidaten plus den Richter. Die Wirtschaftlichkeit funktioniert, weil Sie (a) nur bei der schwierigen Minderheit der Anfragen Fan-out durchführen und (b) fusionieren günstigere Mitglieder als das Frontier-Modell, das Sie ersetzen.

Latenz — Arbiter: { strategy: first } plus eine strenge max_latency_ms gibt Ihnen die schnellste von N mit einer harten Obergrenze.

Qualität — best_of_n für offene Aufgaben, tests_pass, wenn eine Testsuite zur Verfügung steht, auf die man sich stützen kann. samples und thinking_budget_tokens kaufen mehr innerhalb eines Durchgangs.

Betreiben, ohne die Produktion zu beeinträchtigen

Routing-Änderungen sind beängstigend, daher wird das DSL mit den Sicherheitsvorkehrungen ausgeliefert, die ein SRE erwartet:

Lint bei jedem Speichern — Schema, CEL-Typüberprüfung (jedes when: muss zu bool ausgewertet werden), Referenzauflösung, Knob-Bereiche, Header/Param-Sperrlisten. Fehler werden als {line, column, message, rule} zurückgegeben und als Gutter-Chips im Editor dargestellt.

Trockentest — POST eine synthetische Anfrage (task_class, difficulty, agent_state, …) und erhalte die passende Regel, den aufgelösten Effekt und die Auswertungszeit zurück, bevor etwas ausgeliefert wird.

Schattenmodus — für 24 h nach dem ersten Speichern wird das DSL evaluiert, aber nicht verwendet; ein Schattenprotokoll zeichnet die potenziellen Auswahlen auf und die Konsole zeigt eine Differenz an (Prozentsatz der geänderten Routen, prognostizierte tägliche Kostenänderung, Trefferanzahl pro Regel).

Canary — ein 0–100 Traffic-Schieberegler. Rampe 5 → 25 → 50 → 100 unter Beobachtung der Metriken pro Slice; zurücksetzen durch Schieben auf 0.

Audit + Rollback — jeder Speicher-/Rollback-Vorgang schreibt eine Audit-Zeile in derselben Transaktion; gleichzeitige Bearbeitungen erhalten einen 409 mit der aktuellen Version, damit Sie es gegen den aktuellen Stand erneut versuchen.

Testfälle, Trace-Wiedergabe und eine KI-Ansicht „Regelsatz erklären“ runden es ab. Sie finden es im Dashboard unter Routing → Strategie → DSL.

Ein vollständiges Regelwerk

Günstig bei einfach, mittel bei mittel, ein bewertetes Fusionspanel auf dem harten agentischen Schwanz, mit einer Vertrauenskaskade darunter:

Version: 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

Dieser Endpunkt ist derjenige, der oben in Tabelle A steht – nicht weil er ein besseres Modell gefunden hat, sondern weil er das richtige Modell für die richtige Anfrage einsetzt und ein Panel genau dort einfügt, wo das Panel gewinnt.

Verfassen beginnen

Der nächste Sprung in der Leistungsfähigkeit muss nicht auf den nächsten Meilenstein warten. Es ist ein Graph, den Sie heute Nachmittag schreiben können: nach Schwierigkeit routen, auf dem harten Ende ausfächern, die Ausgaben bewerten oder testen, kaskadieren, wenn das Vertrauen sinkt.

Dokumentation: https://docs.orcarouter.ai/routing/routing-dsl

UI: Routing → Router erstellen -> Routingstrategie → DSL (Experte)

Die Grenze ist ein Panel. Bauen Sie Ihres.