Un gruppo di ricercatori della National University of Singapore, della DAMO Academy di Alibaba, di Hupan Lab, Zhejiang University, University of California Berkeley e Hong Kong University of Science and Technology ha sviluppato ACRouter, un sistema progettato per scegliere automaticamente quale modello linguistico utilizzare per ogni specifica attività di programmazione.
Il progetto nasce da un limite comune agli assistenti di coding e agli agenti software attuali. Strumenti come Claude Code, Codex e altre piattaforme di sviluppo assistito tendono generalmente a utilizzare lo stesso modello per richieste molto differenti, dalla generazione di una semplice funzione alla correzione di un errore in un repository composto da numerosi file. Questa impostazione semplifica il funzionamento del servizio, ma non garantisce che ogni incarico venga assegnato al modello più efficace o economicamente conveniente.
ACRouter parte invece dal presupposto che nessun modello sia il migliore in tutte le categorie di programmazione. Anche un sistema complessivamente molto potente può essere superato da modelli più economici o specializzati quando il compito riguarda, per esempio, la progettazione di algoritmi, la produzione di test automatici o l’analisi dei dati.
Nei test condotti dai ricercatori, Claude Opus 4.6 ha ottenuto la migliore prestazione media generale, pari al 42,9%, ma non ha dominato tutte le attività. Nella progettazione di algoritmi GLM-5 ha raggiunto il 47,2%, contro il 25,4% di Opus, con un vantaggio relativo dell’86%. Nella generazione di test Qwen3-Max ha ottenuto l’82,7%, rispetto al 39,2% di Opus, mentre nelle attività di data science Kimi-K2.5 ha raggiunto il 18,4%, contro il 14,2% del modello Anthropic. Complessivamente, cinque modelli differenti sono risultati i migliori in almeno una delle nove categorie principali considerate.
Questa distribuzione delle competenze rende inefficiente utilizzare sempre il modello più costoso. Il problema, tuttavia, non può essere risolto semplicemente classificando ogni richiesta in una categoria e collegandola a un modello prestabilito. Le attività reali non sempre rientrano chiaramente in una classe conosciuta e possono cambiare struttura, linguaggio, livello di difficoltà o contesto operativo.
I ricercatori hanno quindi formalizzato il routing dei modelli come un processo continuo denominato Agent-as-a-Router. Il sistema non prende una decisione isolata per ogni prompt, ma lavora attraverso un ciclo chiamato Context-Action-Feedback. Prima analizza il contesto disponibile, quindi sceglie il modello da utilizzare, verifica il risultato ottenuto e inserisce le informazioni raccolte nel contesto delle decisioni successive.
Il meccanismo consente al router di apprendere durante l’uso. Quando un modello risolve correttamente una determinata tipologia di problema, l’esperienza viene registrata. Allo stesso modo, vengono conservati i fallimenti, i costi sostenuti e le tracce della verifica. Quando arriva una nuova richiesta simile, il sistema può quindi basarsi non soltanto su statistiche generali, ma anche sui risultati concretamente osservati nelle esecuzioni precedenti.
Secondo i test preliminari, il principale ostacolo al funzionamento dei router AI non è la loro incapacità di ragionare, ma la mancanza di informazioni sulle reali prestazioni dei modelli. Un router zero-shot basato su Claude Sonnet 4.6 ha raggiunto una prestazione media del 41,41%. La semplice aggiunta della descrizione della categoria del compito non ha prodotto miglioramenti, portando il risultato al 41,18%. Quando sono state fornite statistiche sulle prestazioni precedenti dei modelli, il punteggio è invece salito al 47,74%, con un miglioramento relativo del 15,3%.
ACRouter traduce questo principio in un’architettura composta da tre moduli principali: Orchestrator, Verifier e Memory. L’Orchestrator decide quale modello utilizzare. Per effettuare la scelta considera la tipologia del compito, il linguaggio, la difficoltà, le statistiche storiche e le attività simili già presenti nella memoria. La politica centrale utilizza una versione da 0,8 miliardi di parametri di Qwen3.5, ottimizzata sul benchmark del progetto, affiancata da regole euristiche e da un sistema di voto ponderato.
Il Verifier controlla la qualità del risultato prodotto dal modello selezionato. Nel caso delle attività eseguibili può analizzare la sintassi, applicare il codice, eseguire test in un ambiente isolato Docker e verificare se l’output soddisfa i requisiti. Per altri incarichi può utilizzare controlli basati su regole, confronto tra più risposte, estrazione dei test presenti nel prompt e valutazioni effettuate da un ulteriore modello.
Il sistema non si limita quindi a chiedere al modello se la propria risposta sia corretta, ma prova a ottenere segnali misurabili dall’esecuzione. Il punteggio risultante, il costo monetario, il modello utilizzato e i dettagli della verifica vengono inviati al modulo Memory.
Memory è un archivio vettoriale online che conserva le attività precedenti utilizzando rappresentazioni numeriche del loro contenuto. Quando arriva una nuova richiesta, il sistema individua tramite similarità coseno i problemi più vicini già affrontati e mostra all’Orchestrator quali modelli abbiano funzionato o fallito in situazioni analoghe. L’implementazione descritta può contenere fino a 20.000 esperienze e può utilizzare servizi specializzati come voyage-code-3 oppure modelli locali come BGE-large per creare gli embedding.
Questa memoria aggiornata continuamente distingue ACRouter dai router statici. Un classificatore tradizionale viene addestrato una volta e successivamente applica sempre la stessa politica. ACRouter modifica invece la propria base informativa dopo ogni esecuzione e può adattarsi quando cambiano i problemi, le prestazioni dei modelli o la distribuzione delle richieste.
Per valutare il sistema è stato creato CodeRouterBench, un ambiente composto da 10.111 attività provenienti da oltre 15 benchmark di programmazione. Il set comprende generazione del codice, progettazione di algoritmi, correzione degli errori, completamento del codice, refactoring, data science, programmazione multilingua, comprensione del codice e generazione di test.
Sette categorie vengono valutate eseguendo direttamente il codice in ambienti isolati, mentre le restanti utilizzano metriche specifiche integrate da una valutazione automatica. Il benchmark comprende 7.080 attività utilizzate per costruire e calibrare i router, 2.919 attività separate per il test sulla stessa distribuzione e 176 problemi completamente differenti destinati alla verifica fuori distribuzione.
Le 176 prove più complesse riguardano la programmazione agentica a livello di repository e sono state ricavate da SWE-bench Verified, LongCLI-Bench, FeatureBench e SWE-CI. A differenza dei problemi a risposta singola, richiedono pianificazione su più passaggi, navigazione tra file, modifica di repository e debugging iterativo. I risultati vengono verificati attraverso sandbox Docker e strumenti derivati da mini-swe-agent.
Il pool messo a disposizione del router comprende otto modelli di fascia avanzata: Claude Opus 4.6, Claude Sonnet 4.6, GPT-5.4, Qwen3-Max, Qwen3.5-Plus, GLM-5, Kimi-K2.5 e MiniMax-M2.7. Per ciascuna attività sono stati raccolti punteggi verificati e dati relativi ai token e ai costi, in modo da poter confrontare non soltanto la qualità finale, ma anche l’efficienza economica delle decisioni.
Nel test composto dalle 2.919 attività appartenenti alle categorie conosciute, ACRouter ha ottenuto una prestazione media del 49,98%, il risultato più alto tra tutti i router confrontati. Il metodo euristico DimensionBest, che conosceva già il modello mediamente migliore per ciascuna categoria, si è fermato al 47,50%, mentre i router statici basati su regressione logistica, BERT, reti MLP e altri classificatori hanno ottenuto risultati compresi approssimativamente tra il 46% e il 47%.
L’utilizzo esclusivo di Claude Opus 4.6 ha raggiunto soltanto il 43,83%. Il risultato mostra che inviare ogni richiesta al modello con la migliore media generale non garantisce le prestazioni più elevate, perché ignora le specializzazioni degli altri sistemi.
Il confronto economico è ancora più netto. Sulle 2.919 attività, l’impiego esclusivo di Opus ha generato un costo stimato di 34,02 dollari. ACRouter ha sostenuto un costo di 13,21 dollari, includendo sia l’uso dei modelli selezionati sia il funzionamento del router. Il sistema ha quindi speso circa 2,6 volte meno rispetto alla configurazione basata sempre su Opus, ottenendo contemporaneamente un punteggio superiore di oltre sei punti percentuali.
Il modello più economico utilizzato da solo, Kimi-K2.5, ha richiesto soltanto 2,90 dollari, ma la prestazione è scesa al 36,66%. Il risultato evidenzia che il routing non consiste semplicemente nello scegliere il sistema meno costoso, ma nel trovare un equilibrio tra qualità e prezzo per ogni singola attività.
ACRouter ha raggiunto un indice prestazione-costo pari a 3,79, rispetto a 1,29 della configurazione basata esclusivamente su Opus. Alcuni router statici più leggeri hanno registrato un rapporto economico superiore perché richiedono meno risorse, ma hanno prodotto risultati qualitativi inferiori e hanno mostrato forti difficoltà quando sono stati sottoposti ad attività diverse da quelle utilizzate durante lo sviluppo.
Questa differenza è emersa soprattutto nelle prove fuori distribuzione. Sulle 176 attività agentiche a livello di repository, ACRouter ha raggiunto una prestazione media del 62,50%, superando l’utilizzo esclusivo di Opus, fermo al 57,14%, e il router Qwen3.5-0.8B ottimizzato staticamente, che ha ottenuto il 55,36%.
I classificatori statici hanno subito un calo molto più marcato. Regressione logistica, TF-IDF con MLP e le varianti di RouteLLM hanno ottenuto risultati compresi tra l’8,93% e il 21,43%, inferiori persino alla selezione casuale, che ha raggiunto il 31,25%. I router basati su bandit online si sono adattati meglio, arrivando rispettivamente al 49,82% e al 46,43%, ma sono rimasti comunque al di sotto di ACRouter.
Il sistema viene valutato anche attraverso il cumulative regret, una metrica che misura quanto le decisioni del router si allontanino progressivamente da quelle di un selettore teoricamente perfetto, capace di conoscere in anticipo il miglior modello per ogni attività. Un valore più basso indica che il router accumula meno errori di scelta durante il flusso di richieste.
ACRouter ha registrato un cumulative regret di 205,5 nelle attività appartenenti alla distribuzione conosciuta. I router statici hanno ottenuto valori compresi approssimativamente tra 284 e 317, mentre l’uso esclusivo di Opus è arrivato a 387,1. Nei test fuori distribuzione ACRouter ha ottenuto un valore di 17, contro 26,7 di Opus e valori compresi tra circa 59 e 73 per molti classificatori statici.
La differenza aumenta con il procedere delle attività. I sistemi statici continuano ad accumulare errori perché non aggiornano le proprie informazioni, mentre ACRouter utilizza i risultati verificati per migliorare le decisioni successive. Il vantaggio non deriva quindi soltanto dal modello impiegato per il routing, ma dal ciclo che collega scelta, esecuzione, verifica e memoria.
Il progetto comprende anche integrazioni adattabili a strumenti utilizzati dagli sviluppatori. Il repository ufficiale contiene supporto sperimentale per Claude Code Router e cc-switch, consentendo di effettuare la selezione del modello a livello di gateway o proxy prima che la richiesta venga inviata al fornitore scelto. È presente inoltre una dimostrazione capace di instradare prompt verso Codex, Claude Code oppure OpenCode. Codice, dati, risultati di riferimento e benchmark sono stati pubblicati per consentire la riproduzione offline degli esperimenti senza effettuare nuove chiamate alle API.
La stessa architettura può essere adattata a differenti esigenze operative. Le aziende possono modificare il peso assegnato alla qualità e al costo, ampliare il pool con altri modelli, sostituire gli strumenti di verifica e personalizzare la memoria in base ai propri repository. Il principio può inoltre essere esteso oltre la programmazione, utilizzando agenti simili per scegliere non soltanto tra modelli linguistici, ma anche tra strumenti, API o procedure differenti.
I ricercatori segnalano comunque alcuni limiti. Le stime economiche si basano sui token effettivamente misurati e sui prezzi pubblici delle API, perché non è possibile conoscere con precisione i tassi di utilizzo della cache applicati dai provider. I valori monetari devono quindi essere interpretati come confronti relativi e non come una previsione esatta dei costi di produzione.
Anche il test agentico è stato limitato a 40 passaggi per attività, invece dei 250 previsti da alcune configurazioni standard, per contenere la spesa complessiva. Inoltre, l’implementazione attuale utilizza una combinazione specifica di modello linguistico, ricerca k-nearest neighbors e memoria vettoriale. Architetture basate su forme differenti di memoria o aggiornamento dei parametri potrebbero produrre risultati ulteriormente diversi.
ACRouter mostra così un possibile cambiamento nell’uso enterprise dei modelli AI. Invece di scegliere un unico fornitore o utilizzare sempre il sistema più potente, una piattaforma può trattare i modelli come risorse specializzate, assegnando dinamicamente ogni attività al sistema che offre il miglior compromesso tra competenza, affidabilità e costo. Il valore del router non dipende soltanto dalla capacità di interpretare il prompt, ma dalla possibilità di verificare ciò che accade realmente dopo ogni scelta e utilizzare quell’esperienza per le decisioni future.