Cache e riuso di contesto ribaltano la scelta tra GPT-4.1 e Claude Sonnet

Su 417 task della AppWorld Test Challenge, lo stesso CodeAct agent è costato 79 dollari con Claude Sonnet 4.6 e 155 dollari con GPT-4.1: 0,19 contro 0,37 dollari a task. Sulla carta doveva accadere il contrario: GPT-4.1 ha prezzi per token più bassi in input e in output, mentre Sonnet richiede circa tre volte più passi di ragionamento per chiudere gli stessi task. Eppure ha vinto sul costo effettivo.

Gli autori indicano la cache come causa principale. I carichi agentici riusano ampie porzioni di contesto tra uno step e l’altro. Con un alto tasso di cache hit, il costo dell’input crolla. In questo scenario il prezzo delle letture da cache pesa più del prezzo per token. Sonnet aveva un costo di cache-read inferiore e questo ha compensato sia il prezzo base più alto sia i passi extra, fino a ribaltare il confronto.

Il punto non riguarda solo questi due modelli. Riguarda come si sceglie un modello in sistemi con routing. Molti la trattano come una classificazione: dato un input, predico quale modello usare. Nella pratica agentica, gli autori sostengono che la scelta diventa un problema di ottimizzazione di sistema, dove contano metriche operative oltre al listino del modello.

Affidarsi ai prezzi per token porta a decisioni deboli quando il workload riusa contesto. In questi carichi, la curva dei costi dipende da quanta parte del contesto si può rileggere a basso prezzo e dal pattern di riuso su più step. Nel test, questi fattori hanno reso GPT-4.1 più caro per task pur partendo da un vantaggio nominale sul token.

Il banco di prova è cruciale. I 417 task dell’AppWorld Test Challenge, eseguiti dallo stesso CodeAct agent, mostrano differenze che non emergono da un confronto di listino. La misura del caching fa la differenza e sposta l’equilibrio economico tra modelli.

Cosa implica per chi progetta sistemi? Prima domanda: il tuo workload riusa molto contesto su più step? Se sì, la cache conta. Seconda: qual è il costo delle letture da cache sul modello candidato? Se basso, può battere un modello più economico per token. Terza: qual è il pattern di riuso? Più il contesto resta stabile, più il caching produce risparmi.

Questo cambia il routing. Non basta mappare input a modelli. Serve ottimizzare il sistema guardando a:

• tasso di cache hit atteso lungo la catena di step;
• prezzo delle letture da cache rispetto al prezzo per token;
• numero di passi previsto per task e quota di contesto riusabile.

Operativamente: quando il riuso è alto, privilegia modelli con cache-read economiche anche se costano di più per token. Se il riuso è basso o il contesto cambia spesso, il listino per token torna rilevante. Aggiorna le policy di routing con soglie sulla cache hit e simula i costi per task, non per chiamata. Così eviti scelte miopi su prezzi nominali e allinei il modello al profilo reale del carico.