Routing tra modelli per coding agent: quando conviene

Cosa comporta il routing tra più modelli per un coding agent

Il routing tra più modelli invia ogni richiesta al modello meno costoso in grado di gestirla. Sul traffico delle chat funziona bene. Con un coding agent, invece, di solito costa più di quanto faccia risparmiare, perché la spesa dell’agent dipende soprattutto da un prefisso del prompt memorizzato nella cache per ciascun modello, e il passaggio da un modello all’altro elimina quella cache.

La regola sostenuta da questo articolo è la seguente: usare il routing tra provider per garantire la disponibilità, usare il routing tra livelli di costo soltanto ai confini tra un’attività e l’altra, e mantenere un solo modello per sessione per tutte le attività agentiche. Di seguito viene illustrato il ragionamento.

Definiamo una volta per tutte quattro termini. Un router seleziona un modello per ogni richiesta. Un gateway è il proxy attraverso cui passa la richiesta; può anche occuparsi del routing, ma non necessariamente. Una prompt cache è il meccanismo con cui il provider memorizza il prefisso elaborato del prompt, così una richiesta successiva che ripete quel prefisso viene addebitata a una frazione del prezzo dell’input. Una KV cache (key value cache) applica lo stesso principio all’interno di un server gestito autonomamente.

Perché il traffico chat viene instradato bene, mentre quello degli agenti no

Una richiesta chat corrisponde a un turno. Arriva, viene classificata, viene inviata a un modello e riceve una risposta. Nulla viene mantenuto per la richiesta successiva. Un router può inviare questa domanda a un modello più piccolo e la successiva a uno più grande; nessuna delle due richieste sa che l’altra è esistita. Questo è il carico di lavoro misurato da quasi tutti i benchmark di routing, e i router validi lo gestiscono davvero bene.

Un turno di un agente non corrisponde a una sola richiesta. Una singola istruzione come «correggi il test non riuscito» genera da 20 a 60 chiamate API. Ogni chiamata invia nuovamente l’intera conversazione: il prompt di sistema, ogni definizione degli strumenti, ogni file letto dall’agente e ogni output dei comandi che ha osservato. Il contesto continua a crescere. Alla chiamata 30, il prefisso ripetuto può contenere decine di migliaia di token, mentre il contenuto effettivamente nuovo di ogni chiamata è di poche centinaia di token.

Questa struttura cambia il significato della parola «costoso». Nella chat, il costo è approssimativamente il prezzo del modello moltiplicato per la richiesta. In un ciclo di esecuzione di un agente, il costo dipende dal prefisso, che viene fatturato nuovamente a ogni singola chiamata. Il resto di questo articolo deriva da questo unico fatto.

La cache del prompt è specifica per modello e l’agente vive al suo interno

Anthropic applica alle letture dalla cache un prezzo pari a 0.1 volte il prezzo base degli input e alle scritture in cache con durata di cinque minuti un prezzo pari a 1.25 volte. Questi sono i prezzi di listino pubblicati ad agosto 2026.

[
  {
    "label": "Opus 5",
    "uncached_input_usd": "5.00",
    "cache_read_usd": "0.50"
  },
  {
    "label": "Sonnet 5",
    "uncached_input_usd": "2.00",
    "cache_read_usd": "0.20"
  },
  {
    "label": "Haiku 4.5",
    "uncached_input_usd": "1.00",
    "cache_read_usd": "0.10"
  }
]

Confronta la seconda serie con la prima, riga per riga anziché colonna per colonna. Una lettura dalla cache su Opus 5 costa 0.50 dollari per milione di token. Un input non presente nella cache su Haiku 4.5, il modello meno costoso tra quelli elencati, costa 1.00 dollari. Di conseguenza, rileggere un prefisso già presente nella cache sul modello più costoso costa meno, per token di input, rispetto alla lettura a freddo dello stesso prefisso sul modello meno costoso.

Questo singolo confronto invalida la maggior parte dei piani di routing. Un router che sposta il lavoro verso un livello inferiore confronta i prezzi di listino. Tuttavia, durante una sessione, un agente non paga il prezzo di listino del modello che sta già utilizzando. Paga il prezzo della lettura dalla cache, che è già inferiore alla tariffa per input non presente nella cache del modello meno costoso.

Le cache usano un hash del prefisso del prompt come chiave e sono specifiche per modello. Una richiesta indirizzata a un altro modello viene confrontata con un archivio che non l’ha mai ricevuta, quindi non trova alcuna corrispondenza e paga il prezzo pieno. La cache è inoltre gerarchica: prima gli strumenti, poi il messaggio di sistema e infine i messaggi. Una modifica a qualsiasi livello invalida quel livello e tutti quelli successivi. Di conseguenza, modificare una singola definizione di strumento elimina dalla cache anche il prompt di sistema che si trova dopo di essa. Gli agenti che registrano gli strumenti a runtime possono incorrere in questo problema senza coinvolgere affatto un router.

Il costo effettivo di un singolo cambio durante la sessione

Consideriamo una sessione con un prefisso stabile di 40,000 token, una dimensione comune dopo che un agente ha letto diversi file. Di seguito è riportato il costo del prefisso per un singolo turno, calcolato a partire dai prezzi di listino indicati sopra.

[
  {
    "label": "Opus 5, cache warm",
    "prefix_cost_usd": "0.020"
  },
  {
    "label": "Sonnet 5, turn after switch",
    "prefix_cost_usd": "0.100"
  },
  {
    "label": "Opus 5, cache re-warmed",
    "prefix_cost_usd": "0.250"
  }
]

Restare su Opus 5 con la cache disponibile costa 0.020 dollari per il prefisso di quel turno. Il primo turno dopo il passaggio a Sonnet 5 costa 0.100 dollari, perché Sonnet non contiene alcuna voce per questo prefisso e deve crearne una. Tornare a Opus 5 costa 0.250 dollari, perché la voce originale è scaduta mentre la sessione utilizzava Sonnet.

Il percorso di andata e ritorno paga quindi 2 scritture nella cache per evitare 2 letture dalla cache. In cambio, il cambio consente di ottenere l'output di un turno al prezzo di Sonnet invece che a quello di Opus. Il blocco dei dettagli calcola l'intero percorso: il risparmio è di una frazione di centesimo, mentre la penalità della cache è dell'ordine di decine di centesimi. La penalità è maggiore di oltre un ordine di grandezza e cresce con la lunghezza del prefisso, mentre il risparmio non cresce con essa.

Opus 5, warm read     40,000 x $0.50 / 1e6  = $0.020
Sonnet 5, cache write 40,000 x $2.50 / 1e6  = $0.100   (1.25 x $2 base)
Opus 5, cache write   40,000 x $6.25 / 1e6  = $0.250   (1.25 x $5 base)

800 x ($25 - $10) / 1e6 = $0.012

I formati delle chiamate agli strumenti non sono uguali tra i vari provider

Un agente esegue un ciclo di chiamate agli strumenti, quindi il formato della chiamata è importante in un modo che non si applica mai alla chat. La Messages API di Anthropic restituisce un blocco di contenuto tool_use e si aspetta in risposta un blocco tool_result. Le API compatibili con OpenAI restituiscono un array tool_calls in cui function.arguments è una stringa con codifica JSON, non un oggetto annidato. Un gateway converte un formato nell'altro e, per le chiamate ordinarie, la conversione è corretta.

I problemi compaiono nei casi limite. Le chiamate parallele agli strumenti, in cui un modello emette più chiamate in un'unica risposta, sono rappresentate in modo diverso e non sono supportate allo stesso modo ovunque. L'applicazione rigorosa dello schema è una funzionalità specifica del provider. Di conseguenza, un modello che garantisce argomenti conformi allo schema su un endpoint tende soltanto ad avere argomenti validi su un altro. L'agente rileva la differenza come un risultato dello strumento contenente un errore di analisi, quindi prova a correggerlo consumando un altro turno. Questi turni di correzione vengono fatturati al prezzo pieno del prefisso, quindi una differenza di formato compare sia in fattura sia nella trascrizione.

Gli endpoint self-hosted richiedono una configurazione esplicita. Il server compatibile con OpenAI di vLLM richiede --enable-auto-tool-choice insieme a un --tool-call-parser corrispondente alla famiglia del modello (hermes, mistral, llama3_json e altri), oltre a un template di chat che gestisca i messaggi con ruolo tool. La documentazione di vLLM descrive chiaramente i limiti di questo percorso: con tool_choice="auto" e senza un vincolo di schema rigoroso, vLLM estrae le chiamate agli strumenti dal testo non elaborato, quindi gli argomenti possono occasionalmente essere malformati o non rispettare lo schema dei parametri della funzione. Scegliere il parser sbagliato per il modello è un errore di configurazione che si manifesta come un agente incapace di chiamare gli strumenti. È importante saperlo prima di instradare il traffico verso quell'endpoint. La differenza tra Ollama e vLLM per distribuire autonomamente i modelli è rilevante in questo caso, perché i due sistemi espongono le chiamate agli strumenti con modalità diverse.

Un fallback durante un'attività cambia il comportamento senza generare errori

Il routing di fallback è la funzionalità che più spesso viene abilitata accidentalmente. Un gateway è configurato per riprovare con un altro modello quando il primo restituisce un limite di frequenza o un errore 5xx, quindi mette il modello che ha fallito in cooldown per alcuni secondi. Sul traffico delle chat questo comportamento è corretto. All'interno di un'attività lunga eseguita da un agent, invece, significa che la seconda metà dell'attività viene eseguita da un modello che non hai scelto.

Nessun componente segnala il problema. L'attività non fallisce, l'agent non visualizza avvisi e lo stato di uscita è positivo. Il risultato è un'attività in cui il piano è stato scritto da un modello e le modifiche sono state apportate da un altro, con tono e modalità operative diversi a metà esecuzione. L'unico indicatore affidabile è il campo model nel log delle richieste del gateway o nei metadati della risposta. Se usi i fallback, registra quindi quel campo per ogni richiesta e controllalo quando un risultato non corrisponde alle aspettative. Analizzare il comportamento senza sapere quale modello lo ha prodotto fa perdere più tempo di quanto il fallback ne abbia risparmiato.

La stessa insidia riguarda la compressione del contesto. Molti agent riassumono la cronologia lunga chiamando un modello più piccolo. Se quella chiamata usa un modello diverso o un system prompt diverso, scrive una propria voce nella cache e non aggiorna quella della sessione principale. Il turno completo successivo deve quindi elaborare un prefisso non presente nella cache. La compressione ha ridotto il numero di token, ma ha invalidato il vantaggio della cache.

Il sovraccarico del routing è reale, ma la latenza non è il problema principale

I router aggiungono lavoro per ogni richiesta, quindi è importante quantificarlo correttamente. DigitalOcean riporta che il proprio modello Arch-Router determina l'intento di routing in circa 51 millisecondi, con un'accuratezza del routing del 93.17% nella propria valutazione. Questi sono i loro dati, ottenuti dalle loro misurazioni e dal loro benchmark; non sono i nostri e non rappresentano un risultato universale. Prendendoli per buoni, la conclusione è rassicurante: 51 millisecondi moltiplicati per quaranta chiamate degli agenti corrispondono a circa due secondi aggiunti a un'attività che dura diversi minuti.

Non sono questi due secondi a rendere costoso il routing. Il sovraccarico che incide davvero deriva da un router che esegue la classificazione con una chiamata completa al modello, perché in questo modo ogni richiesta genera una seconda inferenza, con costi e accodamento analoghi a quelli di qualsiasi altra richiesta. Alla base di entrambi c'è il calcolo della cache descritto sopra, che non è affatto un sovraccarico. È il costo dell'operazione che il routing avrebbe dovuto ottimizzare.

Su un server gestito autonomamente vale la stessa regola, ma con meno margine di manovra. L'equivalente locale della prompt cache è il caching dei prefissi nella KV cache, che risiede nella memoria GPU. Ospitare due modelli su una sola GPU divide questa memoria tra loro: ciascun modello mantiene una KV cache più piccola ed espelle i prefissi più rapidamente. Il routing tra due modelli locali può quindi ridurre contemporaneamente il tasso di hit della cache per entrambi. Se stai dimensionando l'hardware per questo scenario, il punto di partenza più utile è la memoria e la CPU di cui un coding agent ha effettivamente bisogno su un VPS, non un router.

La regola decisionale

• Instrada tra provider per garantire la disponibilità. Quando l'alternativa è una richiesta fallita, qualsiasi costo è accettabile. Imposta il fallback su un modello con lo stesso formato per le chiamate agli strumenti, così il ciclo dell'agente continua a funzionare, e registra quale modello ha gestito ogni chiamata.
• Instrada tra livelli solo ai confini delle attività, per contenere i costi. Scegliere Haiku per una ridenominazione e Opus per un refactoring è una decisione corretta se viene presa una volta, prima dell'avvio della sessione. È una decisione errata se viene presa al turno trenta della stessa sessione.
• Imposta un solo modello per sessione per qualsiasi attività agentica. Il valore della sessione risiede nella cache già inizializzata. Considera il cambio di modello come la cancellazione di quella cache, perché di fatto produce questo effetto.
• Instrada liberamente i subagent. Un subagent che parte con un contesto nuovo e di dimensioni ridotte non ha una cache già inizializzata da perdere, quindi può usare il modello più adatto al proprio compito. Questo è l'unico punto all'interno di un agente in cui l'instradamento è quasi gratuito.

Per realizzare questa architettura, il gateway gestisce il lavoro: alias dei modelli ed elenchi espliciti di fallback. Una configurazione minima del proxy LiteLLM è la seguente.

model_list:
  - model_name: agent-primary
    litellm_params:
      model: anthropic/claude-opus-5
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: agent-standby
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"agent-primary": ["agent-standby"]}]
  num_retries: 2
  cooldown_time: 30

Indica a agent-primary il modello da usare e l'agente rimane su quel modello finché non diventa irraggiungibile. Le due voci usano lo stesso provider, quindi il formato delle chiamate agli strumenti non cambia quando entra in funzione il fallback. In quel momento accetti comunque il passaggio a un altro livello, ma è un compromesso accettabile solo perché l'alternativa è una richiesta fallita. Questo è instradamento per la disponibilità senza instradamento basato sui costi, la combinazione più adatta alla maggior parte degli agenti di coding. La procedura completa, incluse chiavi e quote, è descritta in esecuzione di un gateway LiteLLM self-hosted sul proprio VPS, e questo articolo non la ripete intenzionalmente.

Quando un singolo modello scelto correttamente è migliore di qualsiasi router

Il routing serve a gestire la variabilità della difficoltà delle richieste. Un agente di coding presenta meno variabilità di quanto possa sembrare, perché la parte costosa di ogni chiamata è lo stesso prefisso, indipendentemente dalla richiesta. Quando il prefisso rappresenta la parte principale del costo, la differenza tra il tier economico e quello costoso si riduce quasi alla differenza tra i relativi prezzi degli output, che costituiscono una quota ridotta dei token usati da un agente.

La scelta predefinita più trasparente è quindi usare un solo modello, scelto una volta, con il caching attivo e un TTL (time to live) abbastanza lungo da coprire le pause necessarie per leggere un diff. Anthropic offre una scrittura nella cache della durata di un'ora al doppio del prezzo base dell'input. Il costo si recupera dopo due letture, e spesso questa è una leva più efficace di qualsiasi router. Scegli il tier in modo consapevole usando un confronto diretto tra Opus, Sonnet e Haiku e, se il problema resta il costo, riducilo con budget e contesti più piccoli come descritto in controllare i costi degli agenti AI su un VPS, invece di cambiare modello durante la sessione.

Usa il routing quando le richieste sono indipendenti e brevi oppure quando i subagent iniziano con contesti nuovi. Mantieni fisso il modello quando hai una sessione lunga dedicata a una singola attività. La maggior parte del lavoro svolto dagli agenti di coding appartiene al secondo caso. Per questo il router che riduce i costi del tuo prodotto di chat può aumentare i costi in questo contesto senza che sia evidente. Se non hai ancora scelto l'agente, il confronto tra Claude Code, Cursor, Codex e Copilot spiega come ciascuno gestisce la selezione del modello e mostra che alcuni prendono questa decisione al posto tuo.

FAQ

Il cambio di modello durante la sessione invalida davvero la cache del prompt?

Sì. Le cache dei prompt sono indicizzate tramite un hash del prefisso del prompt e vengono memorizzate per modello. Una richiesta inviata a un modello diverso viene quindi confrontata con un archivio che non ha mai ricevuto quel prefisso. Non trova nulla e paga il prezzo completo dell'input non memorizzato in cache. Se la cache è abilitata, paga inoltre la scrittura nella cache. Tornare al modello precedente non recupera la voce originale, perché nel frattempo la durata predefinita di cinque minuti è generalmente scaduta. Controllare i campi cache_read_input_tokens e cache_creation_input_tokens nell'oggetto di utilizzo della risposta: in una sessione lunga, un turno che legge zero token dalla cache è il sintomo del problema.

Instradare le richieste verso un modello più economico è mai più conveniente per un agente?

Solo quando non c'è una cache attiva da perdere. Una lettura dalla cache su Anthropic costa 0.1 volte l'input di base. Di conseguenza, una lettura dalla cache attiva su Opus 5 costa meno dell'input non memorizzato in cache su Haiku 4.5. Quando una sessione ha un prefisso ampio già memorizzato nella cache, il modello attualmente in uso è già l'opzione più economica per l'input. L'instradamento conviene quando il contesto è nuovo e ridotto: all'inizio di un'attività oppure in un subagente che trasporta soltanto il contesto necessario.

Perché il mio agente ha iniziato a comportarsi diversamente a metà di un'attività?

Controllare se è stato attivato un fallback del gateway. Un limite di frequenza o un errore 5xx sul modello primario fa ritentare la richiesta al gateway usando il modello di standby e mette il modello primario in stato di cooldown per alcuni secondi. Il resto dell'attività viene quindi eseguito altrove. Questo non produce errori né avvisi e l'attività risulta comunque completata correttamente. Il campo model nel log delle richieste del gateway o nei metadati della risposta è l'unica registrazione affidabile. Registrarlo per ogni richiesta se si usano fallback.

Le chiamate agli strumenti funzionano allo stesso modo con ogni provider?

Non esattamente. L'API Messages di Anthropic usa i blocchi di contenuto tool_use e tool_result, mentre le API compatibili con OpenAI usano un array tool_calls il cui function.arguments è una stringa codificata in JSON. Un gateway gestisce correttamente i casi comuni, ma le chiamate parallele agli strumenti e l'applicazione rigorosa dello schema variano in base al provider. Su vLLM self-hosted è necessario impostare --enable-auto-tool-choice e un --tool-call-parser compatibile con la famiglia del modello. La documentazione di vLLM specifica inoltre che, senza un vincolo di schema rigoroso, il server estrae le chiamate agli strumenti dal testo grezzo. Di conseguenza, gli argomenti possono risultare occasionalmente malformati.

Per quanto tempo devo impostare il TTL della cache per una sessione di sviluppo?

Usare la durata predefinita di cinque minuti per il lavoro continuativo e l'opzione di un'ora quando una persona deve leggere le differenze tra un turno e l'altro. Anthropic applica un costo di scrittura pari a 1.25 volte l'input di base per la durata di cinque minuti e pari a 2 volte per la durata di un'ora, mentre una lettura costa 0.1 volte. La scrittura con durata di cinque minuti viene ripagata da una sola lettura, quella con durata di un'ora da due letture. Pertanto, in una sessione che si prevede di riprendere in seguito, la durata maggiore generalmente costa meno rispetto al pagamento di un prefisso non presente nella cache.