Asana: costi ridotti di 76x nei test browser con GPT‑6.1 Sol
Con GPT‑6 Astra in Codex, Asana ha ridotto di 76 volte i costi del suo agente per il browser e ne ha quintuplicato la velocità nei test, per offrire ai clienti modelli più capaci.
76x
Costi stimati del modello inferiori con il flusso di lavoro ottimizzato di GPT-6.1 Sol
5x
Esecuzioni nel browser più veloci con il flusso di lavoro ottimizzato di GPT-6.1 Sol
0,47 $
Costo medio stimato del modello con il flusso di lavoro ottimizzato di GPT-6.1 Sol
Affidando gli esperimenti a GPT‑6 Astra in Codex, Asana ha ottimizzato il flusso di lavoro del suo agente per il browser su GPT‑6.1 Sol, riducendo i costi di 76 volte e aumentando la velocità di 5 volte.
Asana aiuta i clienti ad automatizzare il lavoro nelle applicazioni aziendali tramite StackAI(si apre in una nuova finestra), una piattaforma che ha acquisito(si apre in una nuova finestra). Con StackAI, i clienti possono creare flussi di lavoro che navigano sui siti web, compilano moduli e raccolgono informazioni senza scrivere codice. Alla scala operativa di Asana, anche le piccole inefficienze di questi flussi di lavoro si accumulano.
Frank Hidalgo, PhD, CTO di StackAI presso Asana, si è posto l’obiettivo di rendere l’agente per il browser più veloce e meno costoso da eseguire. Ha chiesto a GPT‑6 Astra in Codex di analizzare l’agente, testare i miglioramenti e confrontare i risultati. Un lavoro che, secondo le sue stime, avrebbe richiesto da uno a due mesi se svolto manualmente è stato completato in circa una settimana.
Lo studio di Asana su 144 esecuzioni(si apre in una nuova finestra) ha testato GPT‑6.1 Sol e altri tre modelli di frontiera, qui denominati Modello A, B e C. Il flusso di lavoro ottimizzato ottenuto su GPT‑6.1 Sol ha registrato in media un costo stimato del modello di 0,47 $ e circa quattro minuti per esecuzione: un costo 76 volte inferiore e una velocità 5 volte superiore rispetto alla configurazione iniziale in produzione sul Modello B.
“Ecco come funzionano nella pratica i team di persone e agenti. Un ingegnere ha indicato la direzione, GPT-6 Astra ha condotto gli esperimenti e i risultati sono arrivati in produzione attraverso Command. Questo dimostra come Asana renda concreti i team di persone e agenti.”
Per procedere rapidamente, Hidalgo ha iniziato usando GPT‑6 Astra in Codex per mappare la base di codice e spiegare come l’agente costruiva ogni richiesta al modello. GPT‑6 Astra ha scoperto che l’agente memorizzava nella cache le istruzioni fisse e le definizioni degli strumenti, ma non la cronologia, in continua crescita, del testo e degli screenshot raccolti dalle pagine. Ogni richiesta reinviava quindi quella cronologia a prezzo pieno.
Inoltre, l’agente eliminava gli screenshot più vecchi e tagliava il testo a quasi ogni passaggio. Ogni modifica alterava la cronologia, quindi la sola memorizzazione nella cache non sarebbe stata utile. Inoltre, la perdita di quelle informazioni poteva costringere l’agente a tornare su pagine già lette.
Hidalgo ha esaminato le correzioni proposte da GPT‑6 Astra e ne ha selezionate tre da testare:
Estendere la memorizzazione nella cache alla cronologia di navigazione dell’agente
Aumentare la quantità di testo che poteva conservare
Rimuovere gli screenshot a gruppi anziché a ogni passaggio
GPT‑6 Astra ha iniziato con test rapidi per stabilire quali variabili fossero rilevanti. Poiché il codice non era stato progettato per esperimenti controllati, lo ha poi ristrutturato in modo che un unico frontend e un unico backend potessero supportare molti flussi di lavoro in parallelo, ciascuno con le proprie impostazioni.
Astra ha condotto lo studio completo: limiti della cronologia di 120.000 e 480.000 caratteri e sei strategie di gestione della cache e degli screenshot, ciascuna testata tre volte su ognuno dei quattro modelli (vedi la tabella seguente). La strategia più efficace lasciava accumulare gli screenshot fino a 20, per poi conservare solo il più recente. In questo modo la cronologia precedente rimaneva invariata per intervalli più lunghi tra una rimozione e l’altra. Insieme al limite più ampio della cronologia, questa strategia ha dato origine al flusso di lavoro ottimizzato. Ogni configurazione svolgeva lo stesso compito: raccogliere sei campi per ciascuno di 32 libri da un catalogo dimostrativo pubblico, rappresentativo delle attività che alcuni clienti Asana eseguono in StackAI.
Modello | Descrizione | Prezzo |
|---|---|---|
Modello A | Un modello più piccolo e meno costoso di un altro laboratorio di ricerca di frontiera, rilasciato nell’autunno 2025 | Metà del prezzo di GPT‑6.1 Sol |
Modello B | Il modello utilizzato inizialmente in produzione, dello stesso laboratorio del Modello A, rilasciato nell’estate 2026 | Stesso prezzo di GPT‑6.1 Sol |
Modello C | Una versione aggiornata del Modello B, rilasciata nell’autunno 2026 | Stesso prezzo di GPT‑6.1 Sol |
GPT‑6.1 Sol | Il modello di OpenAI |
GPT‑6 Astra ha eseguito i flussi di lavoro ed esaminato richieste, registri di utilizzo e output; sessioni separate del modello hanno poi verificato il lavoro. Le richieste, le tracce dei dati e i risultati di ogni sessione sono stati registrati in Command(si apre in una nuova finestra), la piattaforma di Asana per la distribuzione del software, così che il team potesse riesaminare l’intero studio in seguito. Da Command, i risultati sono stati trasformati prima in ticket e poi in pull request, e le modifiche sono state portate in produzione.
“Farlo manualmente mi avrebbe richiesto da uno a due mesi. Con GPT-6 Astra in Codex è bastata circa una settimana: impostavo un /goal prima di andare a letto e rivedevo i risultati al mattino.”
Per il Modello B, l’ottimizzazione ha ridotto il costo stimato del modello da almeno 36,21 $ (alcune esecuzioni iniziali raggiungevano il limite di passaggi prima di concludersi) a 1,24 $ per esecuzione: una riduzione di 29 volte. Il flusso di lavoro ottimizzato su GPT‑6.1 Sol costava ancora 2,6 volte meno: 0,47 $. Ogni esecuzione del flusso di lavoro ottimizzato ha completato il compito e restituito la risposta corretta.
Medie di 3 esecuzioni. ≥: la configurazione di riferimento include esecuzioni interrotte al raggiungimento del limite, quindi la sua media è un limite inferiore.
I due fattori di riduzione a destra si riferiscono al Modello B ottimizzato. Il Modello B è stato testato nella fase 1; il Modello C e Sol 6.1 nella fase 2 dello stesso studio (linea tratteggiata).
Sul solo GPT‑6.1 Sol, con il limite più ampio della cronologia, la nuova strategia di gestione della cache e degli screenshot ha ridotto il costo di 4 volte, da 1,97 $ a 0,47 $ per esecuzione. Ogni chiamata costava circa 3 volte meno, perché l’89% dell’input proveniva dalla cache, a un costo pari al 5% del prezzo dell’input non memorizzato nella cache. Anche le esecuzioni sono diventate più veloci: da almeno 22,5 minuti con la configurazione iniziale sul Modello B a circa quattro minuti con il flusso di lavoro ottimizzato su GPT‑6.1 Sol.
Media di 3 esecuzioni, barre d’errore della deviazione standard. ≥: la media include un’esecuzione interrotta al limite o incompleta, quindi il valore effettivo è almeno pari a quello indicato.
Le barre usano il tema blu. Valutare gli effetti della cache rispetto alla barra con il limite più ampio di 480k.
I marcatori delle esecuzioni e le barre d’errore della deviazione standard sono ricostruzioni approssimative dell’immagine originale; i valori delle singole esecuzioni e le deviazioni standard non erano disponibili.
Media di 3 esecuzioni, barre d’errore della deviazione standard. ≥: la media include un’esecuzione interrotta al limite o incompleta, quindi il valore effettivo è almeno pari a quello indicato.
Le barre usano il tema blu. Valutare gli effetti della cache rispetto alla barra con il limite più ampio di 480k.
I marcatori delle esecuzioni e le barre d’errore della deviazione standard sono ricostruzioni approssimative dell’immagine originale; i valori delle singole esecuzioni e le deviazioni standard non erano disponibili.
L’indagine ha mostrato anche che la gestione della cronologia influiva sulla capacità stessa dell’agente di produrre una risposta. Fornire a GPT‑6.1 Sol più spazio per conservare la cronologia di navigazione ha portato il numero di esecuzioni che producevano una risposta da tre su 18 con il limite più basso a tutte e 18 con il limite più alto, ciascuna con la risposta corretta. Per Hidalgo, il valore aziendale consiste nell’offrire ai clienti l’accesso a modelli più veloci e più capaci, mantenendo sostenibili i costi operativi.
“Prima, i costi limitavano la scelta dei modelli che potevamo offrire ai clienti per questi carichi di lavoro. Rendendo l’agente più efficiente, possiamo offrire ai clienti un modello migliore e più veloce, riducendo al contempo i nostri costi operativi.”
Asana ha rilasciato le modifiche alla navigazione nel browser in StackAI e sta sviluppando strumenti per rendere più semplice ripetere esperimenti simili. Nel tempo, il team intende integrare questi test nelle valutazioni della piattaforma, così che i clienti e i team interni possano confrontare costi, tempi di esecuzione e qualità delle risposte quando configurano i propri agenti.
“Il collo di bottiglia non è più la velocità di rilascio, ma l’attenzione umana. Siamo vicini a un mondo in cui ogni ingegnere è un product manager alla guida di una flotta di agenti.”
Asana ora usa GPT‑6 Astra in Codex per testare le funzionalità del prodotto prima del rilascio: Astra naviga nella piattaforma, prova input diversi e segnala bug agli addetti al controllo qualità. Hidalgo vede in questo approccio la base di un nuovo ciclo di sviluppo software, con molte sessioni di agenti nel cloud che testano le funzionalità in parallelo.
Lo studio completo è disponibile sui blog di Asana(si apre in una nuova finestra) e StackAI(si apre in una nuova finestra).
