Infrastruttura di Routing OrcaRouter: Routing Consapevole della Sessione ed Escalation di Frontiera

ORCAROUTER · ARCHITETTURA DI ROUTING

Ogni gateway LLM che memorizza nella cache i prompt deve vincolare una conversazione a un unico modello. Ogni gateway che vincola una conversazione prende la sua decisione di instradamento in base al turno meno informativo di quella conversazione. Questo è un report su quel compromesso e sul meccanismo di stickiness a livelli che OrcaRouter offre per uscirne.

Oggetto: OrcaRouter LLM gateway (Go / Gin / Redis) · Componente: session affinity + Frontier Escalation engine · Metodo: replay di 400 sessioni contro il codice decisionale di produzione · Data: 14 agosto 2026

RIASSUNTO — L'instradamento LLM a livello di richiesta — che valuta ogni richiesta in modo indipendente e la instrada al modello adeguato più economico — è il regime a cui si rivolge quasi tutta la letteratura pubblicata sui router. È anche il regime sbagliato per il traffico che ora domina il volume dei gateway: sessioni di agenti multi-turno, in cui il prompt è per il 90 % contesto riportato e la cache del prompt del provider premia la continuità. Cambiare modello a metà conversazione fa perdere uno sconto di 10× sul prefisso condiviso, quindi i gateway ancorano le sessioni. Ma un ancoraggio fatto al turno 1 è un ancoraggio fatto nel turno con meno prove, e persiste per l'intera vita della conversazione.

100 / 100 — sessioni latent-hard il cui punteggio al turno 1 è indistinguibile da uno banale

+16% — deriva del punteggio di difficoltà dovuta alla sola lunghezza della trascrizione, a parità di difficoltà del compito

45% — del costo sempre di frontiera, per il 67 % della sua copertura in virata brusca

0.019 — margine tra il gate rilasciato e il tetto dei punteggi realistici

1 Due regimi di routing

Un gateway LLM che funge da interfaccia per molti provider deve rispondere a una domanda per richiesta: quale modello serve questa richiesta? Ci sono due modi strutturalmente diversi per rispondere, e la letteratura e la realtà produttiva si sono allontanate su quale dei due sia quello che conta.

Routing a livello di richiesta tratta ogni richiesta come indipendente. Uno scorer stima la difficoltà della query o la qualità prevista della risposta, e la richiesta viene inviata al modello più economico che ci si aspetta possa gestirla. Questo è il regime di praticamente tutti i lavori pubblicati sui router: RouteLLM addestra router basati su dati di preferenza che raggiungono il 95 % della qualità di GPT-4 con il 14 % di chiamate a modelli fortisup>[1]/sup>; FrugalGPT utilizza una cascata da economico a costoso con un controllo di accettazione/rifiuto e riporta una riduzione dei costi fino al 98 %sup>[2]/sup>; RouterArena costruisce un benchmark di 8.400 query per confrontare i router esattamente su questo assesup>[3]/sup>. L’unità di analisi è la query.

Routing sensibile alla sessione

Il motivo per cui esiste il routing sensibile alla sessione non è l'eleganza. È aritmetica.

2 L'economia della cache che rende obbligatoria la persistenza

In una sessione di agente multi-turno, il prompt del turno n è il prompt del turno n−1 più un delta. Entro il turno 10, il prefisso portato avanti è la stragrande maggioranza dei token di input. Ogni grande provider ora applica prezzi diversi a quel prefisso a seconda che si tratti di un cache hit:

Tabella 1. Semantica della prompt-cache per provider. La cache è basata su un prefisso esatto e sulla serving key — un cambio di modello o una rotazione della chiave comporta una lettura a freddo a prezzo pieno.

OrcaRouter codifica esattamente queste durate come TTL dei pin: una mappa per tipo di canale delle finestre di cache del provider — 5 minuti per OpenAI, Anthropic e Gemini, 60 minuti per DeepSeek — con un valore predefinito di 5 minuti per i provider non mappati. Il pin canale+chiave scade con quella finestra, perché un indice di chiave obsoleto non ha valore di cache e distorce solo il bilanciamento del carico. Il modello pin, su una distribuzione basata su Redis e per un ID di sessione idoneo al pin lungo, persiste per 30 giorni — non per il valore di cache, che ormai non esiste più, ma per la continuità del formato delle richieste. Un cambio di modello a metà conversazione impone una conversione del formato delle richieste che può essere incompatibile con i dati: i blocchi di pensiero e gli ID delle chiamate agli strumenti non sopravvivono necessariamente alla traduzione tra gli schemi dei provider.

Il dettaglio sottovalutato

Le cache dei prompt sono indicizzate per API key, non per modello. Un gateway che fissa il modello ma bilancia il carico su tre chiavi sullo stesso canale andrà comunque in cold read due volte su tre. È per questo che il pin del canale di OrcaRouter memorizza {ChannelID, KeyIndex} invece di un ID canale, e per questo il pin viene rimosso quando l'indice di chiave registrato non corrisponde più a una chiave abilitata — una chiave potenziata ma ruotata favorirebbe una cache fredda, bypassando il bilanciamento, che è il peggio di entrambi i mondi.

I pin sono morbidi in ogni caso: un ID di sessione non risolvibile è un no-op, un canale pinnato disabilitato o non sano degrada alla normale selezione bilanciata, e un pin verso un canale con peso zero in un pool misto viene eliminato, così un amministratore che drena un canale non viene ostacolato dalla persistenza. Non fanno mai fallire una richiesta.

3 La trappola: la persistenza disabilita il router

Ecco la modalità di errore. In OrcaRouter, il percorso di codice pre-escalation, per un router sensibile alla sessione su qualsiasi strategia non-DSL, il pin sessione→modello restituito

Ciò sarebbe tollerabile se il turno 1 fosse rappresentativo. Sistematicamente non lo è, per due ragioni che si sommano.

3.1 Il turno 1 è il turno meno informativo

Lo scalare di difficoltà (service/model_router_difficulty.go) è una combinazione lineare pesata di sei caratteristiche lessicali:

LogPromptTokens × 0,20 con tetto log(8001) ≈ 8,99

ReasoningCueCount × 0.15 tetto 5

SystemPromptLogLen × 0.10 cap log(2001) ≈ 7.60

Densità di parole chiave del codice × 0,20 tetto 5,0 (corrispondenze per 100 caratteri)

HasTools × 0.15 già 0/1

MathMarkerCount × 0.20 tetto 5

Un breve opener senza cronologia ottiene un punteggio basso quasi per costruzione: il termine token con peso 0,20 è vicino al suo minimo, e i termini di ragionamento/matematica si attivano su un vocabolario che l'utente non ha ancora avuto motivo di usare. Le sessioni quindi si affidano a un modello di pool debole nel momento di minima informazione — e con un pin del modello di 30 giorni basato su Redis, questo impegno è lungo.

Figura 1.Difficoltà media dell’ultimo turno per turno di conversazione, su 100 sessioni a difficoltà latente e 200 genuinamente facili, valutate dallo scorer di produzione. Al turno 1 — il turno in cui viene scritto lo sticky pin — le due popolazioni sono indistinguibili (0,210 vs 0,208). La popolazione difficile supera il gate al turno 5. Con una politica basata solo sul pin, tutte le 100 sessioni a difficoltà latente vengono assegnate al pool economico prima che esista qualsiasi evidenza di ciò.

3.2 La lunghezza si maschera da difficoltà

Il secondo problema è più sottile e mina la soluzione ovvia. Se semplicemente riesegui il gate di difficoltà a ogni turno, lo stai rieseguendo su un punteggio calcolato sull'intero trascritto concatenato. Questo punteggio ha una deriva verso l'alto incorporata: il termine LogPromptTokens con peso 0.20 sale monotonicamente con la lunghezza della conversazione, e per qualsiasi sessione di un agente i termini 0.15 HasTools e 0.10 SystemPromptLogLen sono di fatto soglie costanti. Una sessione lunga e noiosa appare progressivamente più difficile.

Figura 2. L’artefatto del bias di lunghezza, misurato su 60 sessioni costituite interamente da modifiche banali (“rinomina questa variabile”, “aggiungi un controllo nil”). Il punteggio dell’intera trascrizione subisce una deriva del +16% nell’arco di 25 turni a difficoltà del compito costante; il punteggio dell’ultimo turno (delta) è piatto. Una rivalutazione ingenua del punteggio dell’intera trascrizione a ogni turno porterebbe all’escalation delle sessioni per il crimine di essere lunghe.

La correzione che OrcaRouter offre è un distinto delta-estrattore (service/model_router_delta.go) che valuta solo l'ultimo turno — il nuovo testo utente più eventuali risultati degli strumenti allegati dopo l'ultimo messaggio dell'assistente — riutilizzando gli stessi pesi e limiti ma azzerando deliberatamente SystemPromptLogLen, che non fa parte del delta. La linea blu piatta della Figura 2 è quell'estrattore.

4 Design: adesività a più livelli

La via d'uscita ingenua dal lock-in del turno 1 è reinstradare ogni turno — che è solo routing a livello di richiesta, e rinuncia alla cache. La correzione ingenua nella direzione opposta è fare del pin la memoria del fatto che "questa sessione è diventata dura" — che non può esprimere de-escalation e non può essere limitato. Il design di OrcaRouter rifiuta entrambe.

Il nuovo inquadramento: una sessione è ancorata a un modello all'interno di un livello, e un piccolo Redis per lo stato del livello è l'unica memoria di escalation. L'ancoraggio al modello non è mai la memoria.

Pool di livelli. Il livello forte è il pool di escalation risolto (escalation_pool, che per impostazione predefinita è il strong_pool del router). Il livello base è AllowedModels \ pool del livello forte; un modello presente in entrambi appartiene al livello forte. All'interno del livello base, le fasce di difficoltà debole/media/forte di gated_adaptive continuano a funzionare esattamente come prima.

Pin con ambito di livello. La chiave model-pin del livello strong riceve un suffisso :t:strong; il livello base mantiene invariata la chiave legacy. L'escalation quindi preserva il pin base, quindi una sessione de-escalata — o una ripresa dopo la scadenza dello stato del livello — torna al modello esatto su cui era iniziata, non a una scelta arbitraria. I pin strong vengono scritti solo con il TTL breve della finestra del provider: un pin strong di 30 giorni sopravviverebbe allo stato del livello di 4 ore che lo ha giustificato.

Il gate viene eseguito per primo. In selectByStrategy (service/model_router.go:1374) il tier viene risolto in anticipo, il set di candidati viene ristretto al pool del tier, e solo poiviene consultato il pin sticky — all’interno di quel tier. Questa è la correzione strutturale per il §3: il calcolo della difficoltà e i trigger di escalation vengono eseguiti a ogni turno, prima che il pin possa aggirarli (short-circuit).

4.1 Tre classi di trigger, classificate per fiducia

Tabella 2. Trigger di escalation. Nessun segnale fuzzy viene mai incrementato da solo; solo una richiesta esplicita del cliente fa scattare l’impegno a n=1, e anche in questo caso rispetta i limiti massimi.

Tre invarianti di igiene sono portanti. Gli strike vengono deduplicati per ID di richiesta tramite un ring buffer, quindi i retry del client interlacciati non possono essere conteggiati due volte. Il guasto dell’infrastruttura non è mai un guasto di capacità — i 429, i 5xx e i fallback di canale non contano mai come strike; contano solo i segnali di qualità post-successo. E un “turno” è definito come una richiesta completata e fatturata con successo che ha eseguito la valutazione degli strike, quindi le richieste fallite non fanno avanzare né il decadimento dello strike né il contatore dei turni puliti.

4.2 Resolve è puro; il commit è differito

La proprietà strutturale più rilevante del motore è che ResolveEscalation non scrive nulla. Restituisce una decisione e un elenco di intenti pendenti. Il distributore applica tali intenti nel suo blocco post-successo, su una lettura fresca all'interno di una transazione WATCH di Redis. Questo è importante perché il resolver viene eseguito su percorsi che non devono mai mutare lo stato: risoluzioni speculative della catena di fallback, endpoint diagnostici di sola lettura e richieste che successivamente restituiscono 403 o falliscono a monte. Riapplicare gli intenti su uno stato fresco significa anche che uno scrittore concorrente obsoleto non può sovrascrivere un'escalation committata, e due escalation identiche e concorrenti si fondono in modo idempotente.

4.3 Maiuscole, e perché legano tutto

Un'escalation di falsi positivi costa (strong − base) prezzo × token rimanenti dell'episodio caldo, e lo paga in silenzio — non fallisce nulla. Il raggio d'esplosione è delimitato da cap che si applicano a ogniclasse:

escalation_max_per_session (predefinito: 1). La de-escalation e i reset del client non lo rimborsano, il che chiude il percorso di sfruttamento del ciclo di reset.

Un limite per router della quota di escalation (predefinito 20 %) su una finestra mobile di 24–48 ore di bucket giornalieri Redis, più un limite trasversale a livello di workspace. Al raggiungimento del limite, tutto l'instradamento dell'escalation viene soppresso — incluse le richieste esplicite e i boost una tantum.

De-escalation solo ai confini di cache fredda, quindi un falso positivo è limitato a un episodio caldo.

Il motivo per cui la Classe A rispetta i limiti è una conclusione del modello di minaccia, non una preferenza di policy: su un API gateway, chi detiene il token dell'area di lavoro controlla le intestazioni. Un percorso esente da limiti basato su “lo ha chiesto il client” è un canale di spesa non misurato. Il §7 misura cosa succede quando ogni client ne abusa.

4.4 La de-escalation è asimmetrica per progettazione

Escalare su prove corroborate; de-escalare solo quando è gratuito. Una sessione forte torna alla base solo quando tutte le seguenti condizioni sono soddisfatte: la sessione è cache-cold (inattiva oltre la finestra del provider registrata al momento dell'escalation), ha accumulato ≥3 turni valutati senza strike, e l'ultimo delta di difficoltà è al di sotto di T1. All'interno della finestra calda, uno switch paga una rilettura a freddo a prezzo pieno — il flapping è l'unico modo garantito per rendere l'escalation a costo negativo.

5 Metodo

Abbiamo misurato il meccanismo riproducendo un corpus di sessioni sintetiche attraverso il vero codice decisionale di produzione. L'harness è un test Go nel package del servizio che chiama ResolveEscalation e CommitEscalationDecision a ogni turno contro un tier store basato su miniredis, con i veri scorer di difficoltà, i veri produttori di strike lato richiesta e la vera meccanica del tetto massimo di condivisione. Nulla del percorso decisionale è reimplementato o mockato, tranne il sink degli eventi di audit.

Cosa è reale e cosa non lo è

Reale: ogni decisione di routing, punteggio di difficoltà, rilevamento degli strike, regola della serie, valutazione del cap e transizione dello stato Redis — queste sono le funzioni effettivamente distribuite. Sintetico: il traffico. Il corpus è generato, non campionato dai log di produzione. Il suo mix di archetipi (50 % hard) è un mix di stress scelto per esercitare il meccanismo, non una stima del traffico reale; il §6.4 riporta la sensibilità a questa scelta, ed essa è ampia. I numeri di precisione puliti qui sotto riflettono un corpus le cui classi sono separabili per costruzione, e vanno letti come “il meccanismo scatta dove è stato progettato per farlo”, non come una stima di precisione in produzione.

5.1 Corpus

400 sessioni, 3.968 turni, generati con seed fisso e deterministicamente. Ogni turno è un corpo di richiesta chat-completions completo che trasporta la cronologia cumulativa, un array con le definizioni di due strumenti e un prompt di sistema realistico — la forma che un agente di codifica invia realmente. Cinque archetipi, ciascuno con un'etichetta ground-truth:

Tabella 3. Composizione del corpus. “Needs strong” è la verità di base utilizzata per i punteggi di precisione e copertura.

I turni difficili contengono un dump di goroutine incollato o un estratto di codice sorgente di 3–8 KB oltre alla prosa, perché è ciò che contiene un vero turno di debugging difficile. Questo dettaglio si è rivelato enormemente importante — vedi §6.2.

5.2 Modello di costo

I costi sono calcolati a partire dai prezzi di listino pubblicati con semantica di cache per provider; il modello è dichiarato per intero così da poter essere contestato.

Tabella 4. Parametri del modello di costo. I prezzi sono in $ per 1 milione di token, listino di agosto 2026.

Un turno caldo costa 0.1·p_in·prefix + write·p_in·delta; un turno freddo costa write·p_in·prompt. Il turno 1 è sempre una scrittura completa della cache. Il turno di cambio di livello nella politica di escalation viene addebitato esplicitamente come freddo, quindi il meccanismo paga per la propria invalidazione della cache.

La qualità è riportata come copertura dei turni difficili — la frazione di turni difficili secondo il ground truth effettivamente serviti dal modello forte — piuttosto che come misura di accuratezza. Non abbiamo eseguito l'inferenza a monte, quindi ci asteniamo dall'inventare numeri di accuratezza.

6 Risultati

6.1 Il meccanismo si attiva dove è stato progettato per farlo.

Tabella 5. Esiti di escalation per archetipo, modalità auto, canary 100 %, T2 = 0,70 (predefinito distribuito).

Zero falsi positivi sulle 200 sessioni facili, incluse le 60 lunghe che uno scorer basato sulla trascrizione completa avrebbe classificato nella banda difficile. Le classi di trigger si specializzano in modo pulito e senza sovrapposizioni: difficulty intercetta il lavoro ad alta intensità di ragionamento, strikes intercetta i loop di fallimento. Nota che il punteggio massimo di difficoltà di failure_loop è 0.262 — il gate di difficoltà non vede mai quelle sessioni. Un agente bloccato in un loop di errori di compilazione non sta producendo prosa densa di indizi di ragionamento; sta producendo lo stesso prompt breve con uno stack trace diverso. Senza gli strike di Classe C, ognuna di quelle 60 sessioni continuerebbe a macinare sul modello economico all'infinito.

Figura 3. Quando le sessioni subiscono un'escalation, suddividile in base al fattore scatenante. Le escalation guidate dagli strike sono nettamente concentrate (turno 4, il primo turno in cui due strike possono essersi accumulati all'interno della finestra di decadimento); le escalation guidate dalla difficoltà si distribuiscono sui turni 2–11 seguendo la distribuzione degli esordi del corpus. La regola della serie di due turni consecutivi implica che la prima escalation di difficoltà possibile sia il turno 2.

Rilievo 6.2: il cancello spedito si trova sul ciglio di un precipizio.

Il nostro primo corpus ha prodotto zero escalation guidate dalla difficoltà. I turni difficili — carichi di race condition, invarianti, analisi della complessità e vocabolario di dimostrazione — hanno raggiunto il picco di 0.658 contro una soglia di 0.70. L'aggiunta delle stack trace incollate che i turni di debug reali effettivamente contengono li ha portati a 0.719. La soglia viene superata con un margine di 0.019.

Figura 4. Dove va effettivamente il budget di difficoltà, calcolato su 855 turni difficili e 3.113 turni facili. Un turno difficile realistico raggiunge 0,719 di un massimo teorico di delta di 0,90. Il termine CodeKeywordDensity contribuisce con 0,069 del suo budget di 0,20 — la densità misurata è di 1,72 corrispondenze ogni 100 caratteri, contro un tetto di saturazione di 5,0 — e il valore 0,10 di SystemPromptLogLen è strutturalmente zero nell’estrattore di delta. All’incirca un terzo dell’intervallo nominale del punteggio è irraggiungibile da testo realistico.

La scansione di soglia conferma che si tratta di un dirupo, non di una pendenza. Attraverso T2 da 0.35 a 0.65 l'esito è identico — 200 sessioni su 400 vanno in escalation, con zero errori. Con la soglia 0.70 in produzione, il classificatore inizia a perdere sessioni; a 0.75 l'escalation guidata dalla difficoltà crolla da 122 sessioni a 23.

Figura 5. Sensibilità di soglia. L'intero intervallo 0.35–0.65 è comportamentalmente identico perché nessun testo delta realistico vi rientra — la distribuzione dei punteggi è bimodale, con turni facili raggruppati vicino a 0.23 e turni difficili vicino a 0.72, e niente in mezzo. Il valore predefinito fornito si colloca all'estremità superiore della moda superiore.

IMPLICAZIONE INGEGNERISTICA

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 Costo e copertura

Figura 6.Cinque politiche sulle stesse 400 sessioni. A sinistra: costo per 1.000 sessioni (scala logaritmica). A destra: frazione di turni veramente difficili serviti dal modello forte.

Tabella 6. Confronto delle policy. Costo per 1.000 sessioni secondo il modello della Tabella 4.

Due risultati meritano di essere separati. Innanzitutto, la sola affinità di sessione fa risparmiare il 24 % a parità di scelta del modello (16.64 → 12.63) e il 35 % sulla coppia di frontiera (290.93 → 188.30). Si tratta di pura economia della cache: stessi modelli, stessa identica configurazione, cambia solo la persistenza della chiave. Il risparmio è maggiore sulla coppia di frontiera perché il premio di scrittura 1.25× di Anthropic rende i turni a freddo sproporzionatamente costosi.

In secondo luogo, l'escalation scatta dove dovrebbe un meccanismo di salvataggio: il 45 % del costo del modello sempre di frontiera per il 67 % della sua copertura dei turni difficili, servendo il modello forte solo nel 21,4 % dei turni.

Il terzo di copertura mancante non è un difetto; è il prezzo del cricchetto. Le regole di corroborazione che danno zero falsi positivi significano anche che il meccanismo non può agire al primo manifestarsi di un problema:

Tabella 7. Latenza di escalation — turni difficili serviti dal modello economico prima che il cricchetto scatti.

Due turni è esattamente ciò che specifica la regola della serie di due turni consecutivi, e un turno è esattamente ciò che specifica la regola dei due colpi per il ratchet. La latenza è il design, ed è la stessa proprietà che ha prodotto zero falsi positivi. Chiunque desideri un recupero più rapido ha l'header di Classe A, che agisce a n=1 — è proprio per questo che la porta di fuga manuale è stata rilasciata per prima.

6.4 Il rapporto del titolo dipende interamente dal tuo traffico

Il corpus è composto per il 50% da sessioni hard per costruzione. Il traffico reale dei router non lo è, e il confronto dei costi è estremamente sensibile a questo. Riponderando i costi misurati per archetipo su una gamma di prevalenze di sessioni hard:

Figura 7.Costo per 1.000 sessioni in funzione di quanta parte del tuo traffico ha realmente bisogno del modello forte. Il comportamento intra-classe è mantenuto ai valori misurati; cambia solo il mix.

Tabella 8.Sensibilità della prevalenza, $ per 1.000 sessioni.

Al tasso di escalation target del documento di progettazione, pari a ≤5 % delle sessioni, i costi di escalation ammontano a 1,6× il costo del pool economico e al 12 % del costo della frontiera. Con il mix di stress al 50 %, il costo è 6,7× quello del pool economico. Entrambe le affermazioni sono vere; rispondono a domande diverse. Quella operativamente rilevante è la prima, ed è per questo che il limite massimo di quota è impostato al 20 % invece che su “off”: è il limite, non la precisione del trigger, a vincolare realmente la spesa.

6.5 I limiti restano validi sotto abuso adversarial.

Abbiamo rieseguito il corpus con il vero meccanismo share-cap — niente stub, veri day-bucket Redis — sotto il modello di minaccia §8: ogni client invia X-OrcaRouter-Tier: strong a ogni singolo turno.

Figura 8.Abuso avversario dell'header contro il limite del 20 % di quota incrementata. Le prime 20 richieste non sono vincolate per progettazione — la soglia di riscaldamento impedisce che "1 escalation su 2" venga letta come 50 % e blocchi la funzionalità su un router appena avviato — dopodiché la quota converge e si mantiene. Stato finale: 296 richieste su 1.439 servite come strong (20,6 %), con 1.143 richieste esplicite negate e registrate come eventi denied_cap.

Il residuo superamento dello 0,6 % è il comportamento previsto di un confronto strettamente maggiore su un contatore mobile approssimativo, e il limite massimo per sessione di 1 impedisce alle singole sessioni di consumare il budget. Ogni rifiuto è visibile al client nell'header di risposta X-Orca-Session-Tier: base; reason=denied:share_cap e all'operatore nella tabella di audit — un'escalation soppressa non è mai silenziosa.

7 Cosa cambieremmo

Assegna all'estrattore delta una propria soglia. Riutilizzare il T2 dell'intera trascrizione lascia un margine di 0,019 (§6.2). Un T2 specifico per il delta compreso tra 0,45 e 0,60 è comportamentalmente identico su questo corpus, con un margine di sicurezza maggiore di due ordini di grandezza. Il lavoro sulla soglia percentile già pianificato assorbe questa esigenza ed è la soluzione migliore.

Non lasciare che il termine densità di codice rimanga decorativo. Contribuisce per 0,069 del suo budget di 0,20 sul testo realistico più denso che siamo riusciti a costruire, perché il suo tetto di saturazione di 5 corrispondenze per 100 caratteri implica circa una parola chiave di codice ogni venti caratteri. O ricalibra il tetto su una distribuzione di produzione misurata, oppure rialloca il suo peso.

La Classe C è il cavallo di battaglia per il traffico degli agenti, ed è la meno sviluppata. La popolazione failure_loop è invisibile al gate di difficoltà (picco 0.262) ed è catturata interamente dagli strike. Le sessioni degli agenti falliscono andando in loop, non diventando lessicalmente più difficili. I restanti produttori lato risposta — e l'hook di cattura dello streaming nativo di Gemini, che manca ancora — valgono più di un'ulteriore messa a punto della difficoltà.

Pubblica la latenza di escalation. Due turni di duro lavoro serviti sul modello economico sono il costo onesto di un cricchetto corroborante, e gli operatori dovrebbero vederlo nel pannello di analisi accanto alla precisione, non scoprirlo.

8 Limitazioni

Il corpus è sintetico. È stato costruito per separarsi in modo pulito, quindi il risultato di zero falsi positivi caratterizza la specificità del meccanismo su input separabili, non la sua precisione sul traffico di produzione. Il valore di precisione reale può venire solo dal lavoro di etichettatura in modalità shadow specificato dal design — pipeline di trigger completamente attiva, senza instradare nulla, decisioni etichettate retroattivamente — con un gate di go-live a ≥70 % di precisione di etichettatura.

Il modello di costo presuppone un numero fisso di 500 token di output per turno, il che sopprime un effetto reale: i modelli di frontiera emettono più token di ragionamento, quindi il vero premio di frontiera è sottostimato. Inoltre modella il calore della cache a livello di richiesta come un 1/N uniforme sugli slot chiave; un pool ponderato userebbe l'indice di Herfindahl Σw², e un canale a chiave singola non mostrerebbe alcun vantaggio di cache per l'affinità di sessione a livello di canale — anche se il pinning a livello di modello conta ancora per le strategie adattive.

Non abbiamo eseguito inferenza a monte, quindi non viene fatta alcuna affermazione di accuratezza o successo del compito. La copertura dei turni difficili è un proxy della qualità e presuppone che il modello forte sia effettivamente migliore in quei turni — plausibile per gli archetipi costruiti, ma non verificato qui.

Infine, {{1}}questo misura l'implementazione di un singolo gateway{{/1}}. {{2}}La modalità di errore del lock-in al turno 1{{/2}} dovrebbe applicarsi a qualsiasi router cache-aware che fissa le sessioni, ma {{3}}i numeri specifici sono proprietà di queste soglie, questi pesi e questi prezzi{{/3}}.

9 Lavori correlati

Il routing a livello di richiesta è ben coperto. FrugalGPTsup>[2]/sup> ha introdotto la cascata LLM — interrogare il modello economico, valutare la risposta, escalare in caso di bassa confidenza — riportando una riduzione dei costi fino al 98% a parità di accuratezza. RouteLLMsup>[1]/sup> addestra i router sui dati di preferenza di Chatbot Arena e riporta il 95% della qualità di GPT-4 con il 14% di chiamate a modelli forti, con router trasferibili tra coppie di modelli senza riaddestramento. RouterArenasup>[3]/sup> fornisce la base di valutazione mancante: 8.400 query in diversi domini e livelli di difficoltà, valutate in base a accuratezza, costo, ottimalità del routing, robustezza e overhead del router.

Ciò che nessuno di questi affronta è la conversazione come unità di routing. Una cascata inoltra una richiesta e dimentica; il turno successivo riesegue lo stesso modello economico sullo stesso compito ormai noto come difficile. Un router addestrato sulle preferenze valuta una query, non una traiettoria. Il vuoto che questo rapporto affronta è cosa un router dovrebbe ricordare tra i turni, per quanto tempo, e cosa dovrebbe essere autorizzato a fargli cambiare idea — una questione che diventa urgente solo quando il caching dei prompt rende costoso dimenticare.

OrcaRouter include un harness RouterArena integrato nell'albero (eval/) che valuta le sue cinque strategie a livello di richiesta — cheapest, quality, balanced, linucb, gated_adaptive — sul dataset aperto senza modificare il repository upstream. Il meccanismo a livello di sessione descritto qui è ortogonale a tutte e cinque e si compone con esse.

10 Conclusione

Il prompt caching ha cambiato l'economia del routing degli LLM in un modo che la letteratura sul routing non ha ancora recepito. Quando la continuità vale uno sconto del 10× sulla maggior parte dei tuoi token di input, un router deve fare pin — e nel momento in cui fa pin, prende la sua decisione nel turno in cui sa meno, e convive con quella decisione per tutta la durata della conversazione. Il routing a livello di richiesta non ha questo problema e lo paga in cache miss; una ingenua rivalutazione a ogni turno reintroduce i miss e aggiunge per di più un artefatto di bias di lunghezza.

La stickiness a livelli lo risolve separando due cose che sembrano una sola: quale modello serve questa sessione (il pin, stabile all'interno di un livello) e a quale livello appartiene questa sessione (un piccolo pezzo di stato, limitato, corroborato e con scadenza). Nel nostro replay questa separazione recupera l'87 % delle sessioni la cui difficoltà non è rilevabile al turno 1, con zero falsi positivi su 200 sessioni facili, al 45 % del costo dell'always-frontier — e mantiene un tetto di spesa del 20 % contro clienti che tentano attivamente di eluderlo.

Le debolezze oneste del meccanismo sono la calibrazione, non l'architettura: un gate di difficoltà riutilizzato da una distribuzione per cui non era stato tarato, un termine di feature che non può raggiungere il suo budget, e due turni di inevitabile latenza di soccorso. Queste sono trattabili. L'affermazione architettonica — che la memoria di escalation debba essere separata dal pin, che nessun segnale fuzzy possa procedere a scatti da solo, e che i limiti massimi debbano vincolare la richiesta esplicita del cliente stesso perché il cliente detiene il token — è la parte che conserveremmo.

11 Fonti

1. LMSYS Org. RouteLLM: un framework open-source per un routing di LLM economicamente conveniente. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · codice: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia & Zou. FrugalGPT: come usare i modelli linguistici di grandi dimensioni riducendo i costi e migliorando le prestazioni. 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: una piattaforma aperta per il confronto completo dei router LLM. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Prompt Caching nell'API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — caching automatico, prefisso di ≥1.024 token in incrementi di 128 token, eliminazione per inattività di 5–10 minuti, ≤1 ora; sconto sull'input in cache in base al livello del modello. Prezzi: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Caching del prompt. 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> — letture della cache 0.1× l'input base, scritture 1.25× (TTL di 5 minuti) o 2× (TTL di 1 ora), aggiornata all'uso. Prezzi: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. L'API DeepSeek introduce il caching del contesto su disco. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automatico, addebitato in base ai cache hit effettivi, riduzione di un ordine di grandezza sugli hit.

7. Google. Caching del contesto dell'API Gemini. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — caching implicito ed esplicito con TTL al prezzo dello storage.

8. Sorgente di OrcaRouter, questo repository: service/session_affinity.go (pin, TTL, chiavi con ambito di tier) · service/session_escalation.go (il motore) · service/model_router.go:1374 (selectByStrategy: restringimento del tier prima della lettura del pin) · service/model_router_difficulty.go (pesi e massimali) · service/model_router_delta.go (estrattore di delta) · service/escalation_strikes.go (produttori lato richiesta) · service/escalation_caps.go (tetti di quota) · docs/features/frontier-escalation.md (progettazione, round di revisione 1–4).

Riproducibilità. L'harness di misurazione è un test Go nel pacchetto di servizio che pilota ResolveEscalation / CommitEscalationDecision contro miniredis, più una pipeline Python di analisi e figure. La generazione del corpus è seedata (rand.NewSource(20260814)) e l'esecuzione completa è deterministica: 400 sessioni, 3.968 turni, tre esperimenti (replay principale, run adversarial con cap, sweep di soglia a 9 punti). Le figure usano una palette categorica validata per CVD; ogni figura è abbinata alla sua tabella sottostante. Nessun dato di produzione è stato accessato, e nessuna parte di questa analisi è stata committata nel repository.