OrcaRouter Routing Infra: sessiebewuste routing en frontier-escalatie

ORCAROUTER · ROUTING-ARCHITECTUUR

Elke LLM-gateway die prompts in de cache opslaat, moet een gesprek aan één model vastpinnen. Elke gateway die een gesprek vastpint, neemt zijn routeringsbeslissing op basis van de minst informatieve beurt van dat gesprek. Dit is een rapport over die afweging, en over het gelaagde kleefmechanisme dat OrcaRouter meelevert om eraan te ontsnappen.

Onderwerp: OrcaRouter LLM gateway (Go / Gin / Redis) · Component: sessie-affiniteit + Frontier Escalation engine · Methode: replay van 400 sessies tegen de productiebeslissingscode · Datum: 14 augustus 2026

SAMENVATTING — Request-level LLM-routing — het onafhankelijk scoren van elke aanvraag en het doorsturen naar het goedkoopste geschikte model — is het regime waar vrijwel al het gepubliceerde routeringsonderzoek zich op richt. Het is ook het verkeerde regime voor het verkeer dat nu de gateway-volume domineert: multi-turn agentsessies, waarbij de prompt voor 90 % bestaat uit meegenomen context en de promptcache van de provider betaalt voor continuïteit. Van model wisselen midden in een gesprek gooit een 10× korting op het gedeelde prefix weg, dus gateways pinnen sessies. Maar een pin die op beurt 1 wordt gezet, is een pin die wordt gezet op de beurt met de minste bewijskracht, en die blijft bestaan zolang het gesprek duurt.

100 / 100 — latent-hard-sessies waarvan de turn-1-score niet te onderscheiden is van een triviale

+16%verschuiving van de moeilijkheidsscore alleen al door de transcriptlengte, bij identieke taakmoeilijkheid

45% — van always-frontierkosten, voor 67 % van zijn hard-turndekking

0.019 — marge tussen de uitgebrachte gate en het plafond van realistische scores

1 Twee routeringsregimes

Een LLM-gateway die veel providers ontsluit, moet per verzoek één vraag beantwoorden: welk model bedient dit? Er zijn twee structureel verschillende manieren om die te beantwoorden, en de literatuur en de productiepraktijk zijn uit elkaar gegroeid over welke van de twee ertoe doet.

Routing op aanvraagniveau behandelt elk verzoek als onafhankelijk. Een scorer schat de moeilijkheidsgraad van de query of de voorspelde kwaliteit van het antwoord in, en het verzoek wordt doorgestuurd naar het goedkoopste model waarvan wordt verwacht dat het dit aankan. Dit is het paradigma van vrijwel al het gepubliceerde routerwerk: RouteLLM traint routers op voorkeursdata die 95 % van de GPT-4-kwaliteit halen met 14 % sterke-modelaanroepensup>[1]/sup>; FrugalGPT schakelt van goedkoop naar duur met een accept-/afwijzingscontrole en rapporteert tot 98 % kostenverlagingsup>[2]/sup>; RouterArena bouwt een benchmark met 8.400 queries om routers op precies deze as te vergelijkensup>[3]/sup>. De analyse-eenheid is de query.

Sessiebewuste routering

De reden waarom sessiebewuste routering bestaat is niet elegantie. Het is rekenkunde.

2 De cache-economie die stickiness verplicht maakt

In een multi-turn agent-sessie, beurt n z'n prompt is beurt n−1 z'n prompt plus een delta. Tegen beurt 10 is het overgedragen voorvoegsel de overgrote meerderheid van de invoertokens. Elke grote aanbieder prijst dat voorvoegsel nu anders, afhankelijk van of het een cache-hit is:

Tabel 1.Prompt-cache-semantiek per provider. De cache-sleutel bestaat uit een exact prefix en de serving key — een modelswitch of een keyrotatie is een cold read tegen de volledige prijs.

OrcaRouter codeert precies deze levensduren als pin-TTL's: een kaart van provider-cachevensters per kanaaltype — 5 minuten voor OpenAI, Anthropic en Gemini, 60 minuten voor DeepSeek — met een standaardwaarde van 5 minuten voor niet-toegewezen providers. De kanaal+sleutel-pin vervalt met dat venster, omdat een verouderde sleutelindex geen cachewaarde heeft en alleen maar de lastverdeling vertekent. De modelpin blijft 30 dagen bestaan bij een op Redis gebaseerde implementatie en voor een sessie-id die in aanmerking komt voor een langdurige pin — niet voor de cachewaarde, die allang verdwenen is, maar voor de continuïteit van het aanvraagformaat. Een modelwisseling midden in een gesprek forceert een conversie van het aanvraagformaat die data-incompatibel kan zijn: denkblokken en tool-call-ID's overleven niet noodzakelijkerwijs de vertaling tussen providerschema's.

Het ondergewaardeerde detail

Promptcaches zijn geïndexeerd per API-sleutel, niet per model. Een gateway die het model vastpint maar de last over drie sleutels op hetzelfde kanaal verdeelt, leest nog steeds bij twee van de drie beurten een koude cache. Dit is waarom de kanaalpin van OrcaRouter {ChannelID, KeyIndex} opslaat in plaats van een kanaal-id, en waarom de pin wordt verwijderd wanneer de geregistreerde sleutelindex niet langer naar een ingeschakelde sleutel verwijst — een gebooste maar geroteerde sleutel zou een koude cache bevoordelen terwijl de lastverdeling wordt omzeild, wat het slechtste van beide is.

De pins zijn zacht in alle gevallen: een niet-resolveerbaar sessie-id is een no-op, een uitgeschakeld of ongezond gepind kanaal degradeert naar normale gebalanceerde selectie, en een pin naar een kanaal met gewicht nul in een gemengde pool wordt genegeerd, zodat een beheerder die een kanaal leegmaakt niet wordt verslagen door plakkerigheid. Ze laten een verzoek nooit falen.

3 De valkuil: plakkerigheid schakelt de router uit

Dit is de foutmodus. In OrcaRouter's pre-escalatiecodepad retourneerde de sessie→model-pin voor een sessiebewuste router op elke niet-DSL-strategie

Dat zou aanvaardbaar zijn als beurt 1 representatief was. Dat is systematisch niet zo, om twee elkaar versterkende redenen.

3.1 Beurt 1 is de minst informatieve beurt

De moeilijkheidsscalar (service/model_router_difficulty.go) is een gewogen lineaire combinatie van zes lexicale kenmerken:

LogPromptTokens × 0,20, begrensd tot log(8001) ≈ 8,99

ReasoningCueCount × 0,15 maximum 5

SystemPromptLogLen × 0,10 begrensd tot log(2001) ≈ 7,60

CodeKeywordDensity × 0.20 max 5.0 (overeenkomsten per 100 tekens)

HasTools × 0.15 reeds 0/1

MathMarkerCount × 0,20 met een maximum van 5

Een korte opener zonder geschiedenis scoort laag, vrijwel per constructie: de tokenterm met gewicht 0,20 zit dicht bij zijn minimum, en de redeneer-/wiskundetermen worden geactiveerd door woordenschat die de gebruiker nog geen reden heeft gehad om te gebruiken. Sessies committeren zich daardoor aan een model met een zwakke pool op het moment van de minste informatie — en met een op Redis gebaseerde 30-daagse modelpin is die commitment langdurig.

Figuur 1. Gemiddelde moeilijkheid van de laatste beurt per conversatiebeurt, over 100 latent-moeilijke sessies en 200 werkelijk gemakkelijke sessies, beoordeeld door de productiescorer. Bij beurt 1 — de beurt waarop de sticky pin wordt geschreven — zijn de twee populaties niet te onderscheiden (0,210 tegen 0,208). De moeilijke populatie overschrijdt de drempel bij beurt 5. Onder een pin-only beleid worden alle 100 latent-moeilijke sessies aan de goedkope pool toegewezen voordat er enig bewijs van dat alles bestaat.

3.2 Lengte vermomt zich als moeilijkheid

Het tweede probleem is subtieler en het ondermijnt de voor de hand liggende oplossing. Als je eenvoudigweg de moeilijkheidsdrempel elke beurt opnieuw uitvoert, voer je hem opnieuw uit op een score die is berekend over het gehele aaneengeschakelde transcript. Die score heeft een ingebouwde opwaartse drift: de met 0,20 gewogen LogPromptTokens-term stijgt monotoon met de gesprekslengte, en voor elke agent-sessie zijn de 0,15 HasTools- en 0,10 SystemPromptLogLen-termen effectief constante vloeren. Een lange, saaie sessie ziet er steeds moeilijker uit.

Figuur 2. Het lengte-bias-artefact, gemeten over 60 sessies die volledig bestaan uit triviale bewerkingen (“hernoem deze variabele”, “voeg een nil-check toe”). De volledige-transcriptscore loopt +16 % op over 25 beurten bij constante taakmoeilijkheid; de score van de laatste beurt (delta) blijft vlak. Een naïeve herevaluatie van de volledige-transcriptscore bij elke beurt zou sessies escaleren vanwege het misdrijf dat ze lang zijn.

De fix die OrcaRouter meelevert is een aparte delta extractor (service/model_router_delta.go) die alleen de laatste beurt scoort — de nieuwe gebruikerstekst plus eventuele toolresultaten die na het laatste assistentbericht zijn toegevoegd — waarbij dezelfde gewichten en limieten worden hergebruikt, maar SystemPromptLogLen bewust op nul wordt gezet, aangezien dat geen onderdeel is van de delta. De vlakke blauwe lijn in figuur 2 is die extractor.

4 Ontwerp: getrapte kleefkracht

De naïeve uitweg uit de turn-1-lock-in is om elke beurt opnieuw te routeren — wat slechts routering op verzoekniveau is en de cache verspeelt. De naïeve oplossing in de andere richting is om de pin te laten fungeren als het geheugen van “deze sessie werd moeilijk” — wat geen de-escalatie kan uitdrukken en niet kan worden begrensd. Het ontwerp van OrcaRouter weigert beide.

De herformulering: een sessie is vastgepind aan een model binnen een tier, en een kleine Redis tierstate is het enige escalatiegeheugen. De modelpin is nooit het geheugen.

Tiergroepen. De sterke laag is de opgeloste escalatiepool (escalation_pool, die standaard de strong_pool van de router gebruikt). De basislaag is AllowedModels minus de sterke-laagpool; een model dat in beide voorkomt behoort tot de sterke laag. Binnen de basislaag blijft de zwakke/midden/sterke moeilijkheidsindeling van gated_adaptive precies zoals voorheen werken.

Tier-gebonden pinnen. De model-pin-sleutel van de sterke tier krijgt een :t:strong-suffix; de basistier laat de legacy-sleutel ongewijzigd. Escalatie, derhalve, behoudt de basis-pin, zodat een gede-escaleerde sessie — of een sessie die wordt hervat nadat de tier-status is verlopen — weer uitkomt op exact het model waarmee deze begon, niet op een willekeurige herkeuze. Sterke pinnen worden alleen met de korte TTL van het provider-venster geschreven: een sterke pin van 30 dagen zou de 4-uurs tier-status die hem rechtvaardigde overleven.

De gate draait eerst. In selectByStrategy (service/model_router.go:1374) wordt de tier vooraf bepaald, de kandidaatset beperkt tot de pool van de tier, en pas daarna wordt de sticky pin geraadpleegd — binnen die tier. Dit is de structurele oplossing voor §3: de moeilijkheidsberekening en de escalatietriggers draaien elke beurt, voordat de pin ze kan kortsluiten.

4.1 Drie triggerklassen, gerangschikt naar vertrouwen

Tabel 2. Escalatietriggers. Geen enkel vaag signaal leidt ooit uit zichzelf tot escalatie; alleen een expliciete klantvraag doet dat al bij n=1, en zelfs die houdt zich aan de limieten.

Drie hygiëne-invarianten zijn van structureel belang. Strikes worden via een ringbuffer op basis van request-id gededupliceerd, zodat door elkaar lopende client-retry's niet dubbel tellen. Infrastructuurfalen is nooit functioneel falen — 429's, 5xx's en kanaal-fallbacks leveren nooit een strike op; alleen kwaliteitssignalen na succes tellen. En een “turn” wordt gedefinieerd als een voltooide, succesvol gefactureerde aanvraag die de strike-evaluatie heeft doorlopen, dus mislukte aanvragen helpen noch het strike-verval noch de clean-turn-teller vooruit.

4.2 Resolve is puur; commit is uitgesteld.

De belangrijkste structurele eigenschap van de engine is dat ResolveEscalation niets schrijft. Het retourneert een beslissing plus een lijst van openstaande intenties. De distributeur past die intenties toe in zijn post-success-blok, op een verse leesbewerking binnen een Redis WATCH-transactie. Dit is belangrijk omdat de resolver draait op paden die nooit de toestand mogen muteren: speculatieve fallback-ketenresoluties, de alleen-lezen diagnostische eindpunten, en verzoeken die later 403 opleveren of upstream falen. Het opnieuw toepassen van intenties op verse toestand betekent ook dat een verouderde concurrerende schrijver een vastgelegde escalatie niet kan overschrijven, en dat twee gelijktijdige identieke escalaties idempotent samenvoegen.

4.3 Caps, en waarom ze alles binden

Een fout-positieve escalatie kost (strong − base) prijs × resterende warm-episode-tokens, en het kost dit stilzwijgend — niets faalt. De explosieradius wordt begrensd door limieten die gelden voor elke klasse:

escalation_max_per_session (standaard 1). De-escalatie en client-resets geven dit niet terug, waardoor het reset-loop gaming-pad wordt gesloten.

Een per-router escalatie-aandeelplafond (standaard 20 %) over een voortschrijdend venster van 24–48 uur van Redis-dagbakken, plus een werkruimtebreed cross-routerplafond. Bij het plafond wordt alle escalatierouting onderdrukt — inclusief expliciete verzoeken en eenmalige boosts.

De-escalatie alleen bij cache-koude grenzen, zodat een fout-positief beperkt is tot één warme episode.

De reden dat Klasse A zich aan de limieten houdt, is een conclusie van het dreigingsmodel, geen beleidsvoorkeur: op een API-gateway bepaalt degene die het werkruimtetoken bezit de headers. Een limietvrijgesteld 'de klant vroeg erom'-pad is een ongemeten uitgavenkanaal. §7 meet wat er gebeurt wanneer elke klant dit misbruikt.

4.4 De-escalatie is asymmetrisch van opzet

Escaleer op basis van bevestigd bewijs; de-escaleer alleen wanneer het gratis is. Een sterke sessie keert alleen terug naar de basis wanneer al het volgende van toepassing is: de sessie is cache-koud (langer inactief dan het providervenster dat bij escalatie is geregistreerd), er zijn ≥3 strikevrije geëvalueerde beurten verzameld, en de nieuwste delta-moeilijkheid ligt onder T1. Binnen het warme venster betaalt een switch een koude herlezing tegen de volle prijs — flapperen is de enige gegarandeerde manier om escalatie kostennegatief te maken.

5 Methode

We hebben het mechanisme gemeten door een synthetisch sessiecorpus af te spelen via de daadwerkelijke productiebeslissingscode. De testopstelling is een Go-test in het servicepakket die per beurt ResolveEscalation en CommitEscalationDecision aanroept tegen een op miniredis gebaseerde tieropslag, met de echte moeilijkheidsscorers, de echte strikeproducenten aan de verzoekzijde, en de echte share-cap-machinerie. Niets aan het beslissingspad is opnieuw geïmplementeerd of gemockt, behalve de audit-event-sink.

Wat is echt en wat niet

Echt: elke routeringsbeslissing, moeilijkheidsscore, strike-detectie, streak-regel, cap-evaluatie en Redis-statusovergang — dit zijn de opgeleverde functies. Synthetisch: het verkeer. Het corpus is gegenereerd, niet gesampled uit productielogs. De archetypemix (50 % moeilijk) is een stressmix die is gekozen om het mechanisme te testen, geen schatting van echt verkeer; §6.4 rapporteert de gevoeligheid voor die keuze, en die is groot. De schone precisiegetallen hieronder weerspiegelen een corpus waarvan de klassen per constructie scheidbaar zijn, en moeten worden gelezen als “het mechanisme slaat aan waar het voor ontworpen is”, niet als een schatting van de productieprecisie.

5.1 Corpus

400 sessies, 3,968 beurten, geseed en deterministisch. Elke beurt is een volledige chat-completions-aanvraagbody met de cumulatieve geschiedenis, een array met twee tool-definities en een realistische systeemprompt — de vorm die een codeeragent daadwerkelijk verzendt. Vijf archetypen, elk met een ground-truth-label:

Tabel 3.Corpussamenstelling. “Needs strong” is de ground truth die wordt gebruikt voor de precisie- en dekkingsscores.

Moeilijke beurten bevatten naast het proza een geplakte goroutine-dump of een bronfragment van 3–8 kB, want dat is wat een echte moeilijke debugbeurt bevat. Dit detail bleek enorm belangrijk te zijn — zie §6.2.

5.2 Kostenmodel

Kosten worden berekend op basis van gepubliceerde lijstprijzen met per-provider cache-semantiek; het model wordt volledig beschreven zodat het betwist kan worden.

Tabel 4.Parameters van het kostenmodel. Prijzen zijn $ per 1M tokens, prijslijst augustus 2026.

Een warme beurt kost 0.1·p_in·prefix + write·p_in·delta; een koude beurt kost write·p_in·prompt. Beurt 1 is altijd een volledige cache-schrijving. De tier-wisselbeurt onder het escalatiebeleid wordt expliciet als koud in rekening gebracht, dus het mechanisme betaalt voor zijn eigen cache-invalidatie.

Kwaliteit wordt gerapporteerd als dekking van moeilijke bochten — het aandeel van de volgens de ground truth moeilijke bochten dat daadwerkelijk door het sterke model is bediend — in plaats van als een nauwkeurigheidscijfer. We hebben geen upstream-inferentie uitgevoerd, dus we onthouden ons van het verzinnen van nauwkeurigheidscijfers.

6 Resultaten

6.1 Het mechanisme gaat af waar het voor ontworpen is.

Tabel 5. Escalatie-uitkomsten per archetype, automatische modus, canary 100 %, T2 = 0,70 (standaard meegeleverd).

Nul fout-positieven bij de 200 eenvoudige sessies, waaronder de 60 lange sessies waarbij een full-transcript-scorer in de moeilijke band zou zijn afgedwaald. De triggerklassen specialiseren zich netjes en zonder overlapping: difficulty vangt redeneer-intensief werk, strikes vangen faallussen. Merk op dat de piekdifficulty-score van failure_loop 0.262 is — de difficulty-gate ziet die sessies helemaal niet. Een agent die vastzit in een compileerfout-lus produceert geen proza dat bol staat van redeneer-cues; hij produceert dezelfde korte prompt met een andere stack trace. Zonder Class C strikes zou elk van die 60 sessies voor onbepaalde tijd op het goedkope model blijven malen.

Figuur 3. Wanneer sessies escaleren, splits op trigger. Door treffers gedreven escalaties zijn scherp geconcentreerd (beurt 4, de eerste beurt waarin twee treffers binnen het vervalvenster kunnen zijn opgebouwd); door moeilijkheid gedreven escalaties spreiden zich uit over beurten 2–11 volgens de aanvangsverdeling van het corpus. De regel van twee opeenvolgende beurten betekent dat de vroegst mogelijke moeilijkheidsescalatie beurt 2 is.

6.2 Bevinding: de geleverde poort staat op een klifrand.

Ons eerste corpus leverde nul moeilijkheidsgedreven escalaties op. De moeilijke beurten — beladen met racecondities, invarianten, complexiteitsanalyse en bewijsvocabulaire — piekten op 0.658 tegenover een drempel van 0.70. Het toevoegen van de geplakte stacktraces die echte debugbeurten daadwerkelijk met zich meebrengen, bracht ze naar 0.719. De drempel wordt overschreden met een marge van 0.019.

Figuur 4.Waar het moeilijkheidsbudget daadwerkelijk naartoe gaat, gemiddeld over 855 moeilijke en 3.113 gemakkelijke beurten. Een realistische moeilijke beurt bereikt 0,719 van een theoretisch deltamaximum van 0,90. De term CodeKeywordDensity draagt 0,069 van zijn budget van 0,20 bij — de gemeten dichtheid is 1,72 overeenkomsten per 100 tekens tegen een verzadigingslimiet van 5,0 — en de 0,10 van SystemPromptLogLen is structureel nul in de delta-extractor. Ruwweg een derde van het nominale bereik van de score is onbereikbaar met realistische tekst.

De drempelmeting bevestigt dat dit een klif is, geen helling. Over T2 van 0.35 tot 0.65 is de uitkomst identiek — 200 van de 400 sessies escaleren, met nul missers. Bij de uitgebrachte 0.70 begint de classifier sessies te verliezen; bij 0.75 stort de moeilijkheidsgestuurde escalatie in van 122 sessies naar 23.

Figuur 5. Drempelgevoeligheid. Het gehele bereik 0.35–0.65 is gedragsmatig identiek omdat er geen realistische deltatekst in terechtkomt — de scoreverdeling is bimodaal, met gemakkelijke beurten geclusterd rond 0.23 en moeilijke beurten rond 0.72, en niets daartussenin. De meegeleverde standaardwaarde ligt aan de bovenrand van de bovenste modus.

TECHNISCHE IMPLICATIE

T2 is gekalibreerd voor de full-transcript distributie waarop de gated_adaptive bands zijn afgestemd, en wordt hergebruikt als de drempel van de delta extractor. Het ontwerpdocument geeft aan dat de delta extractor “een eigen afstelling nodig heeft”; deze meting kwantificeert hoeveel. Ofwel de delta gate heeft een lagere eigen T2 nodig — overal tussen 0.45 en 0.60 levert hetzelfde gedrag op met ruime marge — ofwel de op percentielen gebaseerde drempel die al voor Fase 3 staat gepland (“top X % van het recente verkeer van deze router”) moet worden ingevoerd, wat de escalatie snelheid tot de knop van de operator maakt en absolute kalibratie volledig omzeilt.

6.3 Kosten en dekking

Figuur 6. Vijf beleidslijnen over dezelfde 400 sessies. Links: kosten per 1.000 sessies (logaritmische schaal). Rechts: fractie van werkelijk moeilijke beurten die door het sterke model worden afgehandeld.

Tabel 6. Beleidsvergelijking. Kosten per 1.000 sessies volgens het model in Tabel 4.

Twee resultaten zijn het waard om te onderscheiden. Ten eerste, alleen sessie-affiniteit bespaart 24 % bij identieke modelkeuze (16.64 → 12.63) en 35 % op het frontier-paar (290.93 → 188.30). Dat is pure cache-economie — dezelfde modellen, alles hetzelfde, alleen de sleutelplakkerigheid verschilt. De besparing is groter op het frontier-paar omdat Anthropic's 1.25× schrijfpremie koude beurten onevenredig duur maakt.

Ten tweede komt escalatie terecht waar een reddingsmechanisme zou moeten: 45 % van de always-frontier-kosten voor 67 % van zijn hard-turn-dekking, waarbij het sterke model slechts in 21,4 % van de gespreksbeurten wordt ingezet.

Het ontbrekende derde deel van de dekking is geen defect; het is de prijs van de ratel. De bevestigingsregels die nul vals-positieven opleveren, betekenen ook dat het mechanisme niet kan handelen bij de eerste zet van een probleem:

Tabel 7. Escalatie-latentie — harde bochten afgehandeld op het goedkope model voordat de ratel afgaat.

Twee omwentelingen is precies wat de regel voor een reeks van twee opeenvolgende omwentelingen voorschrijft, en één omwenteling is precies wat twee-aanslagen-tot-pal bepaalt. De vertraging is het ontwerp, en het is dezelfde eigenschap die nul vals-positieven opleverde. Iedereen die snellere redding wil, heeft de Class A-header, die bij n=1 werkt — dat is precies waarom het handmatige ontsnappingsluik als eerste werd uitgeleverd.

6.4 De kopverhouding hangt volledig af van je traffic.

Het corpus is door opzet voor 50% hard. Echt routerverkeer is dat niet, en de kostenvergelijking is daar uiterst gevoelig voor. Herweging van de gemeten kosten per archetype over een reeks prevalenties van harde sessies:

Figuur 7. Kosten per 1.000 sessies als functie van het aandeel van uw verkeer dat daadwerkelijk het sterke model nodig heeft. Het gedrag binnen de klassen wordt constant gehouden op de gemeten waarden; alleen de mix verandert.

Tabel 8. Prevalentiesensitiviteit, $ per 1.000 sessies.

Bij de door het ontwerpdocument zelf beoogde escalatiegraad van ≤5 % van de sessies bedragen de escalatiekosten 1,6× de rekening van de goedkope pool en 12 % van de frontier-rekening. Bij de stressmix van 50 % kosten ze 6,7× de rekening van de goedkope pool. Beide zijn waar; ze beantwoorden verschillende vragen. De operationeel relevante is de eerste, en dat is waarom het aandeelplafond standaard op 20 % staat in plaats van op 'uit' — het plafond, niet de precisie van de trigger, is wat de rekening daadwerkelijk begrenst.

6.5 De limieten houden stand onder kwaadwillig misbruik

We hebben het corpus opnieuw gedraaid met de echte share-cap-machinerie — geen stub, echte Redis-dagbuckets — onder het §8-bedreigingsmodel: elke client stuurt bij elke beurt X-OrcaRouter-Tier: strong.

Figuur 8. Misbruik van vijandelijke headers tegen de limiet van 20 % op het aandeel geëscaleerde verzoeken. De eerste 20 verzoeken zijn per ontwerp onbeperkt — de opwarmingsdrempel voorkomt dat '1 escalatie op de 2' als 50 % wordt gelezen en dat de functie op een nieuwe router wordt vergrendeld — waarna het aandeel convergeert en stabiel blijft. Eindtoestand: 296 van de 1.439 verzoeken werden sterk bediend (20,6 %), waarbij 1.143 expliciete verzoeken werden geweigerd en geauditeerd als denied_cap-gebeurtenissen.

De resterende overshoot van 0,6% is het beoogde gedrag van een strikt-grotere vergelijking op een benaderende trailing-teller, en de cap van 1 per sessie voorkomt dat individuele sessies het budget verbruiken. Elke weigering is zichtbaar voor de client in de X-Orca-Session-Tier: base; reason=denied:share_cap response-header en voor de operator in de audittabel — een onderdrukte escalatie is nooit stil.

7 Wat we zouden veranderen

Geef de delta-extractor zijn eigen drempelwaarde. Het hergebruik van de volledige transcript-T2 laat een marge van 0,019 over (§6.2). Een delta-specifieke T2 tussen 0,45 en 0,60 is gedragsmatig identiek op dit corpus, met twee ordes van grootte meer speling. Het al geplande percentieldrempelwerk omvat dit en is de betere oplossing.

Laat de term 'codedichtheid' niet decoratief blijven. Het draagt 0,069 van zijn budget van 0,20 bij aan de dichtste realistische tekst die we konden construeren, omdat het verzadigingsplafond van 5 treffers per 100 tekens ruwweg één code-trefwoord per twintig tekens impliceert. Herijk het tegen een gemeten productieverdeling of herverdeel het gewicht.

Class C is het werkpaard voor agentverkeer, en het is het minst ontwikkeld. De failure_loop-populatie is onzichtbaar voor de moeilijkheidsdrempel (piek 0.262) en wordt volledig opgevangen door strikes. Agentsessies mislukken door te lussen, niet doordat ze lexicaal moeilijker worden. De overige producenten aan de responsekant — en de nog ontbrekende native-Gemini streaming-capturehook — zijn meer waard dan verdere afstemming van de moeilijkheidsgraad.

Publiceer de escalatielatentie. Twee rondes hard werk, geleverd op het goedkope model, zijn de eerlijke prijs van een bevestigende ratel, en operators zouden dit in het analytics-paneel naast precisie moeten zien, in plaats van het te ontdekken.

8 Beperkingen

Het corpus is synthetisch. Het is geconstrueerd om schoon te scheiden, dus het resultaat met nul fout-positieven karakteriseert de specificiteit van het mechanisme op scheidbare invoer, niet zijn precisie op productieverkeer. Het werkelijke precisiegetal kan alleen komen uit de labelingstaak in schaduwmodus die het ontwerp specificeert — de volledige triggerpijplijn draait, er wordt niets gerouteerd en beslissingen worden achteraf gelabeld — met een go-live-drempel van ≥70 % gelabelde precisie.

Het kostenmodel gaat uit van een vaste 500 outputtokens per beurt, waardoor een reëel effect wordt onderdrukt: frontier-modellen genereren meer redeneertokens, dus de werkelijke frontierpremie wordt onderschat. Het modelleert ook de cache-warmte op verzoekniveau als een uniforme 1/N over de key-slots; een gewogen pool zou de Herfindahl-index Σw² gebruiken, en een single-key-kanaal zou op kanaalniveau helemaal geen cachevoordeel voor sessie-affiniteit laten zien — hoewel de pin op modelniveau nog steeds van belang is voor adaptieve strategieën.

We hebben geen upstream-inferentie uitgevoerd, dus er wordt geen uitspraak gedaan over nauwkeurigheid of taaksucces. Hard-turn-dekking is een proxy voor kwaliteit, en het veronderstelt dat het sterke model daadwerkelijk beter is op die beurten — plausibel voor de geconstrueerde archetypen, hier niet geverifieerd.

Tot slot meet dit de implementatie van één gateway. De turn-1-lock-in-foutmodus zou moeten generaliseren naar elke cache-bewuste router die sessies vasthoudt, maar de specifieke getallen zijn eigenschappen van deze drempels, deze gewichten en deze prijzen.

9 Gerelateerd werk

Routing op verzoekniveau is goed behandeld. FrugalGPTsup>[2]/sup> introduceerde de LLM-cascade — het goedkope model bevragen, het antwoord beoordelen, bij lage zekerheid escaleren — met een gerapporteerde kostenreductie van tot 98 % bij gelijke nauwkeurigheid. RouteLLMsup>[1]/sup> traint routers op basis van voorkeursgegevens van Chatbot Arena en rapporteert 95 % van de GPT-4-kwaliteit met 14 % aanroepen van sterke modellen, met routers die zonder hertraining overdraagbaar zijn tussen modelparen. RouterArenasup>[3]/sup> levert de ontbrekende evaluatiebasis: 8.400 queries over domeinen en moeilijkheidsgraden, beoordeeld op nauwkeurigheid, kosten, routeringsoptimaliteit, robuustheid en routeroverhead.

Waar geen van deze op ingaat, is het gesprek als routeringseenheid. Een cascade escaleert een verzoek en vergeet het; de volgende beurt voert hetzelfde goedkope model opnieuw uit op dezelfde inmiddels als moeilijk bekende taak. Een op voorkeuren getrainde router beoordeelt een query, niet een traject. De leemte die dit rapport aanpakt, is wat een router zich tussen beurten moet herinneren, hoe lang, en wat hem van mening mag laten veranderen — een vraag die pas urgent wordt zodra prompt-caching vergeten duur maakt.

OrcaRouter levert een in-tree RouterArena-harness (eval/) die zijn vijf strategieën op verzoekniveau — cheapest, quality, balanced, linucb, gated_adaptive — benchmarkt tegen de open dataset zonder de upstream-repository te wijzigen. Het hier beschreven mechanisme op sessieniveau is orthogonaal aan en combineerbaar met alle vijf.

10 Conclusie

Promptcaching heeft de economie van LLM-routering veranderd op een manier waar de routeringsliteratuur nog niet op is ingespeeld. Zodra continuïteit een 10× korting oplevert op het merendeel van je inputtokens, moet een router vastpinnen — en op het moment dat hij vastpint, neemt hij zijn beslissing op de beurt waarover hij het minst weet, en blijft hij die beslissing de rest van het gesprek volgen. Routering op aanvraagniveau heeft dit probleem niet en betaalt daarvoor met cachemissers; naïeve herevaluatie per beurt introduceert de missers opnieuw en voegt bovendien een lengtevoorkeursartefact toe.

Gelaagde stickiness lost het op door twee dingen te scheiden die op één ding lijken: welk model deze sessie bedient (de pin, stabiel binnen een laag) en tot welke laag deze sessie behoort (een klein, begrensd, bevestigd, vervallend stukje status). In onze replay vindt die scheiding 87 % van de sessies terug waarvan de moeilijkheidsgraad bij beurt 1 niet detecteerbaar is, met nul vals-positieven op 200 gemakkelijke sessies, tegen 45 % van de always-frontier-kosten — en handhaaft een uitgavenplafond van 20 % tegen clients die actief proberen het te verslaan.

De eerlijke zwakheden van het mechanisme zijn kalibratie, niet architectuur: een moeilijkheidsdrempel die is hergebruikt uit een verdeling waarvoor hij niet is afgesteld, een featureterm die zijn budget niet kan halen, en een onvermijdelijke reddingslatentie van twee beurten. Die zijn aanpakbaar. De architectuurbewering — dat het escalatiegeheugen gescheiden moet zijn van de pin, dat geen vaag signaal alleen een ratchet-effect mag veroorzaken, en dat limieten de eigen expliciete aanvraag van de cliënt moeten binden omdat de cliënt het token houdt — is het deel dat we zouden behouden.

11 Bronnen

1. LMSYS Org. RouteLLM: een open-source raamwerk voor kosteneffectieve LLM-routering. 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: hoe u grote taalmodellen gebruikt terwijl u kosten verlaagt en prestaties verbetert. 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: een open platform voor uitgebreide vergelijking van LLM-routers. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Prompt Caching in de API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — automatische caching, prefix van ≥1.024 tokens in stappen van 128 tokens, verwijdering bij inactiviteit na 5–10 minuten, ≤1 uur; korting op gecachte invoer per modelniveau. Prijzen: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Promptcaching. 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> — cachelezen 0,1× basisinput, schrijven 1,25× (TTL van 5 minuten) of 2× (TTL van 1 uur), ververst bij gebruik. Prijzen: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. DeepSeek API introduceert Context Caching on Disk. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automatisch, gefactureerd op daadwerkelijke cache-hits, orde-van-grootte-reductie bij een hit.

7. Google. Gemini API context caching. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — impliciete en expliciete caching met TTL tegen opslagprijzen.

8. OrcaRouter-bron, deze repository: service/session_affinity.go (pins, TTL's, tier-gebonden sleutels) · service/session_escalation.go (de engine) · service/model_router.go:1374 (selectByStrategy: tier-vernauwing vóór het lezen van de pin) · service/model_router_difficulty.go (gewichten en limieten) · service/model_router_delta.go (delta-extractor) · service/escalation_strikes.go (producenten aan de request-zijde) · service/escalation_caps.go (aandelenlimieten) · docs/features/frontier-escalation.md (ontwerp, reviewrondes 1–4).

Reproduceerbaarheid. De meetopstelling bestaat uit een Go-test in het servicepakket die met behulp van miniredis ResolveEscalation / CommitEscalationDecision aanstuurt, en een Python-pijplijn voor analyse en figuren. De corpusgeneratie is geseed (rand.NewSource(20260814)) en de volledige run is deterministisch: 400 sessies, 3.968 beurten, drie experimenten (hoofd-replay, adversarial cap-run, 9-punts drempelsweep). Figuren gebruiken een CVD-gevalideerd categorisch palet; elke figuur is gekoppeld aan de bijbehorende onderliggende tabel. Er is geen productiedata benaderd, en geen enkel onderdeel van deze analyse is in de repository gecommit.