Agenti browser: come Asana ha tagliato i costi di 76 volte con caching e screenshot
Se state costruendo un agente che naviga sul web, la voce di costo che vi sorprenderà non è il modello: è la cronologia. Ogni passo aggiunge testo e screenshot, e a ogni richiesta l'agente rimanda tutto indietro. OpenAI ha raccontato come Asana (tramite StackAI) ha affrontato il problema con GPT-6.1 Sol: i numeri sono interessanti, ma la lezione vale più dei numeri.
Dove si perdevano i soldi
L'agente browser di StackAI metteva già in cache le istruzioni fisse e le definizioni degli strumenti. Non faceva però lo stesso con la parte che cresce di più: la cronologia di navigazione, fatta di testo delle pagine e screenshot. Risultato: a ogni richiesta l'intera storia veniva reinviata a prezzo pieno.
C'era poi un secondo problema, più sottile. Quasi a ogni passo l'agente eliminava i vecchi screenshot e accorciava il testo. Ogni modifica altera la cronologia, e una cronologia che cambia continuamente non beneficia della cache, perché il prefisso non è più identico. In più, buttare via informazioni poteva costringere l'agente a rileggere pagine già visitate, pagando due volte.
Questo è un pattern che si ritrova in molti agenti: si ottimizza il contesto per tenerlo piccolo, ma così si rompe proprio il meccanismo che lo renderebbe economico.
Le tre correzioni
Il team ha esteso la cache alla cronologia di navigazione, ha aumentato la quantità di testo conservata e ha cambiato il modo di eliminare gli screenshot: a blocchi invece che a ogni passo. La politica migliore è stata accumulare fino a 20 screenshot e ridurli solo allora al più recente, lasciando il prefisso invariato il più a lungo possibile.
Per verificare l'effetto hanno fatto un test sistematico: 144 esecuzioni, due budget di cronologia, sei politiche di cache e screenshot, tre ripetizioni su quattro modelli. Il compito era volutamente semplice: raccogliere sei campi per ciascuno di 32 libri da un catalogo demo pubblico. Un benchmark sintetico, quindi, ma proprio per questo confrontabile.
I numeri (e come leggerli)
Con il workflow ottimizzato su GPT-6.1 Sol, secondo la fonte, il costo medio stimato è di 0,47 $ per esecuzione e la durata di circa 4 minuti. Rispetto alla configurazione originale in produzione, significa 76 volte meno costo e 5 volte meno tempo. Attenzione però: quel 76x è un confronto cumulativo tra un modello e una configurazione vecchi e quella nuova, e il dato di partenza è un minimo, perché alcune esecuzioni originali si sono fermate al limite di passi senza completare.
Il dato più utile per chi decide è un altro: la sola ottimizzazione su Sol, a parità di modello, ha ridotto il costo di 4 volte (da 1,97 $ a 0,47 $). Qui l'89% dell'input arrivava dalla cache, pagata il 5% del prezzo non in cache. È la parte replicabile sui vostri agenti, indipendentemente dal modello.
Un secondo dettaglio conta: con il budget di cronologia più piccolo Sol ha prodotto una risposta in 3 esecuzioni su 18; con quello più grande in 18 su 18, tutte corrette. Risparmiare sul contesto in modo troppo aggressivo non fa risparmiare: fa fallire.
Cosa ne penso
Due osservazioni da chi mette in produzione questi sistemi. Primo: il costo di un agente è una proprietà del design del contesto, non solo del listino del modello. Cambiare modello senza guardare cosa si reinvia a ogni passo è ottimizzare il pezzo sbagliato. Secondo: l'approccio di Asana è replicabile, perché hanno registrato le sessioni e le hanno trasformate in ticket e modifiche. Senza tracce misurabili non si ottimizza niente.
Limiti da tenere presenti: il test è su un compito semplice e il risultato dipende dai prezzi della cache e dal comportamento del modello. Su siti reali, con pagine dinamiche, i numeri saranno diversi.
In pratica
- Misurate la quota di cache hit del vostro agente: se la cronologia cambia a ogni passo, il prefisso non è stabile e state pagando prezzo pieno.
- Potate a blocchi, non a ogni passo: eliminate screenshot e testo vecchi solo quando serve, così il prefisso resta invariato più a lungo.
- Testate più budget di contesto su un compito reale, contando sia il costo sia il tasso di completamento: un contesto troppo piccolo fa fallire l'agente.
Se questo tema vi riguarda, lasciate un commento con la vostra esperienza sui costi degli agenti e condividete l'articolo con chi sta costruendo automazioni; iscrivetevi al blog per i prossimi approfondimenti.
Fonte: OpenAI, "Asana cuts model costs 76x in browser tests with GPT-6.1 Sol", 9 ottobre 2026 – https://openai.com/index/asana-browser-agent (https://openai.com/index/asana-browser-agent)
Dove si perdevano i soldi
L'agente browser di StackAI metteva già in cache le istruzioni fisse e le definizioni degli strumenti. Non faceva però lo stesso con la parte che cresce di più: la cronologia di navigazione, fatta di testo delle pagine e screenshot. Risultato: a ogni richiesta l'intera storia veniva reinviata a prezzo pieno.
C'era poi un secondo problema, più sottile. Quasi a ogni passo l'agente eliminava i vecchi screenshot e accorciava il testo. Ogni modifica altera la cronologia, e una cronologia che cambia continuamente non beneficia della cache, perché il prefisso non è più identico. In più, buttare via informazioni poteva costringere l'agente a rileggere pagine già visitate, pagando due volte.
Questo è un pattern che si ritrova in molti agenti: si ottimizza il contesto per tenerlo piccolo, ma così si rompe proprio il meccanismo che lo renderebbe economico.
Le tre correzioni
Il team ha esteso la cache alla cronologia di navigazione, ha aumentato la quantità di testo conservata e ha cambiato il modo di eliminare gli screenshot: a blocchi invece che a ogni passo. La politica migliore è stata accumulare fino a 20 screenshot e ridurli solo allora al più recente, lasciando il prefisso invariato il più a lungo possibile.
Per verificare l'effetto hanno fatto un test sistematico: 144 esecuzioni, due budget di cronologia, sei politiche di cache e screenshot, tre ripetizioni su quattro modelli. Il compito era volutamente semplice: raccogliere sei campi per ciascuno di 32 libri da un catalogo demo pubblico. Un benchmark sintetico, quindi, ma proprio per questo confrontabile.
I numeri (e come leggerli)
Con il workflow ottimizzato su GPT-6.1 Sol, secondo la fonte, il costo medio stimato è di 0,47 $ per esecuzione e la durata di circa 4 minuti. Rispetto alla configurazione originale in produzione, significa 76 volte meno costo e 5 volte meno tempo. Attenzione però: quel 76x è un confronto cumulativo tra un modello e una configurazione vecchi e quella nuova, e il dato di partenza è un minimo, perché alcune esecuzioni originali si sono fermate al limite di passi senza completare.
Il dato più utile per chi decide è un altro: la sola ottimizzazione su Sol, a parità di modello, ha ridotto il costo di 4 volte (da 1,97 $ a 0,47 $). Qui l'89% dell'input arrivava dalla cache, pagata il 5% del prezzo non in cache. È la parte replicabile sui vostri agenti, indipendentemente dal modello.
Un secondo dettaglio conta: con il budget di cronologia più piccolo Sol ha prodotto una risposta in 3 esecuzioni su 18; con quello più grande in 18 su 18, tutte corrette. Risparmiare sul contesto in modo troppo aggressivo non fa risparmiare: fa fallire.
Cosa ne penso
Due osservazioni da chi mette in produzione questi sistemi. Primo: il costo di un agente è una proprietà del design del contesto, non solo del listino del modello. Cambiare modello senza guardare cosa si reinvia a ogni passo è ottimizzare il pezzo sbagliato. Secondo: l'approccio di Asana è replicabile, perché hanno registrato le sessioni e le hanno trasformate in ticket e modifiche. Senza tracce misurabili non si ottimizza niente.
Limiti da tenere presenti: il test è su un compito semplice e il risultato dipende dai prezzi della cache e dal comportamento del modello. Su siti reali, con pagine dinamiche, i numeri saranno diversi.
In pratica
- Misurate la quota di cache hit del vostro agente: se la cronologia cambia a ogni passo, il prefisso non è stabile e state pagando prezzo pieno.
- Potate a blocchi, non a ogni passo: eliminate screenshot e testo vecchi solo quando serve, così il prefisso resta invariato più a lungo.
- Testate più budget di contesto su un compito reale, contando sia il costo sia il tasso di completamento: un contesto troppo piccolo fa fallire l'agente.
Se questo tema vi riguarda, lasciate un commento con la vostra esperienza sui costi degli agenti e condividete l'articolo con chi sta costruendo automazioni; iscrivetevi al blog per i prossimi approfondimenti.
Fonte: OpenAI, "Asana cuts model costs 76x in browser tests with GPT-6.1 Sol", 9 ottobre 2026 – https://openai.com/index/asana-browser-agent (https://openai.com/index/asana-browser-agent)
agenti AI, prompt caching, GPT-6.1 Sol, costi AI, automazione
