OrcaRouter Infrastructure de routage : routage sensible à la session et escalade de frontière

ORCAROUTER · ARCHITECTURE DE ROUTAGE

Chaque passerelle LLM qui met en cache les prompts doit épingler une conversation à un seul modèle. Chaque passerelle qui épingle une conversation prend sa décision de routage sur le tour le moins informatif de cette conversation. Ceci est un rapport sur ce compromis, ainsi que sur le mécanisme de stickiness à plusieurs niveaux qu'OrcaRouter intègre pour y échapper.

Objet : passerelle LLM OrcaRouter (Go / Gin / Redis) · Composant : affinité de session + moteur Frontier Escalation · Méthode : rejeu de 400 sessions contre le code de décision de production · Date : 14 août 2026

RÉSUMÉ — Le routage LLM au niveau de la requête — qui évalue chaque requête indépendamment et l’achemine vers le modèle adéquat le moins cher — est le régime que traite la quasi-totalité des travaux publiés sur les routeurs. C’est aussi le mauvais régime pour le trafic qui domine désormais le volume des passerelles : les sessions d’agents multi-tours, où le prompt est composé à 90 % de contexte reporté et où le cache de prompt du fournisseur récompense la continuité. Changer de modèle en cours de conversation fait perdre une remise de 10× sur le préfixe partagé ; c’est pourquoi les passerelles épinglent les sessions. Mais une épingle posée au tour 1 est posée au tour où l’on dispose du moins de preuves, et elle persiste pour toute la durée de la conversation.

100 / 100 — sessions à difficulté latente dont le score au premier tour est indiscernable de celui d'une session triviale

+16% — dérive du score de difficulté due à la seule longueur de la transcription, à difficulté de tâche identique

45 % — du coût toujours-frontière, pour 67 % de sa couverture en virage serré

0.019 — marge entre le seuil livré et le plafond des scores réalistes

1 Deux régimes de routage

Une passerelle LLM qui se place devant de nombreux fournisseurs doit répondre à une question par requête : quel modèle répond à cette requête ? Il existe deux manières structurellement différentes d'y répondre, et la littérature et la réalité de la production ont divergé sur celle qui compte.

Routage au niveau de la requête traite chaque requête comme indépendante. Un estimateur évalue la difficulté de la requête ou la qualité prédite de la réponse, et la requête est envoyée au modèle le moins coûteux censé pouvoir la traiter. C’est le cadre de pratiquement tous les travaux publiés sur les routeurs : RouteLLM entraîne des routeurs sur des données de préférence qui atteignent 95 % de la qualité de GPT-4 avec 14 % d’appels à des modèles puissantssup>[1]/sup> ; FrugalGPT effectue une cascade du moins cher au plus cher avec un contrôle d’acceptation/rejet et fait état d’une réduction des coûts allant jusqu’à 98 %sup>[2]/sup> ; RouterArena construit un benchmark de 8 400 requêtes pour comparer les routeurs sur exactement cet axesup>[3]/sup>. L’unité d’analyse est la requête.

Routage tenant compte de la session

La raison pour laquelle le routage sensible à la session existe n'est pas l'élégance. C'est l'arithmétique.

2 L'économie du cache qui rend la rétention obligatoire

Dans une session d'agent multi-tours, le prompt du tour n est le prompt du tour n−1 plus un delta. Au tour 10, le préfixe reporté constitue l'écrasante majorité des jetons d'entrée. Chaque grand fournisseur tarifie désormais ce préfixe différemment selon qu'il s'agit d'un cache hit :

Tableau 1.Sémantique du cache de prompt par fournisseur. Le cache est indexé sur un préfixe exact et sur la clé de service — un changement de modèle ou une rotation de clé équivaut à une lecture à froid au prix fort.

OrcaRouter encode exactement ces durées de vie comme TTL de pin : une carte par type de canal des fenêtres de cache du fournisseur — 5 minutes pour OpenAI, Anthropic et Gemini, 60 minutes pour DeepSeek — avec une valeur par défaut de 5 minutes pour les fournisseurs non mappés. Le pin canal+clé expire avec cette fenêtre, car un index de clé obsolète n'a aucune valeur de cache et ne fait que fausser l'équilibrage de charge. Le modèle pin, sur un déploiement Redis et pour un identifiant de session éligible au pin long, persiste pendant 30 jours — non pas pour la valeur de cache, qui a disparu depuis longtemps, mais pour la continuité du format de requête. Un changement de modèle en pleine conversation force une conversion du format de requête qui peut être incompatible avec les données : les blocs de réflexion et les identifiants d'appel d'outil ne survivent pas nécessairement à la traduction entre les schémas des fournisseurs.

Le détail sous-estimé

Les caches de prompt sont indexéspar clé API, pas par modèle. Une passerelle qui épingle le modèle mais répartit la charge entre trois clés sur le même canal effectue encore deux lectures à froid sur trois tours. C'est pourquoi l'épingle de canal d'OrcaRouter stocke {ChannelID, KeyIndex} plutôt qu'un identifiant de canal, et pourquoi l'épingle est abandonnée lorsque l'index de clé enregistré ne correspond plus à une clé activée — une clé boostée mais permutée biaiserait vers un cache à froid tout en contournant l'équilibrage, ce qui cumule le pire des deux mondes.

Les épinglages sont souples dans l’ensemble : un identifiant de session non résoluble est une opération nulle, un canal épinglé désactivé ou non sain retombe sur une sélection équilibrée normale, et un épinglage vers un canal de poids zéro dans un pool mixte est ignoré, afin qu’un administrateur qui draine un canal ne soit pas contrecarré par la persistance de session. Ils ne font jamais échouer une requête.

3 Le piège : la persistance désactive le routeur

Voici le mode de défaillance. Dans le chemin de code de pré-escalade d'OrcaRouter, pour un routeur sensible à la session sur toute stratégie non-DSL, la broche session→modèle a renvoyé

Cela serait tolérable si le tour 1 était représentatif. Ce n'est systématiquement pas le cas, pour deux raisons qui se cumulent.

3.1 Le tour 1 est le tour le moins informatif.

Le scalaire de difficulté (service/model_router_difficulty.go) est une combinaison linéaire pondérée de six caractéristiques lexicales :

LogPromptTokens × 0,20 plafonné à log(8001) ≈ 8,99

ReasoningCueCount × 0.15 plafond 5

SystemPromptLogLen × 0.10, plafonné à log(2001) ≈ 7.60

CodeKeywordDensity × 0,20 plafond 5,0 (correspondances pour 100 caractères)

HasTools × 0,15 déjà 0/1

MathMarkerCount × 0.20 plafond 5

Un court message d'ouverture sans historique obtient un score faible presque par construction : le terme token pondéré à 0,20 est proche de son plancher, et les termes de raisonnement/mathématiques se déclenchent sur un vocabulaire que l'utilisateur n'a pas encore eu de raison d'utiliser. Les sessions s'engagent donc envers un modèle de pool faible au moment où l'information est la plus réduite — et avec un ancrage de modèle de 30 jours adossé à Redis, cet engagement est long.

Figure 1. Difficulté moyenne du dernier tour par tour de conversation, sur 100 sessions latent-difficiles et 200 sessions vraiment faciles, évaluées par le scoreur de production. Au tour 1 — le tour où l'épingle collante est écrite — les deux populations sont indiscernables (0,210 contre 0,208). La population difficile franchit le seuil au tour 5. Avec une politique basée uniquement sur l'épingle, les 100 sessions latent-difficiles sont toutes engagées dans le pool bon marché avant que la moindre preuve n'existe.

3.2 La longueur se fait passer pour la difficulté

Le deuxième problème est plus subtil et il sape la solution évidente. Si vous ré-exécutez simplement le seuil de difficulté à chaque tour, vous le ré-exécutez sur un score calculé sur l'intégralité de la transcription concaténée. Ce score a une dérive à la hausse intégrée : le terme LogPromptTokens pondéré à 0,20 augmente de manière monotone avec la longueur de la conversation, et pour toute session d'agent, les termes HasTools à 0,15 et SystemPromptLogLen à 0,10 sont effectivement des planchers constants. Une session longue et ennuyeuse semble de plus en plus difficile.

Figure 2. L'artefact de biais de longueur, mesuré sur 60 sessions composées entièrement de modifications triviales (« renommer cette variable », « ajouter une vérification nil »). Le score de la transcription complète dérive de +16 % sur 25 tours à difficulté de tâche constante ; le score du dernier tour (delta) est stable. Une réévaluation naïve du score de la transcription complète à chaque tour ferait escalader les sessions pour le crime d'être longues.

Le correctif fourni par OrcaRouter est un delta extracteur séparé (service/model_router_delta.go) qui ne score que le dernier tour — le nouveau texte utilisateur plus les éventuels résultats d'outils attachés après le dernier message de l'assistant — en réutilisant les mêmes poids et plafonds, mais en mettant délibérément SystemPromptLogLen à zéro, qui ne fait pas partie du delta. La ligne bleue plate de la figure 2 est cet extracteur.

4 Conception : adhérence par paliers

L'échappatoire naïve au verrouillage du premier tour consiste à réacheminer à chaque tour — ce qui n'est qu'un routage au niveau de la requête, et sacrifie le cache. La solution naïve dans l'autre sens consiste à faire de l'épingle la mémoire du fait que « cette session est devenue difficile » — ce qui ne peut exprimer la désescalade ni être plafonné. La conception d'OrcaRouter refuse les deux.

Le recadrage : une session est épinglée à un modèle au sein d'un palier, et un petit Redis d'état de palier est la seule mémoire d'escalade. L'épinglage du modèle n'est jamais la mémoire.

Pools de niveaux. Le niveau fort est le pool d'escalade résolu (escalation_pool, par défaut le strong_pool du routeur). Le niveau de base est AllowedModels \ pool du niveau fort ; un modèle présent dans les deux appartient au niveau fort. Dans le niveau de base, le découpage en bandes de difficulté faible/moyen/fort de gated_adaptive continue de fonctionner exactement comme avant.

Épingles à portée de palier. La clé d’épinglage du modèle du palier fort reçoit un suffixe :t:strong ; le palier de base conserve la clé héritée inchangée. L’escalade, donc, préserve l’épingle de base, de sorte qu’une session désescaladée — ou une session reprise après l’expiration de l’état du palier — revient sur le modèle exact sur lequel elle a commencé, et non sur un re-choix arbitraire. Les épingles fortes sont écrites uniquement avec la TTL courte de la fenêtre du fournisseur : une épingle forte de 30 jours survivrait à l’état du palier de 4 heures qui l’a justifiée.

La porte s'exécute en premier. Dans selectByStrategy (service/model_router.go:1374), le palier est résolu en amont, l'ensemble des candidats est réduit au pool du palier, et ce n'est qu'ensuite que la broche collante est consultée — au sein de ce palier. C'est le correctif structurel du §3 : le calcul de difficulté et les déclencheurs d'escalade s'exécutent à chaque tour, avant que la broche ne puisse les court-circuiter.

4.1 Trois classes de déclencheurs, classées par niveau de confiance

Tableau 2. Déclencheurs d’escalade. Aucun signal flou ne s’amplifie jamais seul ; seule une demande explicite du client engage à n=1, et même celle-ci respecte les plafonds.

Trois invariants d'hygiène sont essentiels. Les sanctions sont dédupliquées par identifiant de requête via un tampon en anneau, de sorte que les nouvelles tentatives entrelacées d'un client ne peuvent pas être comptées deux fois.Une défaillance d'infrastructure n'est jamais une défaillance de capacité. — Les 429, 5xx et les bascules de canal ne déclenchent jamais de sanction ; seuls les signaux de qualité post-succès comptent. Et un « tour » est défini comme une requête terminée, facturée avec succès, qui a fait l'objet d'une évaluation de sanction, de sorte que les requêtes échouées n'avancent ni la décroissance des sanctions ni le compteur de tours propres.

La résolution est pure ; le commit est différé.

La propriété structurelle la plus déterminante du moteur est que ResolveEscalation n'écrit rien. Elle renvoie une décision et une liste d'intentions. Le distributeur applique ces intentions dans son bloc post-succès, sur une lecture fraîche dans une transaction WATCH Redis. C'est important, car le résolveur s'exécute sur des chemins qui ne doivent jamais modifier l'état : les résolutions spéculatives de chaîne de repli, les points de terminaison de diagnostic en lecture seule, et les requêtes qui renvoient ensuite une erreur 403 ou échouent en amont. Réappliquer les intentions sur un état frais signifie aussi qu'un processus d'écriture concurrent obsolète ne peut pas écraser une escalade validée, et que deux escalades identiques en course fusionnent de manière idempotente.

4.3 Les majuscules, et pourquoi elles lient tout

Une escalade de faux positif coûte (strong − base) price × jetons d’épisode chaud restants, et ce coût est silencieux — rien n’échoue. Le rayon d’explosion est limité par des plafonds qui s’appliquent à chaque classe :

escalation_max_per_session (par défaut 1). La désescalade et les réinitialisations du client ne le remboursent pas, ce qui ferme la voie à l'exploitation de la boucle de réinitialisation.

Par routeur, un plafond de part d'escalade (par défaut 20 %) sur une fenêtre glissante de 24 à 48 heures de compartiments journaliers Redis, plus un plafond inter-routeurs à l'échelle de l'espace de travail. Au plafond, tout routage d'escalade est supprimé — y compris les demandes explicites et les boosts ponctuels.

Désescalade uniquement aux limites de cache froid, donc un faux positif est limité à un seul épisode chaud.

La raison pour laquelle la classe A respecte les plafonds est une conclusion du modèle de menace, pas une préférence politique : sur une passerelle API, quiconque détient le jeton d’espace de travail contrôle les en-têtes. Un chemin exonéré de plafond du type « le client l’a demandé » constitue un canal de dépenses non mesuré. Le §7 mesure ce qui se passe lorsque chaque client en abuse.

4.4 La désescalade est asymétrique par conception

Escaladez sur la base de preuves corroborées ; ne désescaladez que lorsque c'est gratuit. Une session robuste ne revient à la base que lorsque l'ensemble de : la session est à cache froid (inactive au-delà de la fenêtre du fournisseur enregistrée lors de l'escalade), elle a accumulé ≥3 tours évalués sans pénalité, et la dernière difficulté delta est inférieure à T1. Dans la fenêtre chaude, un basculement paie une relecture à froid au prix fort — le flapping est le seul moyen garanti de rendre l'escalade à coût négatif.

5 Méthode

Nous avons mesuré le mécanisme en rejouant un corpus de sessions synthétiques à travers le code de décision de production réel. Le harnais est un test Go dans le package de service qui appelle ResolveEscalation et CommitEscalationDecision à chaque tour contre un magasin de niveaux adossé à miniredis, avec les vrais scoreurs de difficulté, les vrais producteurs de frappes côté requête, et la vraie machinerie de plafonnement des parts. Rien dans le chemin de décision n'est réimplémenté ou simulé, sauf le puits d'événements d'audit.

Ce qui est réel et ce qui ne l'est pas.

Réel : chaque décision de routage, score de difficulté, détection de faute, règle de série, évaluation de plafond et transition d'état Redis — ce sont les fonctions livrées. Synthétique : le trafic. Le corpus est généré, non échantillonné à partir des journaux de production. Son mélange d'archétypes (50 % difficiles) est un mélange de stress choisi pour exercer le mécanisme, pas une estimation du trafic réel ; le §6.4 rapporte la sensibilité à ce choix, et elle est importante. Les chiffres de précision propres ci-dessous reflètent un corpus dont les classes sont séparables par construction, et doivent être lus comme « le mécanisme se déclenche là où il a été conçu pour le faire », et non comme une estimation de précision en production.

5.1 Corpus

400 sessions, 3 968 tours, avec graine et déterministes. Chaque tour est un corps de requête complet de chat-completions contenant l'historique cumulé, un tableau de définition de deux outils et un prompt système réaliste — la forme qu'un agent de codage envoie réellement. Cinq archétypes, chacun portant une étiquette de vérité terrain :

Tableau 3. Composition du corpus. « Needs strong » est la vérité terrain utilisée pour les scores de précision et de couverture.

Les tours difficiles contiennent un dump de goroutine collé ou un extrait de code source de 3 à 8 Ko en plus du texte, car c'est ce que contient un véritable tour de débogage difficile. Ce détail s'est avéré extrêmement important — voir §6.2.

5.2 Modèle de coût

Les coûts sont calculés à partir des prix catalogue publiés, avec une sémantique de cache par fournisseur ; le modèle est énoncé dans son intégralité afin de pouvoir être contesté.

Tableau 4. Paramètres du modèle de coût. Les prix sont en dollars par million de jetons, liste de prix d'août 2026.

Un tour à chaud coûte 0.1·p_in·prefix + write·p_in·delta ; un tour à froid coûte write·p_in·prompt. Le tour 1 est toujours une écriture complète du cache. Le tour de changement de niveau dans le cadre de la politique d'escalade est explicitement facturé comme un tour à froid, de sorte que le mécanisme paie pour sa propre invalidation de cache.

La qualité est présentée comme la couverture des tours difficiles — la fraction des tours difficiles selon la vérité terrain effectivement pris en charge par le modèle fort — plutôt que comme un score d’exactitude. Nous n’avons pas exécuté d’inférence en amont, nous nous abstenons donc d’inventer des chiffres d’exactitude.

6 Résultats

6.1 Le mécanisme se déclenche à l'endroit prévu.

Tableau 5. Résultats d'escalade par archétype, mode auto, canary 100 %, T2 = 0,70 (défaut fourni).

Zéro faux positif sur les 200 sessions faciles, y compris les 60 longues qui, avec un évaluateur de transcription complète, auraient dérivé vers la bande difficile. Les classes de déclenchement se spécialisent de manière nette et sans chevauchement : la difficulté détecte les tâches à forte charge de raisonnement, les strikes détectent les boucles d'échec. Notons que le score de difficulté maximal de failure_loop est de 0.262 — le portail de difficulté ne voit jamais ces sessions du tout. Un agent coincé dans une boucle d'erreur de compilation ne produit pas de prose dense en indices de raisonnement ; il produit le même prompt court avec une trace de pile différente. Sans les strikes de classe C, chacune de ces 60 sessions tournerait indéfiniment sur le modèle bon marché.

Figure 3.Lorsque les sessions s'intensifient, répartissez-les selon le déclencheur. Les escalades déclenchées par les frappes sont fortement concentrées (tour 4, le premier tour où deux frappes peuvent s'être accumulées dans la fenêtre de décroissance) ; les escalades déclenchées par la difficulté se répartissent sur les tours 2 à 11, suivant la distribution d'apparition du corpus. La règle de la série de deux tours consécutifs signifie que l'escalade de difficulté la plus précoce possible est le tour 2.

6.2 Constat : le portail livré se trouve au bord d'une falaise.

Notre premier corpus a produit zéro escalades motivées par la difficulté. Les tours difficiles — chargés de conditions de course, d'invariants, d'analyse de complexité et de vocabulaire de preuve — ont culminé à 0,658 contre un seuil de 0,70. L'ajout des traces de pile collées que les véritables tours de débogage comportent les a poussés à 0,719. Le seuil est franchi avec une marge de 0,019.

Figure 4.Où va réellement le budget de difficulté, en moyenne sur 855 tours difficiles et 3 113 tours faciles. Un tour difficile réaliste atteint 0,719 d'un delta maximum théorique de 0,90. Le terme CodeKeywordDensity contribue pour 0,069 de son budget de 0,20 — la densité mesurée est de 1,72 correspondances pour 100 caractères, contre un plafond de saturation de 5,0 — et le 0,10 de SystemPromptLogLen est structurellement nul dans l'extracteur de delta. Environ un tiers de la plage nominale du score est inaccessible à un texte réaliste.

Le balayage de seuil confirme qu'il s'agit d'une falaise, pas d'une pente. Sur T2 de 0.35 à 0.65, le résultat est identique — 200 sessions sur 400 escaladent, avec zéro raté. Au seuil livré de 0.70, le classificateur commence à manquer des sessions ; à 0.75, l'escalade pilotée par la difficulté s'effondre, passant de 122 sessions à 23.

Figure 5. Sensibilité au seuil. Toute la plage 0,35–0,65 est identique sur le plan comportemental, car aucun texte delta réaliste ne s'y trouve — la distribution des scores est bimodale, avec des tours faciles regroupés près de 0,23 et des tours difficiles près de 0,72, et rien entre les deux. La valeur par défaut livrée se situe au bord supérieur du mode supérieur.

IMPLICATION TECHNIQUE

T2 is calibrated for the full-transcript distribution the gated_adaptive bands were tuned on, and it is being reused as the delta extractor's threshold. The design document flags that the delta extractor “needs its own tuning”; this measurement quantifies how much. Either the delta gate needs a lower T2 of its own — anywhere in 0.45–0.60 buys identical behaviour with real margin — or the percentile-based threshold already scheduled for Phase 3 (“top X % of this router's recent traffic”) should land, which makes the escalation rate the operator's knob and sidesteps absolute calibration entirely.

6.3 Coût et couverture

Figure 6. Cinq politiques sur les mêmes 400 sessions. À gauche : coût pour 1 000 sessions (échelle logarithmique). À droite : fraction des tours vraiment difficiles servis par le modèle fort.

Tableau 6.Comparaison des politiques. Coût par 1 000 sessions selon le modèle du Tableau 4.

Deux résultats méritent d'être distingués. Premièrement, l'affinité de session à elle seule permet d'économiser 24 % à modèle identique (16,64 → 12,63) et 35 % sur la paire de pointe (290,93 → 188,30). C'est une pure économie de cache — mêmes modèles, mêmes paramètres, seule la persistance de la clé diffère. L'économie est plus importante sur la paire de pointe, car la prime d'écriture de 1,25× d'Anthropic rend les tours à froid disproportionnellement coûteux.

Deuxièmement, l'escalade se produit là où un mécanisme de secours devrait se trouver : 45 % du coût de l'utilisation systématique du modèle de pointe pour 67 % de sa couverture des tours difficiles, servant le modèle fort sur seulement 21.4 % des tours.

Le tiers manquant de couverture n'est pas un défaut ; c'est le prix du cliquet. Les règles de corroboration qui donnent zéro faux positif signifient aussi que le mécanisme ne peut pas agir dès le premier tour d'un problème :

Tableau 7. Latence d'escalade — virages serrés servis sur le modèle bon marché avant que le cliquet ne se déclenche.

Deux tours est exactement ce que spécifie la règle de la série de deux tours consécutifs, et un tour est exactement ce que spécifie la règle de deux frappes pour le cliquet. La latence est voulue, et c'est la même propriété qui a produit zéro faux positif. Quiconque veut un sauvetage plus rapide dispose de l'en-tête de classe A, qui agit à n=1 — c'est précisément pourquoi la trappe d'évacuation manuelle a été livrée en premier.

6.4 Le ratio du titre dépend entièrement de votre trafic.

Le corpus est composé à 50 % de sessions difficiles par construction. Le trafic réel des routeurs ne l'est pas, et la comparaison des coûts y est extrêmement sensible. En repondérant les coûts mesurés par archétype sur une gamme de prévalences de sessions difficiles :

Figure 7. Coût par 1 000 sessions en fonction de la part de votre trafic qui a réellement besoin du modèle puissant. Le comportement au sein de chaque classe est maintenu aux valeurs mesurées ; seule la répartition change.

Tableau 8.Sensibilité de la prévalence, $ pour 1 000 séances.

Au taux d'escalade cible propre au document de conception, soit ≤5 % des sessions, l'escalade coûte 1,6× la facture du pool bon marché et 12 % de la facture du pool frontier. Avec le mélange de stress à 50 %, elle coûte 6,7× la facture du pool bon marché. Les deux affirmations sont vraies ; elles répondent à des questions différentes. Celle qui est pertinente sur le plan opérationnel est la première, et c'est pourquoi le plafond de part est défini par défaut à 20 % plutôt que sur « désactivé » — c'est le plafond, et non la précision du déclencheur, qui borne réellement la facture.

6.5 Les plafonds résistent aux abus malveillants

Nous avons ré-exécuté le corpus avec la véritable mécanique de plafonnement des parts — pas de stub, de vrais compartiments journaliers Redis — selon le modèle de menace du §8 : chaque client envoie X-OrcaRouter-Tier: strong à chaque tour sans exception.

Figure 8.Abus d'en-têtes adverses contre le plafond de 20 % de part escaladée. Les 20 premières requêtes ne sont pas contraintes par conception — le plancher de préchauffage empêche qu'« 1 escalade sur 2 » soit interprétée comme 50 % et verrouille la fonctionnalité sur un routeur neuf — après quoi la part converge et se maintient. État final : 296 des 1 439 requêtes servies en fort (20,6 %), avec 1 143 demandes explicites refusées et auditées comme événements denied_cap.

Le dépassement résiduel de 0,6 % est le comportement attendu d'une comparaison strictement supérieure sur un compteur glissant approximatif, et le plafond par session de 1 empêche les sessions individuelles de consommer le budget. Chaque refus est visible pour le client dans l'en-tête de réponse X-Orca-Session-Tier : base ; reason=denied:share_cap et pour l'opérateur dans la table d'audit — une escalade supprimée n'est jamais silencieuse.

7 Ce que nous changerions

Donner son propre seuil à l'extracteur delta. Réutiliser le T2 de la transcription complète laisse une marge de 0,019 (§6.2). Un T2 spécifique au delta compris entre 0,45 et 0,60 est comportementalement identique sur ce corpus, avec deux ordres de grandeur de marge supplémentaire. Le travail sur les seuils de percentile déjà planifié englobe cette approche et constitue la meilleure solution.

Ne laissez pas le terme de densité de code rester décoratif. Il contribue à hauteur de 0,069 de son budget de 0,20 sur le texte réaliste le plus dense que nous ayons pu construire, car son plafond de saturation de 5 correspondances pour 100 caractères implique environ un mot-clé de code tous les vingt caractères. Soit replafonnez-le sur la base d’une distribution de production mesurée, soit réaffectez son poids.

La classe C est le cheval de bataille du trafic d'agents, et c'est la moins développée. La population failure_loop est invisible pour le seuil de difficulté (pic 0.262) et est entièrement détectée par les strikes. Les sessions d'agents échouent en bouclant, pas en devenant lexicalement plus difficiles. Les producteurs restants côté réponse — et le hook de capture de streaming natif Gemini qui manque encore — valent plus que d'autres réglages de difficulté.

Publiez la latence d'escalade. Le coût honnête d'un cliquet de corroboration, ce sont deux tours de travail acharné exécutés sur le modèle peu coûteux, et les opérateurs devraient le voir dans le panneau d'analyse à côté de la précision, plutôt que de le découvrir.

8 Limitations

Le corpus est synthétique. Il a été construit pour se séparer nettement, de sorte que le résultat de zéro faux positif caractérise la spécificité du mécanisme sur des entrées séparables, et non sa précision sur le trafic de production. Le chiffre de précision réel ne peut provenir que du travail d’étiquetage en mode shadow spécifié par la conception — pipeline de déclenchement complet en cours d’exécution, ne routant rien, décisions étiquetées rétroactivement — avec un seuil de mise en production à ≥70 % de précision étiquetée.

Le modèle de coût suppose un nombre fixe de 500 jetons de sortie par tour, ce qui masque un effet réel : les modèles de pointe émettent davantage de jetons de raisonnement, de sorte que la prime réelle des modèles de pointe est sous-estimée. Il modélise également la chaleur du cache au niveau des requêtes comme une valeur uniforme de 1/N sur les emplacements de clés ; un pool pondéré utiliserait l'indice de Herfindahl Σw², et un canal à clé unique ne montrerait aucun avantage de cache pour l'affinité de session au niveau du canal — bien que l'ancrage au niveau du modèle reste important pour les stratégies adaptatives.

Nous n’avons pas exécuté d’inférence en amont, donc aucune affirmation de précision ou de réussite de tâche n’est faite. La couverture des tours difficiles est un indicateur de qualité, et elle suppose que le modèle fort est effectivement meilleur sur ces tours — plausible pour les archétypes construits, non vérifié ici.

Enfin, cela mesure l'implémentation d'une passerelle. Le mode de défaillance de verrouillage au premier tour devrait se généraliser à tout routeur sensible au cache qui épingle des sessions, mais les chiffres spécifiques sont des propriétés de ces seuils, de ces poids et de ces prix.

9 Travaux connexes

Le routage au niveau des requêtes est bien couvert. FrugalGPTsup>[2]/sup> a introduit la cascade de LLM — interroger le modèle bon marché, évaluer la réponse, escalader en cas de faible confiance — rapportant jusqu’à 98 % de réduction des coûts à précision égale. RouteLLMsup>[1]/sup> entraîne des routeurs sur les données de préférence de Chatbot Arena et rapporte 95 % de la qualité de GPT-4 avec 14 % d’appels au modèle fort, avec des routeurs qui se transfèrent d’une paire de modèles à l’autre sans réentraînement. RouterArenasup>[3]/sup> fournit la base d’évaluation manquante : 8 400 requêtes couvrant divers domaines et niveaux de difficulté, évaluées sur la précision, le coût, l’optimalité du routage, la robustesse et la surcharge du routeur.

Ce qu'aucune de ces approches n'aborde, c'est la conversation comme unité de routage. Une cascade fait remonter une requête puis l'oublie ; le tour suivant réexécute le même modèle bon marché sur la même tâche désormais reconnue comme difficile. Un routeur entraîné par préférences note une requête, pas une trajectoire. La lacune que ce rapport aborde est ce qu'un routeur devrait retenir entre les tours, pendant combien de temps, et ce qui devrait être autorisé à lui faire changer d'avis — une question qui ne devient urgente que lorsque la mise en cache des prompts rend l'oubli coûteux.

OrcaRouter fournit un harnais RouterArena intégré (eval/) qui évalue ses cinq stratégies au niveau de la requête — cheapest, quality, balanced, linucb, gated_adaptive — sur le jeu de données ouvert sans modifier le dépôt amont. Le mécanisme au niveau de la session décrit ici est orthogonal aux cinq stratégies et se compose avec elles toutes.

10 Conclusion

La mise en cache des invites a modifié l'économie du routage des LLM d'une manière que la littérature sur le routage n'a pas encore intégrée. Dès lors que la continuité vaut une réduction de 10× sur la majorité de vos jetons d'entrée, un routeur doit se fixer — et au moment où il se fixe, il prend sa décision au tour où il en sait le moins, et vit avec cette décision pendant toute la durée de la conversation. Le routage au niveau de la requête n'a pas ce problème et le paie en échecs de cache ; une réévaluation naïve à chaque tour réintroduit les échecs et ajoute par-dessus un artefact de biais de longueur.

La persistance à plusieurs niveaux résout ce problème en séparant deux choses qui semblent n'en faire qu'une : quel modèle sert cette session (l'épingle, stable au sein d'un niveau) et à quel niveau appartient cette session (un petit élément d'état, plafonné, corroboré et à expiration). Dans notre rejeu, cette séparation récupère 87 % des sessions dont la difficulté est indétectable au tour 1, avec zéro faux positif sur 200 sessions faciles, pour un coût de 45 % de la stratégie toujours-frontière — et maintient un plafond de dépense de 20 % face à des clients qui tentent activement de la contourner.

Les faiblesses réelles du mécanisme tiennent au calibrage, pas à l’architecture : un seuil de difficulté réutilisé depuis une distribution pour laquelle il n’avait pas été réglé, un terme de caractéristique qui ne peut pas atteindre son budget, et deux tours de latence de secours inévitables. Ce sont des points traitables. L’affirmation architecturale — selon laquelle la mémoire d’escalade doit être séparée du code PIN, aucun signal flou ne doit pouvoir, à lui seul, faire avancer le cliquet, et les plafonds doivent contraindre la propre demande explicite du client, car c’est le client qui détient le jeton — est la partie que nous conserverions.

11 Sources

1. LMSYS Org. RouteLLM : un framework open-source pour un routage de LLM économique. 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 : comment utiliser les grands modèles de langage tout en réduisant les coûts et en améliorant les performances. 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 : une plateforme ouverte pour la comparaison exhaustive des routeurs de LLM. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Prompt Caching dans l'API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — mise en cache automatique, préfixe d'au moins 1 024 jetons par incréments de 128 jetons, éviction après 5 à 10 minutes d'inactivité, ≤ 1 heure ; remise sur l'entrée en cache selon le niveau du modèle. Tarifs : a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Mise en cache des prompts. 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> — lectures de cache 0,1× l’entrée de base, écritures 1,25× (TTL de 5 minutes) ou 2× (TTL de 1 heure), rafraîchies à l’utilisation. Tarifs : a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. L'API DeepSeek introduit la mise en cache de contexte sur disque. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automatique, facturé en fonction des hits réels du cache, réduction d'un ordre de grandeur en cas de hit.

7. Google. Mise en cache du contexte de l'API Gemini. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — mise en cache implicite et explicite avec TTL au prix du stockage.

8. Source d'OrcaRouter, ce dépôt : service/session_affinity.go (pins, TTL, clés par niveau) · service/session_escalation.go (le moteur) · service/model_router.go:1374 (selectByStrategy : réduction de niveau avant la lecture du pin) · service/model_router_difficulty.go (pondérations et plafonds) · service/model_router_delta.go (extracteur de delta) · service/escalation_strikes.go (producteurs côté requête) · service/escalation_caps.go (plafonds de partage) · docs/features/frontier-escalation.md (conception, cycles de relecture 1 à 4).

Reproductibilité. Le harnais de mesure est un test Go dans le package du service qui pilote ResolveEscalation / CommitEscalationDecision avec miniredis, ainsi qu'un pipeline d'analyse et de génération de figures en Python. La génération du corpus est initialisée avec une graine (rand.NewSource(20260814)) et l'exécution complète est déterministe : 400 sessions, 3 968 tours, trois expériences (rejeu principal, exécution avec plafond adversarial, balayage de seuil sur 9 points). Les figures utilisent une palette catégorielle validée CVD ; chaque figure est associée à son tableau sous-jacent. Aucune donnée de production n'a été consultée et aucune partie de cette analyse n'a été committée dans le dépôt.