OrcaRouter Routing-Infra: Sitzungsbewusstes Routing und Frontier-Eskalation

ORCAROUTER · ROUTING-ARCHITEKTUR

Jedes LLM-Gateway, das Prompts zwischenspeichert, muss eine Konversation an ein Modell binden. Jedes Gateway, das eine Konversation bindet, trifft seine Routing-Entscheidung anhand des am wenigsten informativen Gesprächsbeitrags dieser Konversation. Dies ist ein Bericht über diesen Kompromiss und über den Tiered-Stickiness-Mechanismus, den OrcaRouter mitliefert, um diesem Kompromiss zu entgehen.

Betreff: OrcaRouter LLM gateway (Go / Gin / Redis) · Komponente: Session-Affinität + Frontier Escalation engine · Methode: 400-Session-Replay gegen den Produktions-Entscheidungscode · Datum: 14. August 2026

ZUSAMMENFASSUNG — LLM-Routing auf Anfrageebene – also das unabhängige Bewerten jeder Anfrage und das Weiterleiten an das günstigste geeignete Modell – ist der Ansatz, den fast alle veröffentlichten Router-Arbeiten behandeln. Es ist auch der falsche Ansatz für den Datenverkehr, der heute das Gateway-Volumen dominiert: Multi-Turn-Agenten-Sitzungen, bei denen der Prompt zu 90 % aus übernommenem Kontext besteht und der Prompt-Cache des Anbieters Kontinuität belohnt. Ein Modellwechsel mitten in der Konversation führt zum Verlust eines 10-fachen Rabatts auf das gemeinsame Präfix, daher pinnen Gateways Sitzungen an. Aber ein Pin, der in Runde 1 gesetzt wird, ist ein Pin, der in der Runde mit der geringsten Evidenz gesetzt wird, und er bleibt für die gesamte Gesprächsdauer bestehen.

100 / 100 — latent-schwere Sitzungen, deren Turn-1-Score von einem trivialen nicht zu unterscheiden ist

+16% — Drift des Schwierigkeitswerts allein durch die Transkriptlänge bei identischer Aufgabenschwierigkeit

45% — der Always-Frontier-Kosten, für 67 % seiner Hard-Turn-Abdeckung

0.019 — Abstand zwischen der ausgelieferten Schwelle und der Obergrenze realistischer Punktzahlen

1 Zwei Routing-Regime

Ein LLM-Gateway, das vielen Anbietern vorgelagert ist, muss pro Anfrage eine Frage beantworten: welches Modell ist dafür zuständig? Es gibt zwei strukturell unterschiedliche Wege, diese zu beantworten, und die Literatur und die Produktionsrealität sind bei der Frage, welche davon zählt, auseinandergegangen.

Routing auf Anfrageebene behandelt jede Anfrage als unabhängig. Ein Bewerter schätzt die Schwierigkeit der Anfrage oder die vorhergesagte Antwortqualität, und die Anfrage wird an das günstigste Modell weitergeleitet, von dem erwartet wird, dass es sie bewältigen kann. Dies ist das Vorgehen praktisch aller veröffentlichten Router-Arbeiten: RouteLLM trainiert Router mit Präferenzdaten, die 95 % der GPT-4-Qualität mit 14 % Aufrufen starker Modelle erreichensup>[1]/sup>; FrugalGPT kaskadiert von günstig zu teuer mit einer Akzeptanz-/Ablehnungsprüfung und berichtet eine Kostensenkung von bis zu 98 %sup>[2]/sup>; RouterArena baut einen Benchmark mit 8.400 Abfragen, um Router genau auf dieser Achse zu vergleichensup>[3]/sup>. Die Analyseeinheit ist die Anfrage.

Sitzungsbewusstes Routing

Der Grund, warum sitzungsbewusstes Routing existiert, ist nicht Eleganz. Es ist Arithmetik.

2 Die Cache-Ökonomie, die Stickiness zwingend macht.

In einer Multi-Turn-Agenten-Sitzung ist der Prompt von Turn n der Prompt von Turn n−1 plus ein Delta. Ab Turn 10 ist das übernommene Präfix die überwältigende Mehrheit der Eingabe-Tokens. Jeder große Anbieter bepreist dieses Präfix nun unterschiedlich, je nachdem, ob es ein Cache-Hit ist:

Tabelle 1.Prompt-Cache-Semantik nach Anbieter. Der Cache wird über ein exaktes Präfix und den Serving-Key geschlüsselt — ein Modellwechsel oder eine Schlüsselrotation ist ein Kaltstart zum vollen Preis.

OrcaRouter kodiert genau diese Lebensdauern als Pin-TTLs: eine Kanaltyp-basierte Zuordnung von Provider-Cache-Fenstern – 5 Minuten für OpenAI, Anthropic und Gemini, 60 Minuten für DeepSeek – mit einem Standard von 5 Minuten für nicht zugeordnete Provider. Der Kanal+Schlüssel-Pin verfällt mit diesem Fenster, weil ein veralteter Schlüsselindex keinen Cache-Wert hat und nur die Lastverteilung verfälscht. Der Modell-Pin, bei einer Redis-gestützten Bereitstellung und für eine lang-pin-berechtigte Sitzungs-ID, bleibt 30 Tage lang bestehen – nicht für den Cache-Wert, der längst verschwunden ist, sondern für die Kontinuität des Anfrageformats. Ein Modellwechsel mitten im Gespräch erzwingt eine Konvertierung des Anfrageformats, die dateninkompatibel sein kann: Denkblöcke und Tool-Call-IDs überleben eine Übersetzung zwischen Provider-Schemata nicht unbedingt.

DAS UNTERSCHÄTZTE DETAIL

Prompt-Caches sind pro API-Schlüssel indiziert, nicht pro Modell. Ein Gateway, das das Modell festpinnt, aber auf demselben Kanal über drei Schlüssel lastverteilt, hat bei zwei von drei Aufrufen weiterhin einen Cache-Miss. Aus diesem Grund speichert OrcaRouters Kanal-Pin {ChannelID, KeyIndex} statt einer Kanal-ID, und der Pin wird verworfen, wenn der aufgezeichnete Schlüsselindex nicht mehr auf einen aktivierten Schlüssel verweist — ein priorisierter, aber rotierter Schlüssel würde einen kalten Cache begünstigen und dabei das Balancing umgehen, was das Schlimmste aus beiden Welten ist.

Die Pins sind weich durchgehend: eine nicht auflösbare Sitzungs-ID ist ein No-op, ein deaktivierter oder nicht gesunder gepinnter Kanal fällt auf die normale ausgewogene Auswahl zurück, und ein Pin auf einen Kanal mit Gewicht null in einem gemischten Pool wird verworfen, sodass ein Admin, der einen Kanal entleert, nicht durch Stickiness ausgebremst wird. Sie lassen eine Anfrage nie fehlschlagen.

3 Die Falle: Stickiness deaktiviert den Router

Hier ist das Fehlerbild. In OrcaRouters Pre-Eskalations-Codepfad lieferte der Session→Model-Pin für einen sitzungsbewussten Router bei jeder Nicht-DSL-Strategie

Das wäre erträglich, wenn Runde 1 repräsentativ wäre. Sie ist es systematisch nicht, aus zwei sich gegenseitig verstärkenden Gründen.

3.1 Turn 1 ist der am wenigsten informative Turn.

Der Schwierigkeitsskalar (service/model_router_difficulty.go) ist eine gewichtete lineare Kombination über sechs lexikalische Merkmale:

LogPromptTokens × 0,20, begrenzt auf log(8001) ≈ 8,99

ReasoningCueCount × 0,15 begrenzt auf 5

SystemPromptLogLen × 0,10 begrenzt auf log(2001) ≈ 7,60

CodeKeywordDensity × 0.20 Obergrenze 5.0 (Treffer pro 100 Zeichen)

HasTools × 0.15 bereits 0/1

MathMarkerCount × 0,20, Obergrenze 5

Ein kurzer Opener ohne Vorgeschichte schneidet fast konstruktionsbedingt schlecht ab: Der mit 0,20 gewichtete Token-Term liegt nahe seiner Untergrenze, und die Reasoning/Mathe-Terme greifen bei Vokabular, das der Nutzer noch keinen Anlass hatte zu verwenden. Sitzungen verpflichten sich daher im Moment der geringsten Information auf ein Schwach-Pool-Modell – und mit einem Redis-gestützten 30-Tage-Modell-Pin ist diese Verpflichtung von langer Dauer.

Abbildung 1. Durchschnittliche Schwierigkeit des letzten Turns pro Gesprächs-Turn, über 100 latent-schwierige Sitzungen und 200 wirklich einfache, bewertet durch den Produktions-Scorer. Bei Turn 1 — dem Turn, an dem der Sticky-Pin geschrieben wird — sind die beiden Populationen ununterscheidbar (0.210 vs. 0.208). Die schwierige Population überschreitet das Gate bei Turn 5. Bei einer reinen Pin-Policy werden alle 100 latent-schwierigen Sitzungen dem günstigen Pool zugewiesen, bevor irgendeine dieser Evidenzen vorliegt.

3.2 Länge gibt sich als Schwierigkeit aus

Das zweite Problem ist subtiler und untergräbt die naheliegende Lösung. Wenn Sie die Schwierigkeitsschwelle einfach in jeder Runde erneut ausführen, wenden Sie sie erneut auf eine Punktzahl an, die über das gesamte konkatenierte Transkript berechnet wurde. Diese Punktzahl hat einen eingebauten Aufwärtstrend: Der mit 0,20 gewichtete LogPromptTokens-Term steigt monoton mit der Gesprächslänge, und für jede Agent-Sitzung sind die 0,15-HasTools- und 0,10-SystemPromptLogLen-Terme effektiv konstante Untergrenzen. Eine lange, langweilige Sitzung wirkt zunehmend schwieriger.

Abbildung 2. Der Längenbias-Artefakt, gemessen anhand von 60 Sitzungen, die ausschließlich aus trivialen Änderungen bestehen („diese Variable umbenennen“, „einen Nil-Check hinzufügen“). Der Volltranskript-Score driftet über 25 Runden bei konstanter Aufgabenschwierigkeit um +16 %; der Score der letzten Runde (Delta) bleibt flach. Eine naive Neubewertung des Volltranskript-Scores bei jeder Runde würde Sitzungen für das Verbrechen, lang zu sein, hochstufen.

Der von OrcaRouter ausgelieferte Fix ist ein separater Delta-Extraktor (service/model_router_delta.go), der nur den letzten Turn bewertet — den neuen Benutzertext plus alle Tool-Ergebnisse, die nach der letzten Assistenten-Nachricht angehängt wurden — wobei dieselben Gewichte und Obergrenzen verwendet werden, SystemPromptLogLen jedoch absichtlich auf null gesetzt wird, da dieser Wert nicht Teil des Deltas ist. Die flache blaue Linie in Abbildung 2 ist dieser Extraktor.

4 Design: gestufte Haftung

Der naive Ausweg aus dem Turn-1-Lock-in besteht darin, jeden Turn neu zu routen — was lediglich Request-Level-Routing ist und den Cache verliert. Der naive Fix in die andere Richtung besteht darin, den Pin zur Erinnerung daran zu machen, dass „diese Session schwierig geworden ist“ — was keine Deeskalation ausdrücken kann und nicht gedeckelt werden kann. Das Design von OrcaRouter lehnt beides ab.

Das Reframing: eine Sitzung ist an ein Modell innerhalb einer Stufe gebunden, und ein kleiner Redis-Stufenzustandist der einzige Eskalationsspeicher. Der Modell-Pin ist niemals der Speicher.

Stufen-Pools.Die starke Stufe ist der aufgelöste Eskalations-Pool (escalation_pool, standardmäßig der strong_pool des Routers). Die Basis-Stufe ist AllowedModels \ Pool der starken Stufe; ein Modell, das in beiden enthalten ist, gehört zur starken Stufe. Innerhalb der Basis-Stufe funktioniert die Schwach/Mittel/Stark-Schwierigkeitsstaffelung von gated_adaptive weiterhin genau wie zuvor.

Tier-bezogene Pins. Der Modell-Pin-Schlüssel der starken Stufe erhält ein :t:strong-Suffix; die Basisstufe behält den Legacy-Schlüssel unverändert. Die Eskalation, daher bewahrt sie den Basis-Pin, sodass eine herabgestufte Sitzung — oder eine nach Ablauf des Stufenzustands fortgesetzte — wieder auf dem exakten Modell landet, mit dem sie begonnen hat, nicht auf einer willkürlichen Neuauswahl. Starke Pins werden nur mit der kurzen Provider-Window-TTL geschrieben: Ein 30-Tage-starker Pin würde den 4-Stunden-Stufenzustand, der ihn gerechtfertigt hat, überleben.

Das Gate läuft zuerst. In selectByStrategy (service/model_router.go:1374) wird die Stufe vorab aufgelöst, die Kandidatenmenge wird auf den Pool der Stufe eingegrenzt, und erst dann wird der Sticky-Pin konsultiert — innerhalb dieser Stufe. Das ist die strukturelle Korrektur für §3: Die Schwierigkeitsberechnung und die Eskalationsauslöser laufen in jeder Runde, bevor der Pin sie kurzschließen kann.

4.1 Drei Trigger-Klassen, nach Vertrauen geordnet

Tabelle 2. Eskalationsauslöser. Kein Fuzzysignal eskaliert jemals allein; nur eine explizite Kundenanfrage ist bei n=1 bindend, und selbst diese unterliegt den Obergrenzen.

Drei Hygiene-Invarianten sind tragend. Strikes werden über eine Request-ID durch einen Ringpuffer dedupliziert, sodass verschachtelte Client-Wiederholungen nicht doppelt gezählt werden können. Infrastrukturausfall ist niemals ein Fähigkeitsfehler — 429er, 5xxer und Kanal-Fallbacks zählen nie als Strike; nur Qualitätssignale nach Erfolg zählen. Und eine „Runde“ ist definiert als eine abgeschlossene, erfolgreich abgerechnete Anfrage, die eine Strike-Bewertung durchlaufen hat, sodass fehlgeschlagene Anfragen weder den Strike-Abbau noch den Zähler für saubere Runden voranbringen.

4.2 Die Auflösung ist rein; der Commit wird aufgeschoben.

Die folgenreichste strukturelle Eigenschaft der Engine ist, dass ResolveEscalation nichts schreibt. Sie liefert eine Entscheidung und eine Liste ausstehender Intents. Der Distributor wendet diese Intents in seinem Post-Success-Block auf einen frischen Read innerhalb einer Redis-WATCH-Transaktion an. Dies ist wichtig, weil der Resolver auf Pfaden läuft, die niemals den Zustand verändern dürfen: spekulative Fallback-Ketten-Auflösungen, die schreibgeschützten Diagnose-Endpunkte und Anfragen, die später 403 zurückgeben oder upstream scheitern. Das erneute Anwenden von Intents auf frischen Zustand bedeutet auch, dass ein veralteter gleichzeitiger Writer einen festgeschriebenen Eskalationsvorgang nicht überschreiben kann, und zwei konkurrierende identische Eskalationen idempotent verschmelzen.

4.3 Großbuchstaben – und warum sie alles verbinden

Eine Fehlalarm-Eskalation kostet (stark − Basis)-Preis × verbleibende Warm-Episode-Tokens, und sie kostet es still — nichts schlägt fehl. Der Explosionsradius ist durch Obergrenzen begrenzt, die für jede Klasse gelten:

escalation_max_per_session (Standardwert 1). Deeskalation und Client-Resets erstatten es nicht, was den Reset-Loop-Gaming-Pfad schließt.

Eine Pro-Router-Obergrenze für den eskalierten Anteil (Standard 20 %) über ein zurückliegendes 24–48-Stunden-Fenster von Redis-Tagesbuckets, plus eine arbeitsbereichsweite routerübergreifende Obergrenze. Bei Erreichen der Obergrenze wird die gesamte Eskalationsweiterleitung unterdrückt — einschließlich expliziter Anfragen und einmaliger Boosts.

Deeskalation nur an Cache-Kalt-Grenzen, sodass ein Fehlalarm auf eine warme Episode begrenzt ist.

Der Grund, warum Klasse A die Obergrenzen einhält, ist eine Schlussfolgerung aus dem Bedrohungsmodell, keine Richtlinienpräferenz: Auf einem API-Gateway kontrolliert derjenige, der das Workspace-Token besitzt, die Header. Ein von der Obergrenze ausgenommener Pfad nach dem Motto „der Client hat darum gebeten“ ist ein nicht gemessener Ausgabenkanal. §7 misst, was passiert, wenn jeder Client ihn missbraucht.

4.4 Deeskalation ist von Natur aus asymmetrisch

Bei bestätigten Beweisen eskalieren; nur de-eskalieren, wenn es kostenlos ist. Eine starke Sitzung kehrt nur dann zur Basis zurück, wenn alle der folgenden Bedingungen erfüllt sind: die Sitzung ist cache-kalt (länger inaktiv als das bei der Eskalation aufgezeichnete Provider-Fenster), sie hat ≥3 strikefreie bewertete Turns angesammelt, und die neueste Delta-Schwierigkeit liegt unter T1. Innerhalb des Warm-Fensters kostet ein Wechsel eine erneute Kaltlesung zum vollen Preis — Flapping ist der einzige garantierte Weg, um die Eskalation kostennegativ zu machen.

5 Methode

Wir haben den Mechanismus gemessen, indem wir ein synthetisches Session-Korpus durch den tatsächlichen Produktionsentscheidungscode. Der Harness ist ein Go-Test im Service-Paket, der ResolveEscalation und CommitEscalationDecision pro Zug gegen einen miniredis-gestützten Tier-Store aufruft, mit den echten Schwierigkeits-Scorern, den echten anfrageseitigen Strike-Erzeugern und der echten Share-Cap-Mechanik. Nichts am Entscheidungspfad ist neu implementiert oder gemockt, außer der Audit-Event-Senke.

Was ist real und was nicht

Real: jede Routing-Entscheidung, jeder Schwierigkeitswert, jede Strike-Erkennung, jede Streak-Regel, jede Cap-Bewertung und jeder Redis-Zustandsübergang — das sind die ausgelieferten Funktionen. Synthetisch: der Datenverkehr. Das Korpus wird generiert, nicht aus Produktionsprotokollen gesampelt. Seine Archetypen-Mischung (50 % schwer) ist eine Stress-Mischung, die gewählt wurde, um den Mechanismus zu testen, keine Schätzung des realen Datenverkehrs; §6.4 berichtet über die Sensitivität gegenüber dieser Wahl, und sie ist groß. Die sauberen Präzisionszahlen unten spiegeln ein Korpus wider, dessen Klassen konstruktionsbedingt trennbar sind, und sollten als „der Mechanismus greift dort, wo er dafür ausgelegt wurde“ gelesen werden, nicht als Schätzung der Produktionspräzision.

5.1 Korpus

400 Sitzungen, 3.968 Turns, seed-basiert und deterministisch. Jeder Turn ist ein vollständiger Chat-Completions-Anfragebody, der die kumulative Historie, ein Array mit zwei Tool-Definitionen und einen realistischen System-Prompt enthält – die Form, die ein Coding-Agent tatsächlich sendet. Fünf Archetypen, jeder mit einem Ground-Truth-Label:

Tabelle 3.Korpuszusammensetzung. „Benötigt stark“ ist die Ground Truth, die für die Präzisions- und Abdeckungswerte verwendet wird.

Schwierige Turns enthalten zusätzlich zum Prosa-Text einen eingefügten Goroutine-Dump oder einen Quellcode-Auszug von 3–8 KB, denn genau das enthält ein wirklich schwieriger Debugging-Turn. Dieses Detail erwies sich als enorm wichtig — siehe §6.2.

5.2 Kostenmodell

Die Kosten werden aus veröffentlichten Listenpreisen mit pro Anbieter geltender Cache-Semantik berechnet; das Modell wird vollständig dargestellt, sodass ihm widersprochen werden kann.

Tabelle 4. Parameter des Kostenmodells. Preise in $ pro 1 Mio. Token, Listenpreise Stand August 2026.

Eine warme Runde kostet 0.1·p_in·prefix + write·p_in·delta; eine kalte Runde kostet write·p_in·prompt. Runde 1 ist immer ein vollständiger Cache-Write. Die Runde des Ebenenwechsels unter der Eskalationsrichtlinie wird ausdrücklich als kalt abgerechnet, sodass der Mechanismus für seine eigene Cache-Invalidierung zahlt.

Die Qualität wird als Abdeckung schwieriger Turns angegeben — der Anteil der laut Ground-Truth schwierigen Turns, die tatsächlich vom starken Modell bedient wurden — und nicht als Genauigkeitswert. Wir haben keine Upstream-Inferenz durchgeführt, daher erfinden wir keine Genauigkeitszahlen.

6 Ergebnisse

6.1 Der Mechanismus wird dort ausgelöst, wo er dafür ausgelegt wurde.

Tabelle 5. Eskalationsergebnisse nach Archetyp, Automodus, Canary 100 %, T2 = 0.70 (ausgelieferter Standard).

Null Fehlalarme bei den 200 einfachen Sitzungen, einschließlich der 60 langen, bei denen ein Bewerter auf Basis des vollständigen Transkripts in das schwierige Band abgedriftet wäre. Die Triggerklassen spezialisieren sich sauber und ohne Überlappung: difficulty erfasst reasoning-intensive Arbeit, strikes erfassen Fehlerschleifen. Beachte, dass der höchste Schwierigkeitswert von failure_loop 0,262 beträgt — das Schwierigkeitsgate bekommt diese Sitzungen überhaupt nie zu sehen. Ein Agent, der in einer Kompilierungsfehler-Schleife festhängt, erzeugt keine Prosa mit hoher Dichte an Reasoning-Hinweisen; er erzeugt denselben kurzen Prompt mit einem anderen Stacktrace. Ohne Class-C-Strikes würde sich jede dieser 60 Sitzungen auf dem billigen Modell endlos abmühen.

Abbildung 3. Wenn Sitzungen eskalieren, nach Auslöser aufteilen. Strike-bedingte Eskalationen sind stark konzentriert (Runde 4, die erste Runde, in der sich zwei Strikes innerhalb des Verfallsfensters angesammelt haben können); schwierigkeitsbedingte Eskalationen verteilen sich über die Runden 2–11 gemäß der Verteilung der Anfangszeitpunkte im Korpus. Die Zwei-Runden-Serien-Regel bedeutet, dass die frühestmögliche schwierigkeitsbedingte Eskalation in Runde 2 eintritt.

6.2 Befund: Das ausgelieferte Tor sitzt auf einer Klippenkante.

Unser erstes Korpus ergab null schwierigkeitsbedingte Eskalationen. Die schwierigen Turns — beladen mit Race-Conditions, Invarianten, Komplexitätsanalyse und Beweisvokabular — erreichten einen Spitzenwert von 0.658 gegenüber einer 0.70-Schwelle. Das Hinzufügen der eingefügten Stack-Traces, die echte Debugging-Turns tatsächlich mit sich führen, trieb sie auf 0.719. Die Schwelle wird mit einem Vorsprung von 0.019 überschritten.

Abbildung 4.Wohin das Schwierigkeitsbudget tatsächlich fließt, gemittelt über 855 schwere und 3.113 leichte Züge. Ein realistischer schwerer Zug erreicht 0,719 des theoretischen Delta-Maximums von 0,90. Der CodeKeywordDensity-Term trägt 0,069 seines Budgets von 0,20 bei — die gemessene Dichte beträgt 1,72 Treffer pro 100 Zeichen gegenüber einer Sättigungsgrenze von 5,0 — und SystemPromptLogLens 0,10 ist im Delta-Extraktor strukturell null. Etwa ein Drittel des nominellen Bereichs des Scores ist durch realistischen Text nicht erreichbar.

Der Schwellwert-Sweep bestätigt, dass dies eine Klippe ist, kein Abhang. Über T2 von 0,35 bis 0,65 ist das Ergebnis identisch — 200 von 400 Sitzungen eskalieren, mit null Auslassungen. Bei dem ausgelieferten Schwellwert 0,70 beginnt der Klassifikator, Sitzungen zu verlieren; bei 0,75 bricht die schwierigkeitsgetriebene Eskalation von 122 Sitzungen auf 23 zusammen.

Abbildung 5. Schwellenempfindlichkeit. Der gesamte Bereich 0,35–0,65 verhält sich verhaltensmäßig identisch, da kein realistischer Delta-Text in diesen Bereich fällt — die Score-Verteilung ist bimodal, mit einfachen Zügen, die um 0,23 gruppiert sind, und schwierigen Zügen um 0,72, und nichts dazwischen. Die ausgelieferte Standardeinstellung liegt am oberen Rand des oberen Modus.

TECHNISCHE AUSWIRKUNG

T2 ist kalibriert für die Volltranskript-Verteilung, auf welche die gated_adaptive-Bänder abgestimmt wurden, und wird als Schwellenwert des Delta-Extraktors wiederverwendet. Das Designdokument weist darauf hin, dass der Delta-Extraktor „sein eigenes Tuning braucht“; diese Messung quantifiziert, wie viel nötig ist. Entweder benötigt das Delta-Gate ein eigenes niedrigeres T2 — ein Wert irgendwo in 0,45–0,60 erzielt identisches Verhalten mit echter Marge — oder der bereits für Phase 3 geplante perzentilbasierte Schwellenwert („Top X % des jüngsten Datenverkehrs dieses Routers“) sollte greifen, was die Eskalationsrate zum Drehregler des Operators macht und die absolute Kalibrierung vollständig umgeht.

6.3 Kosten und Abdeckung

Abbildung 6. Fünf Strategien über dieselben 400 Sitzungen. Links: Kosten pro 1.000 Sitzungen (logarithmische Skala). Rechts: Anteil der wirklich schwierigen Gesprächsrunden, die vom starken Modell bedient werden.

Tabelle 6. Richtlinienvergleich. Kosten pro 1.000 Sitzungen nach dem Modell in Tabelle 4.

Zwei Ergebnisse sind es wert, getrennt zu werden. Erstens, spart die Sitzungsaffinität allein 24 % bei identischer Modellwahl (16,64 → 12,63) und 35 % beim Frontier-Paar (290,93 → 188,30). Das ist reine Cache-Ökonomie — gleiche Modelle, alles gleich, nur die Stickiness des Schlüssels unterscheidet sich. Die Ersparnis ist beim Frontier-Paar größer, weil Anthropics 1,25× Schreibprämie kalte Turns unverhältnismäßig teuer macht.

Zweitens landet die Eskalation dort, wo ein Rettungsmechanismus landen sollte: 45 % der Kosten des Always-Frontier-Ansatzes für 67 % seiner Hard-Turn-Abdeckung, wobei das starke Modell nur in 21,4 % der Turns zum Einsatz kommt.

Das fehlende Drittel der Abdeckung ist kein Defekt; es ist der Preis der Ratsche. Die Bestätigungsregeln, die null Fehlalarme liefern, bedeuten auch, dass der Mechanismus nicht beim ersten Zug eines Problems handeln kann:

Tabelle 7. Eskalationslatenz — schwierige Anfragen, die vom günstigen Modell bearbeitet werden, bevor die Sperrklinke einrastet.

Zwei Züge sind genau das, was die Regel für zwei aufeinanderfolgende Züge vorgibt, und ein Zug ist genau das, was die Zwei-Fehler-Sperre vorgibt. Die Latenz ist das Design, und es ist dieselbe Eigenschaft, die null Fehlalarme erzeugt hat. Wer eine schnellere Rettung möchte, hat den Class-A-Header, der bei n=1 wirkt – genau deshalb wurde die manuelle Notluke zuerst ausgeliefert.

6.4 Das Überschriftenverhältnis hängt vollständig von Ihrem Traffic ab.

Das Korpus besteht konstruktionsbedingt zu 50 % aus harten Sitzungen. Realer Router-Verkehr ist das nicht, und der Kostenvergleich reagiert extrem empfindlich darauf. Eine Neugewichtung der gemessenen Kosten pro Archetyp über eine Reihe von Prävalenzen harter Sitzungen:

Abbildung 7. Kosten pro 1.000 Sitzungen in Abhängigkeit davon, wie viel Ihres Traffics tatsächlich das starke Modell benötigt. Das Verhalten innerhalb der Klassen wird bei den gemessenen Werten gehalten; nur die Mischung ändert sich.

Tabelle 8. Prävalenz-Sensitivität, $ pro 1.000 Sitzungen.

Bei der im Designdokument selbst angesetzten Ziel-Eskalationsrate von ≤5 % der Sitzungen kostet die Eskalation das 1,6-Fache der Cheap-Pool-Rechnung und 12 % der Frontier-Rechnung. Beim Stress-Mix von 50 % kostet sie das 6,7-Fache der Cheap-Pool-Rechnung. Beides ist richtig; sie beantworten verschiedene Fragen. Die operativ relevante ist die erste, und genau deshalb liegt die Anteilsgrenze standardmäßig bei 20 % statt auf „aus“ – die Grenze, nicht die Auslösepräzision, ist das, was die Rechnung tatsächlich begrenzt.

6.5 Die Kappen halten bei feindseligem Missbrauch stand.

Wir haben das Korpus erneut mit der echten Share-Cap-Maschinerie ausgeführt — kein Stub, echte Redis-Tages-Buckets — unter dem Bedrohungsmodell aus §8: Jeder Client sendet bei jeder einzelnen Runde X-OrcaRouter-Tier: strong.

Abbildung 8.Böswilliger Header-Missbrauch gegen die 20-%-Obergrenze des Eskalationsanteils. Die ersten 20 Anfragen sind bewusst uneingeschränkt – die Warm-up-Untergrenze verhindert, dass „1 Eskalation von 2“ als 50 % gelesen wird und das Feature auf einem frischen Router gesperrt wird – danach konvergiert der Anteil und bleibt stabil. Endzustand: 296 von 1.439 Anfragen wurden mit „strong“ bedient (20,6 %), während 1.143 explizite Anfragen abgelehnt und als denied_cap-Ereignisse protokolliert wurden.

Der verbleibende Überschwinger von 0,6 % ist das beabsichtigte Verhalten eines strikt-größer-Vergleichs auf einem ungefähren nachlaufenden Zähler, und die Begrenzung von 1 pro Sitzung verhindert, dass einzelne Sitzungen das Budget aufbrauchen. Jede Ablehnung ist für den Client im X-Orca-Session-Tier: base; reason=denied:share_cap-Antwortheader und für den Betreiber in der Audit-Tabelle sichtbar – eine unterdrückte Eskalation ist niemals still.

7 Was wir ändern würden

Geben Sie dem Delta-Extraktor einen eigenen Schwellenwert. Die Wiederverwendung des Volltranskript-T2 hinterlässt eine Marge von 0,019 (§6.2). Ein delta-spezifisches T2 zwischen 0,45 und 0,60 verhält sich auf diesem Korpus identisch und bietet zwei Größenordnungen mehr Spielraum. Die bereits geplante Arbeit an Perzentil-Schwellenwerten deckt dies ab und ist die bessere Lösung.

Lassen Sie nicht zu, dass der Code-Dichte-Term nur dekorativ bleibt. Bei dem dichtesten realistischen Text, den wir konstruieren konnten, trägt er 0,069 seines 0,20-Budgets bei, denn seine Sättigungsgrenze von 5 Treffern pro 100 Zeichen impliziert etwa ein Code-Schlüsselwort alle zwanzig Zeichen. Begrenzen Sie ihn entweder anhand einer gemessenen Produktionsverteilung neu oder verteilen Sie sein Gewicht neu.

Klasse C ist das Arbeitspferd für Agentenverkehr und am wenigsten entwickelt. Die failure_loop-Population ist für das Schwierigkeitsgate unsichtbar (Spitzenwert 0,262) und wird vollständig von Strikes erfasst. Agentensitzungen scheitern durch Schleifen, nicht durch zunehmende lexikalische Schwierigkeit. Die verbleibenden Produzenten auf der Antwortseite — und der noch fehlende native-Gemini-Streaming-Capture-Hook — sind mehr wert als weitere Schwierigkeitsanpassungen.

Veröffentlichen Sie die Eskalationslatenz. Zwei Runden harter Arbeit auf dem günstigen Modell sind der ehrliche Preis einer bestätigenden Ratsche, und Betreiber sollten sie im Analyse-Panel neben der Präzision sehen, nicht selbst entdecken müssen.

8 Einschränkungen

Das Korpus ist synthetisch. Es wurde konstruiert, um sauber zu trennen, sodass das Null-Falsch-Positiv-Ergebnis die Spezifität des Mechanismus bei separierbarem Input charakterisiert, nicht seine Präzision im Produktionsverkehr. Die tatsächliche Präzisionszahl kann nur aus dem Shadow-Mode-Labeling-Job stammen, den das Design vorsieht — vollständige Trigger-Pipeline in Betrieb, ohne Weiterleitung, Entscheidungen werden nachträglich gelabelt — mit einem Go-Live-Gate bei ≥70 % gelabelter Präzision.

Das Kostenmodell geht von festen 500 Ausgabetokens pro Runde aus, was einen realen Effekt unterdrückt: Spitzenmodelle erzeugen mehr Reasoning-Tokens, sodass die tatsächliche Spitzenprämie unterschätzt wird. Es modelliert außerdem die Cache-Wärme auf Anfrageebene als gleichmäßiges 1/N über Schlüsselslots; ein gewichteter Pool würde den Herfindahl-Index Σw² verwenden, und ein Single-Key-Kanal würde auf der Kanalebene überhaupt keinen Cache-Vorteil für Sitzungsaffinität zeigen – obwohl das Pinning auf Modellebene für adaptive Strategien weiterhin wichtig ist.

Wir haben keine vorgelagerte Inferenz durchgeführt, daher wird kein Anspruch auf Genauigkeit oder Aufgabenerfolg erhoben. Die Hard-Turn-Abdeckung ist ein Stellvertreter für Qualität und setzt voraus, dass das starke Modell bei diesen Turns tatsächlich besser ist – plausibel für die konstruierten Archetypen, hier jedoch unverifiziert.

Schließlich misst dies die Implementierung eines Gateways. Der Turn-1-Lock-in-Fehlermodus sollte sich auf jeden cache-bewussten Router verallgemeinern lassen, der Sitzungen anpinnt, aber die konkreten Zahlen sind Eigenschaften dieser Schwellenwerte, dieser Gewichte und dieser Preise.

9 Verwandte Arbeiten

Das Routing auf Anfrageebene ist gut abgedeckt. FrugalGPTsup>[2]/sup> führte die LLM-Kaskade ein — das günstige Modell abfragen, die Antwort bewerten, bei geringer Konfidenz eskalieren — und berichtet eine Kostensenkung von bis zu 98 % bei gleicher Genauigkeit. RouteLLMsup>[1]/sup> trainiert Router auf Präferenzdaten von Chatbot Arena und berichtet 95 % der GPT-4-Qualität bei 14 % Aufrufen des starken Modells, wobei die Router ohne erneutes Training auf andere Modellpaare übertragbar sind. RouterArenasup>[3]/sup> liefert die fehlende Evaluationsgrundlage: 8.400 Abfragen über Domänen und Schwierigkeitsgrade hinweg, bewertet nach Genauigkeit, Kosten, Routing-Optimalität, Robustheit und Router-Overhead.

Was keiner dieser Ansätze berücksichtigt, ist das Gespräch als Routing-Einheit. Eine Kaskade eskaliert eine Anfrage und vergisst; die nächste Runde führt dasselbe billige Modell erneut auf derselben inzwischen als schwierig bekannten Aufgabe aus. Ein auf Präferenzen trainierter Router bewertet eine Abfrage, keine Trajektorie. Die Lücke, die dieser Bericht adressiert, ist, was ein Router zwischen den Runden behalten sollte, wie lange, und was ihm erlaubt sein sollte, seine Meinung zu ändern — eine Frage, die erst dann dringend wird, wenn Prompt-Caching das Vergessen teuer macht.

OrcaRouter bringt eine im Quellbaum enthaltene RouterArena-Testumgebung (eval/) mit, die ihre fünf anfragebezogenen Strategien – cheapest, quality, balanced, linucb, gated_adaptive – gegen den offenen Datensatz benchmarkt, ohne das Upstream-Repository zu verändern. Der hier beschriebene Mechanismus auf Sitzungsebene ist orthogonal zu allen fünf und lässt sich mit ihnen kombinieren.

10 Fazit

Prompt-Caching hat die Ökonomie des LLM-Routings in einer Weise verändert, mit der die Routing-Literatur noch nicht Schritt gehalten hat. Sobald Kontinuität einen Rabatt von 10× auf die Mehrheit deiner Eingabe-Tokens wert ist, muss sich ein Router festlegen – und in dem Moment, in dem er sich festlegt, trifft er seine Entscheidung an dem Turn, an dem er am wenigsten weiß, und lebt mit dieser Entscheidung für die gesamte Dauer des Gesprächs. Routing auf Anfrageebene hat dieses Problem nicht und zahlt dafür mit Cache-Misses; naive Neuauswertung pro Turn führt die Misses wieder ein und fügt obendrein ein Artefakt der Längenverzerrung hinzu.

Gestufte Stickiness löst das, indem sie zwei Dinge trennt, die wie eines aussehen: welches Modell diese Session bedient (der Pin, stabil innerhalb einer Stufe) und welcher Stufe diese Session angehört (ein kleines, begrenztes, bestätigtes, ablaufendes Stück Zustand). In unserem Replay gewinnt diese Trennung 87 % der Sitzungen zurück, deren Schwierigkeit in Runde 1 nicht erkennbar ist, mit null Fehlalarmen bei 200 einfachen Sitzungen, zu 45 % der Kosten des Always-Frontier-Ansatzes — und hält eine Ausgabenobergrenze von 20 % ein, selbst gegenüber Kunden, die aktiv versuchen, sie zu umgehen.

Die ehrlichen Schwächen des Mechanismus sind Kalibrierung, nicht Architektur: ein Schwierigkeits-Gate, das aus einer Verteilung übernommen wurde, für die es nicht abgestimmt wurde, ein Feature-Term, der sein Budget nicht ausschöpfen kann, und zwei Züge unvermeidlicher Rettungslatenz. Diese sind behebbar. Der architektonische Anspruch — dass der Eskalationsspeicher vom Pin getrennt sein muss, dass kein unscharfes Signal allein die Ratsche betätigen darf und dass Obergrenzen die eigene ausdrückliche Anfrage des Clients binden müssen, weil der Client das Token hält — ist der Teil, den wir beibehalten würden.

11 Quellen

1. LMSYS Org. RouteLLM: Ein Open-Source-Framework für kosteneffizientes LLM-Routing. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · Code: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia & Zou. FrugalGPT: Wie man große Sprachmodelle nutzt und dabei Kosten senkt und die Leistung verbessert. 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: Eine offene Plattform für den umfassenden Vergleich von LLM-Routern. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Prompt-Caching in der API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — automatisches Caching, Präfix von ≥1.024 Token in 128-Token-Schritten, Verwerfung nach 5–10 Minuten Inaktivität, ≤1 Stunde; Rabatt auf gecachte Eingaben je nach Modellstufe. Preise: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Prompt-Caching. 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> — Cache-Lesezugriffe kosten 0,1× den Basiseingabepreis, Schreibzugriffe 1,25× (5-Minuten-TTL) oder 2× (1-Stunden-TTL); der Cache wird bei Nutzung aktualisiert. Preise: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. Die DeepSeek-API führt Context Caching auf der Festplatte ein. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automatisch, Abrechnung nach tatsächlichen Cache-Treffern, Reduktion um Größenordnungen pro Treffer.

7. Google. Kontext-Caching der Gemini-API. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — implizites und explizites Caching mit speicherpreisbasiertem TTL.

8. OrcaRouter-Quellcode, dieses Repository: service/session_affinity.go (Pins, TTLs, Tier-gebundene Schlüssel) · service/session_escalation.go (die Engine) · service/model_router.go:1374 (selectByStrategy: Tier-Eingrenzung vor dem Pin-Lesen) · service/model_router_difficulty.go (Gewichte und Obergrenzen) · service/model_router_delta.go (Delta-Extraktor) · service/escalation_strikes.go (anfrageseitige Produzenten) · service/escalation_caps.go (Anteils-Obergrenzen) · docs/features/frontier-escalation.md (Design, Review-Runden 1–4).

Reproduzierbarkeit. Das Mess-Harness ist ein Go-Test im Service-Paket, der ResolveEscalation / CommitEscalationDecision gegen miniredis ausführt, ergänzt durch eine Python-Analyse- und Abbildungs-Pipeline. Die Korpusgenerierung ist geseedet (rand.NewSource(20260814)) und der gesamte Lauf ist deterministisch: 400 Sitzungen, 3.968 Turns, drei Experimente (Haupt-Replay, adversarialer Cap-Lauf, 9-Punkte-Schwellenwert-Sweep). Die Abbildungen verwenden eine CVD-validierte kategoriale Palette; jede Abbildung ist mit ihrer zugrunde liegenden Tabelle gepaart. Es wurde auf keine Produktionsdaten zugegriffen, und kein Teil dieser Analyse wurde in das Repository übernommen.