Smart Routing in Unity AI Gateway: eguaglia la qualità dei modelli di frontiera con un costo per task inferiore di oltre il 30%

La frontiera del rapporto prezzo/prestazioni per le attività di programmazione presenta un'enorme varietà di modelli e harness: solo nel 2026 abbiamo assistito al rilascio di 33 nuovi modelli. Nel nostro post precedente sul benchmarking rispetto alla codebase di Databricks, abbiamo scoperto che i modelli si raggruppano in livelli di capacità e che gran parte del lavoro quotidiano (ad esempio, l'attivazione di un flag, la modifica di un singolo file, la correzione di un bug ben definito) non richiede i modelli più costosi.

Quindi, come si riducono i costi di programmazione con l'IA senza sacrificare la produttività degli sviluppatori? Una delle opportunità più grandi consiste nell'abbinare ogni attività al modello giusto, invece di impostare come predefinita per ogni attività l'opzione più potente (e più costosa). Il semplice utilizzo di modelli a costo inferiore può farti risparmiare oltre il 50%, ma per gli utenti è un'impresa incredibilmente scoraggiante. Con la proliferazione di ottimi modelli e harness capaci, gli utenti di agenti di programmazione si trovano costantemente di fronte a un sovraccarico di scelta. Invece di perdere tempo a cercare di selezionare il modello migliore per ogni attività, molti impostano quello più potente al massimo livello di sforzo e vanno avanti. Invece di chiedere agli utenti di scegliere o di frenare la produttività con limiti rigidi, sapevamo di dover innovare.

Ecco perché stiamo lanciando il prossimo importante controllo dei costi in Unity AI Gateway: Smart Routing, ora disponibile in Beta. Unity AI Gateway offre un punto centrale per accedere all'IA, gestire la spesa e applicare controlli in tutta l'azienda, e Smart Routing aggiunge un'ottimizzazione intelligente abbinando automaticamente le attività al modello giusto in base alla complessità. Smart Routing funziona direttamente in Claude Code and Codex, consentendoti di ottimizzare gli strumenti che gli sviluppatori già utilizzano.

E stiamo andando oltre il routing dei modelli. Con Omnigent, il nostro meta-harness per gli agenti di programmazione, i team possono sfruttare tutta la potenza di Smart Routing ottimizzando sia i modelli che gli harness di programmazione, offrendo agli sviluppatori la combinazione giusta per l'attività senza che debbano sceglierla da soli.

I risultati parlano da soli: sui carichi di lavoro di programmazione interni, Smart Routing ha superato qualsiasi singolo modello a solo il 65% del costo per attività di un modello leader come Opus 5. Nei benchmark pubblici, Smart Routing ha eguagliato le prestazioni di Opus 5 a meno della metà del costo.

Ecco cosa abbiamo imparato:

1. La maggior parte del vantaggio deriva dall'uso di modelli più economici per le attività più semplici. Internamente vediamo un'ampia varietà di attività e la maggior parte di esse non richiede un modello premium. Abbiamo configurato il router per selezionare modelli più economici per le attività più semplici, ma per "escalare" il lavoro complesso che richiede le prestazioni di un modello di frontiera.
2. Abbiamo ottenuto ottimi risultati utilizzando solo le informazioni disponibili all'inizio dell'attività (descrizione e metadati). Non abbiamo fornito la risposta, i test o elementi relativi al repository, e Smart Routing è stato comunque in grado di scegliere in modo efficace.
3. C'è ancora un notevole margine di miglioramento nella valutazione efficace della complessità del lavoro e nell'escalation quando necessario. Un router con una lungimiranza perfetta supererebbe ogni singolo modello a una frazione di quanto spende il nostro e, nelle sessioni reali, può anche essere utile rivalutare a metà percorso se l'attività è diventata più complicata. Colmare questo divario è un problema sia di ricerca che di progettazione dell'harness. Dobbiamo imparare dal feedback reale degli utenti per migliorare.

Vediamo come lo abbiamo realizzato.

Come funziona il routing intelligente dei modelli?

Il routing intelligente dei modelli seleziona il modello più adatto a un'attività in base a fattori quali complessità, capacità e costo. Per gli agenti di programmazione, una decisione importante riguarda il momento in cui deve avvenire tale routing.

In genere esistono due approcci al routing:

1. Routing per richiesta: In una determinata sessione, alcuni team hanno esplorato il routing di ogni richiesta basandosi esclusivamente sulla complessità del prompt per quel messaggio. La sfida è che, su scala, i costi sono dominati dal cache hit rate. Avere un tasso elevato di riscontri nella cache richiede il routing di passaggi consecutivi allo stesso modello (e, attualmente, allo stesso livello di sforzo per i modelli più diffusi).
2. Routing sensibile all'attività (task-aware): All'inizio della sessione, si comincia valutando la complessità dell'attività per poi suggerire un modello e un harness da mantenere per tutta la durata della sessione. Ciò preserva il cache hit rate e offre un'opportunità di ottimizzazione futura, come l'aggiornamento o il downgrade in base alle esigenze quando la cache diventa obsoleta (ad esempio, quando si verifica un evento di compattazione).

Come funziona il nostro Smart Router

Abbiamo optato per il routing task-aware per preservare l'efficienza della cache e abbinare al contempo ogni attività di programmazione al modello e all'harness appropriati. Il problema più interessante consiste nel valutare la difficoltà di un'attività prima di avviarla. Volevamo iniziare in modo semplice, quindi il nostro router attualmente utilizza un'unica policy e la applica a ogni attività nello stesso modo.

Per prima cosa, classichiamo l'attività. Per fare questo, utilizziamo un modello più economico e a bassa latenza che legge la descrizione dell'attività e la etichetta con una manciata di campi semantici: quale parte del sistema cambia, quali prove di codice contiene il prompt (uno snippet, un traceback o nulla di esplicito), come sembra fallire, quanto appare localizzata la correzione e a quale tipo di progetto appartiene. Da questi elementi, il router deriva una famiglia di tipi di attività e una famiglia di linguaggi. L'uso di un modello di frontiera graverebbe su ogni richiesta (anche su quelle semplici su cui vogliamo risparmiare), quindi l'estrattore è intenzionalmente piccolo e veloce.

Quindi, triangoliamo per capire quale classe di modello sia la migliore. Il router utilizza come impostazione predefinita un modello di medie dimensioni e usa le etichette per muoversi in entrambe le direzioni, passando a un modello più costoso quando l'attività richiede capacità e conoscenze di livello frontiera o delegando a uno più economico quando non è necessario. Ciò significa che la singola policy può sfruttare un'intera suite di modelli.

I primi risultati sono promettenti. Rispetto al nostro benchmark interno, a cui nessun laboratorio ha avuto accesso, abbiamo registrato un risparmio del 35%. Rispetto ai benchmark di programmazione pubblici che dimostrano la generalizzabilità dei nostri risultati, abbiamo ottenuto un risparmio sui costi del 56%. Ci aspettiamo che questo valore cresca man mano che apprenderemo di più sui nostri casi d'uso e grazie ai nostri partner di progettazione.

Come si esegue il routing delle attività di programmazione tra modelli e harness?

Smart Routing gestisce la decisione di routing, ma poi è necessario poter agire di conseguenza. Funziona in modo nativo all'interno di Claude Code e Codex, ma per gli agenti di programmazione notiamo prestazioni migliori scegliendo non solo il modello giusto, ma anche l'harness di programmazione corretto. Aiutare gli ingegneri a trarre vantaggio dal modello e dall'harness scelti richiede un livello superiore alle singole sessioni di programmazione per orchestrarle. Ecco perché abbiamo creato Omnigent.

Smart Routing è implementato in Omnigent a due livelli:

In primo luogo, gli sviluppatori che utilizzano Omnigent possono selezionare Smart Routing invece di scegliere manualmente un harness di programmazione specifico. Omnigent seleziona quindi automaticamente sia l'harness che il modello per ciascuna attività, con il routing dei modelli gestito da Smart Routing in Unity AI Gateway. Questo design offre a sviluppatori e amministratori la libertà di fornire personalizzazioni, come linee guida a livello di organizzazione o l'opzione di utilizzare la cronologia delle conversazioni precedenti, senza dover modificare il client ogni volta.

Ciò significa anche che tutti gli avvii di sub-agenti passano attraverso l'API Smart Routing, consentendo ai sub-agenti di sfruttare un harness e un modello diversi. Il prompt iniziale dell'utente è spesso poco specificato e difficile da valutare in termini di complessità, quindi i sub-agenti consentono di adattare il nuovo lavoro in base alle nuove informazioni, con una cache pulita e istruzioni chiare. Una singola attività può essere soggetta a decisioni di routing sfumate tra la pianificazione e il lavoro parallelo dei sub-agenti (ad esempio, puoi indirizzare attività di riepilogo di codebase di grandi dimensioni verso modelli più economici mentre progetti l'architettura con quelli più costosi), portando a risparmi ancora più consistenti.

Come si valuta se il routing dei modelli funziona?

Un routing dei modelli efficace deve ottimizzare sia i costi che la produttività degli sviluppatori, e non solo i costi. È fondamentale disporre di segnali di feedback, poiché i router sono ancora tecnologie emergenti che richiederanno molte iterazioni. Il nostro primo passo in questo senso è stato registrare tutte le tracce delle sessioni di programmazione per una valutazione successiva. Vogliamo considerare sia i costi che l'esperienza degli sviluppatori: non vogliamo ottimizzare i costi a scapito della produttività.

Con Unity AI Gateway, le tracce degli agenti di programmazione possono essere registrate in Unity Catalog. Si tratta di dati estremamente sensibili, che nella maggior parte delle aziende più mature devono rimanere regolati da policy di accesso e tagging sofisticate.

Abbiamo utilizzato sia modelli AI che la revisione umana per analizzare le tracce e valutare le modifiche al router. Quando abbiamo eseguito questa analisi sulle nostre sessioni prima del routing, abbiamo osservato che gran parte delle sessioni spendeva cifre da modelli di frontiera per attività che non ne avevano bisogno, semplicemente perché il modello predefinito era quello più costoso. In pratica, il modo per verificare che il router sia utile consiste nel monitorare continuamente le seguenti metriche:

• Suddivisione delle sessioni per modello
• Numero di sessioni completate end-to-end dai modelli instradati
• Risparmio economico derivante dal routing

I prossimi sviluppi del routing intelligente dei modelli

Riteniamo che questo sia un ambito ricco di opportunità e intendiamo continuare a condurre ricerche approfondite in materia. Siamo ancora all'inizio, quindi abbiamo molto da imparare.
La nostra prima sfida è stata rappresentata da dati di benchmark inaffidabili che non corrispondono al comportamento reale degli utenti. Le attività di benchmark sono insolitamente lineari e ognuna si presenta come un blocco di lavoro autonomo. Sebbene i router offrano buone prestazioni in questi casi, le sessioni reali spesso sono del tutto diverse.

• I prompt iniziali sono raramente precisi, poiché ciò che uno sviluppatore digita all'inizio è più un sintomo o un'intenzione approssimativa che una specifica, e il nostro router legge quel primo messaggio e prende una decisione.
• Le sessioni vengono riutilizzate, quindi la decisione corretta per la prima richiesta può rivelarsi errata alla quarta, e nulla interroga nuovamente il router.

Stiamo quindi esplorando nuove direzioni per raccogliere maggiori informazioni e sperimentare nuove tecniche:

1. Iniziare dove la definizione dell'ambito dell'attività è immediata. Le revisioni delle PR, l'avvio di sotto-agenti, le migrazioni batch e i job pianificati sono completamente definiti fin dall'inizio perché la descrizione dell'attività è stata scritta da una macchina. Il routing funziona già oggi su questa categoria senza modificare le abitudini di nessuno, ed è per questo che stiamo partendo da qui.
2. Effettuare il routing dopo alcuni passaggi, non al primo. Per il lavoro interattivo, il prompt iniziale è il momento peggiore per decidere, e nulla ci obbliga a farlo subito. Al contrario, può essere utile lasciare che un modello economico gestisca lo scambio iniziale e ponga domande di chiarimento, per poi instradare l'attività una volta che ha preso forma. È preferibile esplorare con un modello piccolo e veloce, migliorando così sia i costi che l'esperienza.
3. Rendere le sessioni più brevi. Le sessioni incentrate su una singola attività si prestano meglio al routing e costano meno; gli strumenti possono favorire questo approccio rendendo l'avvio di una nuova sessione la scelta più naturale quando cambia l'argomento.
4. Rendere economico il passaggio da un modello all'altro. Tutte le soluzioni sopra indicate richiedono che il cambio di modello a metà sessione sia conveniente. Oggi, con i costi dominati dal tasso di riscontri nella cache (cache-hit-rate), il passaggio a metà sessione è insostenibile su larga scala. La compattazione del contesto è il punto di giunzione naturale, poiché in quel momento si verifica già un mancato riscontro nella cache (cache miss) (questo è il modo in cui lo gestisce Devin Fusion di Cognition). Nel tempo, vogliamo che il livello di routing tariffichi esplicitamente i cache miss, anziché incorporare questo aspetto nel modo in cui utilizziamo il router.

Il routing viene solitamente presentato come un modo per spendere meno. Sebbene la maggior parte dei nostri vantaggi derivi dal pagamento di prezzi inferiori per attività semplici, lo stesso meccanismo può aiutarci a decidere quando spendere di più per ottenere un risultato migliore. La massimizzazione del valore funziona in entrambi i sensi: scegliere il modello economico quando è sufficiente ed essere pronti a spendere di più quando il valore lo giustifica.

Gli strumenti di programmazione spesso spingono gli utenti a consumare sempre più token, ma ciò che vogliamo davvero è ottimizzare l'output produttivo per dollaro, non i token. Scegliere un modello più economico e veloce quando è sufficiente non fa solo risparmiare denaro. Fa anche risparmiare tempo e mantiene la limitata capacità dei modelli di frontiera disponibile per le attività che ne hanno realmente bisogno.

Prova lo Smart Routing oggi stesso

Lo Smart Routing è ora disponibile in versione Beta tramite Unity AI Gateway. Instrada automaticamente le attività di programmazione al modello corretto in base alla complessità, aiutando i team a raggiungere prestazioni di livello "frontiera" con un risparmio sui costi di oltre il 30%, selezionando il modello migliore per ogni attività. Per i team che desiderano ridurre i costi di programmazione AI senza limitare la scelta o la produttività degli sviluppatori, lo Smart Routing offre un'alternativa alla selezione manuale dei modelli o all'uso di rigidi limiti di spesa. E con Omnigent, puoi estendere il routing intelligente a tutti i modelli e sistemi di programmazione.

Per iniziare, visita le pagine della nostra documentazione:

• Per il routing dei modelli: Abilita lo Smart Routing tramite Unity AI Gateway
• Per il routing di modelli + harness: Usa lo Smart Routing con Omnigent (v0.9.0+)

Scopri di più su Unity AI Gateway visitando il nostro sito web.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale