Risultato 76x dell'agente browser di GPT-6.1 Sol: cosa ha effettivamente misurato Asana

Asana ha pubblicato uno studio sui costi degli agenti browser l'8 ottobre 2026, e lo sviluppatore di GPT-6.1 Sol lo ha riportato il giorno successivo con il titolo "Asana riduce i costi del modello di 76 volte nei test browser con GPT-6.1 Sol". Il 76x è reale nel senso che qualcuno l'ha misurato, ma non è un dato sul prezzo di GPT-6.1 Sol. È un dato su ciò che accade quando si corregge una cache dei prompt rotta su un agente browser e poi si sostituisce il modello che vi sta dietro. La stessa ottimizzazione, eseguita sul modello che Asana aveva già in produzione — un modello che chiama Model B — ha ridotto i costi di 29 volte da sola. GPT-6.1 Sol ha fornito il restante 2,6x. Gli esperimenti sono stati eseguiti da GPT-6 Astra che lavora in Codex, e il modello dietro il baseline è un modello di un concorrente che Asana chiama Model B, quindi due livelli dello stesso fornitore e un rivale non nominato compaiono tutti nella storia. Quanto segue separa la parte del risultato che puoi copiare lunedì dalla parte che appartiene allo stack specifico di Asana.

Il confronto, espresso esattamente

Lo stack di Asana per questo è StackAI, la piattaforma di automazione dei flussi di lavoro che ha acquisito, che esegue un agente browser che naviga siti web, compila moduli e raccoglie informazioni senza codice. Il compito di test era ristretto e concreto: raccogliere sei campi per ciascuno di 32 libri da un catalogo demo pubblico. È rappresentativo di ciò che alcuni clienti eseguono, ed è anche abbastanza piccolo da far rientrare in una settimana uno studio di 144 esecuzioni.

Il disegno prevedeva sei politiche di caching e screenshot con due budget di cronologia, tre esecuzioni per condizione, su quattro modelli — 144 esecuzioni, più un follow-up di 12 esecuzioni. I costi sono stati calcolati dai contatori di token di ciascun fornitore, e ogni risposta è stata valutata rispetto a un riferimento preparato in modo indipendente. I quattro modelli erano tre modelli di frontiera senza nome (Modelli A, B e C) e GPT-6.1 Sol. Il Modello A è un modello più piccolo ed economico di un altro laboratorio, rilasciato nell'autunno 2025, con un prezzo pari alla metà di GPT-6.1 Sol. Il Modello B è il modello che era in produzione, dello stesso laboratorio di A, rilasciato nell'estate 2026, con lo stesso prezzo di GPT-6.1 Sol. Il Modello C è una versione più recente del Modello B, rilasciata nell'autunno 2026, anch'essa con lo stesso prezzo di GPT-6.1 Sol. I tre sono senza nome in entrambi i testi, quindi il confronto non è riproducibile da un lettore — cosa da sapere prima di trattare 29x come un numero che riguarda il modello di qualcun altro. Questi sono i dati pubblicati da Asana e OpenAI, non cifre verificate in modo indipendente.

La scala dei risultati, tutti numeri forniti da Asana stessa:

• Produzione baseline su Model B — almeno 36,21 $ per esecuzione, almeno 22,5 minuti per esecuzione. Alcune esecuzioni baseline hanno raggiunto il limite di step prima di terminare, quindi la media è un limite inferiore anziché una media effettiva.

• Model B, agente ottimizzato — $1,24 per esecuzione, 4 volte più veloce del baseline, una riduzione dei costi di 29 volte.

• GPT-6.1 Sol, stesso agente ottimizzato — 0,47 $ per esecuzione, circa quattro minuti, una riduzione dei costi di 76 volte e 5 volte più veloce.

• GPT-6.1 Sol, prima e dopo la correzione — da 1,97 $ a 0,47 $ per esecuzione, una riduzione di 4 volte solo grazie a modifiche alla cache e al pruning.

Poiché la baseline è un limite inferiore, 76x è di per sé un valore minimo. La lettura onesta è "almeno 76x", non "76x".

Cosa è cambiato davvero, e perché non è una funzionalità del modello

Il meccanismo è la meccanica della prompt cache, e vale la pena comprenderlo perché si trasferisce a qualsiasi agente tu esegua su qualsiasi modello. Un agente browser ritrasmette i suoi strumenti, il suo system prompt e la sua cronologia crescente di testo delle pagine e screenshot a ogni chiamata al modello. Il prompt caching sconta la parte ripetuta, ma solo il prefisso invariato più lungo — nel momento in cui qualcosa al centro della richiesta cambia, il riutilizzo si interrompe da quel punto in poi.

L'agente di produzione di Asana presentava due difetti che si amplificavano a vicenda. Memorizzava nella cache le sue istruzioni fisse e le definizioni degli strumenti, ma non la sua cronologia di navigazione. E modificava quella cronologia quasi a ogni passo: scartava ogni volta lo screenshot precedente e riduceva il testo più vecchio per rispettare un budget della cronologia. Ogni modifica invalidava il prefisso, quindi la memorizzazione nella cache sarebbe stata quasi inutile anche se fosse stata attivata. Il resoconto di Asana osserva che, sui modelli testati, le letture dalla cache costano da 0,05x a 0,1x il prezzo standard di input — quindi il premio era cospicuo e l'agente lo rifiutava sistematicamente.

La correzione ha due parti. Innanzitutto, metti in cache anche la cronologia, con un marcatore di cache sull'ultimo risultato dello strumento. In secondo luogo, smetti di modificarla a ogni chiamata: conserva gli screenshot e potali in batch con un rapporto di 20 a 1, così l'agente ne mantiene fino a 20 e poi taglia fino a quello più recente. Circa 19 chiamate consecutive riutilizzano quindi un prefisso invariato. Porta il budget della cronologia da 120.000 a 480.000 caratteri, così il testo vecchio non viene più tagliato, e il calcolo torna: su GPT-6.1 Sol, ogni chiamata è costata circa 3 volte meno perché l'89% dell'input proveniva dalla cache.

Il risultato più importante in questo caso è negativo. Memorizzare la cronologia nella cache senza il pruning dei batch, con il budget maggiore, è costato piùche non usare affatto la cache su tre dei quattro modelli — la cache veniva continuamente riscritta e raramente letta. Un'infrastruttura di cache attivata senza una disciplina di cronologia in sola aggiunta è un modo per pagare un sovrapprezzo di scrittura per nulla. Quella modalità di errore è indipendente dal modello, ed è il motivo per cui la stessa correzione ha spostato il Modello B di 29x.

Dove la scelta del modello ha davvero pagato

Escludiamo la correzione del flusso di lavoro e confrontiamo mele con mele: con lo stesso agente ottimizzato, GPT-6.1 Sol è costato 2,6 volte meno di Model B, allo stesso prezzo di listino. Il fattore in più è il comportamento di cache hit, non il listino. Sol ha letto l'89% del suo input dalla cache; Asana non pubblica la quota equivalente per Model B, quindi il 2,6x è un risultato misurato senza una scomposizione pubblicata. Trattalo come "questo modello, su questo carico di lavoro, ha usato meglio la sua cache", non come un vantaggio generale di 2,6 volte rispetto a un modello che non possiamo nominare.

Il lato runtime è inequivocabile: 5 volte più veloce rispetto al baseline, con il workflow Sol ottimizzato a circa quattro minuti contro un baseline di almeno 22,5 minuti. La velocità conta per i costi negli agenti che fatturano a token, perché un modello lento che entra in loop paga per i suoi loop.

Per chiunque stia calcolando i costi: le tariffe API standard di GPT-6.1 Sol sono 2,00 $ per milione di token di input, 0,10 $ per milione di token di input in cache e 10,00 $ per milione di token di output, e il suo sconto per la lettura dalla cache è 0,05 volte la tariffa di input — il più profondo sull'attuale listino di OpenAI. GPT-6 Astra, il modello che ha svolto il lavoro di ingegneria in Codex, costa 10,00 $ di input e 50,00 $ di output, ovvero il divario di cinque volte su cui faceva leva la presentazione di lancio di OpenAI. Il motivo per cui lo studio ha prodotto esecuzioni da 0,47 $ anziché da 2 $ non è il tariffario; è che l'89% di una richiesta molto ripetitiva è stato fatturato a un ventesimo della tariffa di input. Su un agente con uso intensivo di cache la voce di sconto pesa più del prezzo di copertina, e sul nostro catalogo i prezzi di listino dei fornitori vengono trasferiti con 0% di ricarico, quindi un fornitore che sposta un contatore dell'input in cache lo sposta sulla tua fattura lo stesso giorno.

L'altro numero dello studio: il budget della cronologia decideva se l'agente rispondeva o meno.

Il costo per esecuzione è il numero che tutti citano, ma il risultato più utile dello studio riguarda l'affidabilità, ed è quello che un operatore dovrebbe leggere per primo.

• Con un budget di 120.000 caratteri, Model C non ha risposto in nessuna delle sue 18 esecuzioni e GPT-6.1 Sol ha risposto in 3 su 18 — la maggior parte delle esecuzioni ha raggiunto il limite di passaggi senza produrre una risposta.

• A 480.000 caratteri, ogni esecuzione su entrambi i modelli ha risposto, ciascuna con la risposta corretta.

• I modelli più recenti hanno consumato più rapidamente il budget più piccolo: Model C ha ridotto per la prima volta la propria cronologia alla chiamata 10, Model A alla chiamata 64.

• Nel flusso di lavoro ottimizzato, ogni esecuzione ha completato il compito e restituito la risposta corretta, e ogni esecuzione nelle condizioni migliori su ogni modello ha incontrato tutti i 192 fatti che doveva raccogliere.

Questo è un argomento diverso da "più economico". Un budget della cronologia troppo piccolo su un modello capace produce un agente che fallisce esaurendo lo spazio, e fallisce raggiungendo il limite di passi, che è il modo più costoso di fallire — paghi l'intera esecuzione e non ottieni nulla. Aumentare il budget ha aumentato il costo per chiamata e ridotto il costo per risposta, che è l'unico numero che chi gestisce la produzione dovrebbe monitorare. Se stai valutando un modello non collaudato per un agente come questo, lo schema a basso rischio è mantenere la rotta di produzione sul modello di cui ti fidi e mettere quello nuovo dietro un failover o una rotta separata, così un fallimento per limite di passi si manifesta come un fatto di instradamento anziché come un incidente. Ogni modello in questo confronto è raggiungibile tramite un'unica API per oltre 200 modelli con i prezzi di listino dei fornitori trasferiti invariati, il che rende anche lo sconto per lettura della cache confrontabile tra fornitori sulla stessa fattura invece che su cinque dashboard.

Cosa trarre da questo, in ordine

Se gestisci un agente browser o computer-use, nello studio di Asana ci sono tre leve che vale la pena azionare prima di consultare un tariffario:

• Rendi il prefisso della richiesta di sola aggiunta. Qualsiasi modifica per chiamata alla parte centrale della cronologia azzera il riutilizzo della cache da quel punto in poi.

• Potatura in batch. Il follow-up di Asana ha rilevato che mantenere ogni screenshot costa 1,2x in meno per chiamata rispetto alla migliore condizione di potatura su Model B e GPT-6.1 Sol, e circa il 5% in meno su Model C. La potatura resta comunque importante per attività lunghe, finestre di contesto ridotte e letture della cache costose — ma la questione di un rapporto batch di 20:1 riguarda la stabilità della cache, non gli screenshot in sé.

• Imposta il budget della cronologia per singolo modello e verificalo rispetto al limite di passi. Un budget adeguato per un modello può risultare insufficiente per quello successivo.

Due guardrail dello studio sono facili da saltare e non dovrebbero esserlo. Nessuna esecuzione ha raggiunto il budget di 480.000 caratteri, quindi il budget non ha mai vincolato queste esecuzioni — ma un agente che va alla deriva cresce verso il suo limite di contesto, e se la cache si rompe, ogni chiamata paga il prezzo pieno. I limiti massimi su passi, token e costo per esecuzione sono ciò che argina un'esecuzione problematica. Separatamente, lo studio ha usato tre o quattro esecuzioni per condizione con un numero variabile di chiamate, che la stessa Asana dice essere sufficiente per mostrare schemi generali ma non sufficiente per distinguere condizioni che differiscono di qualche punto percentuale. Non estrapolare da questo un delta del 5% e non ricostruire la tua pipeline su quella base.

La parte che è davvero nuova, e la parte che non lo è

Le avvertenze sull'allestimento vale la pena enunciarle chiaramente: quattro modelli, tre dei quali senza nome, un unico compito ristretto su 32 libri, i contatori strumentati di Asana stesso e un resoconto scritto dal fornitore stesso che ospita il risultato. Nulla di tutto ciò è stato riprodotto al di fuori di Asana. Ma il meccanismo è specificato in ogni dettaglio — cronologia in sola aggiunta, marcatore di cache sull'ultimo risultato dello strumento, potatura in batch, budget maggiore, misurare le letture della cache con i contatori del provider — ed è il tipo di risultato che sopravvive all'essere attribuito al laboratorio sbagliato. Il 76x è un numero di Asana su un carico di lavoro Asana. Il motivo per cui vale la pena leggerlo è che dimostra una regola che puoi verificare in un pomeriggio: un agente che modifica la propria cronologia a ogni passo paga il prezzo pieno per una conversazione che ha già avuto.