GPT-6.1 Terra: il token costa meno, il clic sbagliato no

Un agente apre una schermata, riconosce un campo, inserisce un dato e preme “Salva”. Dalla demo sembra una sequenza banale, quasi una versione più elegante delle vecchie macro. Poi scopri che il campo era quello sbagliato, che il pulsante ha prodotto due richieste oppure che il dato è finito nella pratica di un altro cliente. Il modello ha lavorato velocemente. Il sistema, invece, ha appena creato lavoro per qualcuno.

È da qui che guarderei il lancio di GPT-6.1 Terra annunciato da OpenAI il 26 ottobre 2026. Non dal solito confronto tra classifiche, ma da una domanda molto meno fotogenica: quanto costa portare un processo dall’input a un risultato corretto, verificato e recuperabile? Perché il prezzo di un token lo trovi in una tabella. Quello di un clic sbagliato, spesso, lo scopri quando devi rimettere a posto il database.

La novità non è che l’AI sappia cliccare

OpenAI presenta Terra come un modello rapido per ragionamento visivo, interazione con applicazioni e scrittura. Lo propone per attività come leggere fatture, interpretare disegni tecnici, compilare moduli e lavorare su interfacce. È una direzione precisa: non limitarsi a produrre una risposta, ma trasformare una rappresentazione dello schermo in un’azione. Per chi sviluppa software aziendale, la differenza è importante: il modello non è più soltanto una componente che suggerisce; diventa una componente che può tentare di modificare lo stato di un processo.

Ma un’interfaccia non è un contratto affidabile. Un pulsante può spostarsi, una modale può sovrapporsi, una sessione può scadere, un salvataggio può essere asincrono. E una schermata visivamente plausibile non dimostra che l’operazione sia stata registrata correttamente. Questo vale per qualsiasi sistema di computer use, indipendentemente dal modello. La capacità di riconoscere un controllo è soltanto il primo requisito; il secondo è sapere se l’azione ha avuto l’effetto previsto.

I numeri di Terra sono interessanti. E vanno letti per quello che sono

Nel materiale ufficiale OpenAI dichiara che, su Terminal-Bench 4.0 con reasoning effort massimo, GPT-6.1 Terra risolve il 50,3% dei task contro il 21,5% attribuito a GPT-5.6 Terra. L’azienda segnala anche completamenti oltre tre volte più rapidi rispetto a GPT-6 Astra e GPT-6.1 Sol in alcune valutazioni di agenti, oltre a miglioramenti su computer use e factuality. Sono risultati riportati dal produttore, con condizioni di test specifiche: non li sto presentando come misurazioni indipendenti e non li trasferirei automaticamente a un gestionale WordPress, a un ERP o a una procedura amministrativa.

La scheda API di Terra indica prezzi standard di 1 dollaro per milione di token in input, 0,05 per milione di input in cache e 5 dollari per milione di output. Indica anche una finestra di contesto fino a 1.050.000 token, con una particolarità da non perdere: sopra 272.000 token di input, le tariffe standard della richiesta sono maggiorate. Inoltre la documentazione distingue il costo delle scritture in cache, le eventuali chiamate a strumenti e altre modalità tariffarie. Quindi anche il prezzo al milione, se letto senza le condizioni, è già una semplificazione.

Non è una critica al modello. È una critica a chi prende un numero pubblicato in un contesto preciso, lo incolla in una slide e lo trasforma in una promessa commerciale. Un benchmark misura quello che il benchmark è progettato per misurare. Non il numero di telefonate che riceverai quando l’automazione sbaglia una fattura.

Il vero denominatore è la pratica completata correttamente

Immaginiamo due agenti incaricati di registrare documenti in un applicativo. Il primo costa 2 centesimi di inferenza per tentativo e conclude correttamente il 90% delle pratiche. Il secondo costa 4 centesimi e ne conclude il 98%. Se ogni pratica fallita richiede un intervento umano che, per ipotesi, costa 1 euro, il costo medio illustrativo diventa 12 centesimi per il primo e 6 centesimi per il secondo. Il modello più caro per chiamata è quello che costa meno per pratica. Sono numeri inventati per spiegare il metodo, non risultati sperimentali su Terra.

La formula è semplice da capire e difficile da applicare con disciplina: costo operativo per pratica valida = (inferenza + strumenti + retry + verifiche + recuperi umani) / pratiche concluse correttamente. Se una procedura viene eseguita due volte e genera due ordini, non puoi contare due successi perché il modello ha ricevuto due risposte HTTP positive. Devi contare un incidente e il costo necessario a correggerlo.

Un agente economico che produce errori costosi non è un risparmio. È un modo più veloce di spostare il costo dal cloud alla scrivania di qualcuno.

È una distinzione vicina a quella affrontata parlando della Decisions API e dei confini tra risposta e workflow. Qui però il problema si sposta un passo avanti: non basta prendere una decisione strutturata, perché l’agente deve anche attraversare un’interfaccia, eseguire un’azione e dimostrare che lo stato finale sia corretto.

Quattro controlli prima di lasciare un agente davanti a un gestionale

1. Verifica delle precondizioni

Prima di premere un pulsante, l’agente deve sapere su quale record sta operando, quale stato si aspetta e quali permessi possiede. Un nome cliente letto da uno screenshot non è un identificatore univoco. Quando l’applicazione offre API con ID, versioni e controlli di concorrenza, è spesso più sicuro usare quelle per le mutazioni e riservare il computer use ai passaggi che non hanno un’interfaccia programmabile adeguata.

2. Idempotenza e conferma dello stato

Un timeout dopo “Salva” non autorizza a ripetere alla cieca l’operazione. Potrebbe essere riuscita e avere soltanto perso la risposta. Servono chiavi di idempotenza quando disponibili, controlli sullo stato finale e regole per distinguere “non eseguito” da “eseguito ma non confermato”. È un problema classico dei sistemi distribuiti: la presenza di un modello non lo rende meno classico.

3. Permessi proporzionati e checkpoint

Un agente che deve compilare una bozza non dovrebbe poter confermare un pagamento o cancellare una pratica. Le azioni irreversibili richiedono un confine applicativo chiaro, spesso con approvazione umana. Screenshot, contenuto delle pagine e messaggi visualizzati vanno trattati anche come dati non fidati: un testo presente in una pagina non può diventare una nuova istruzione operativa. È lo stesso principio di separazione del perimetro già discusso a proposito della sandbox e dei confini di sicurezza degli agenti.

4. Audit che permetta davvero il recupero

Registrare “task completato” non basta. Per capire un errore servono almeno identificativo della pratica, versione del workflow, modello ed effort richiesti, strumenti usati, azioni tentate, verifiche effettuate e motivo del fallimento. Senza dati sensibili superflui nei log, naturalmente. L’obiettivo non è collezionare screenshot: è poter rispondere a una domanda concreta quando qualcosa non torna.

Come testerei Terra prima di metterlo in produzione

Preparerei un insieme di casi rappresentativi: documenti puliti, moduli con campi ambigui, sessioni scadute, messaggi di errore, salvataggi lenti, interfacce che cambiano e operazioni già eseguite. Stesso ambiente iniziale, stessi dati, stessa policy di permessi e una definizione verificabile di successo. Poi confronterei Terra con il modello già in uso senza cambiare contemporaneamente prompt, strumenti, effort e orchestrazione.

Misurerei la percentuale di pratiche concluse correttamente al primo tentativo, il costo per pratica valida, il tempo totale fino alla verifica, la distribuzione dei fallimenti e i minuti di intervento umano. Guarderei anche i casi peggiori, non soltanto la media: un processo che normalmente impiega venti secondi ma una volta su cinquanta resta incastrato per mezz’ora non è automaticamente pronto per un ufficio. E ripeterei i test dopo modifiche dell’interfaccia, perché il software dall’altra parte continua a evolvere.

Solo a quel punto avrebbe senso parlare di routing: quali pratiche affidare a un modello economico, quali a uno più capace e quali fermare. Se il risparmio nasce da una misura reale e riproducibile, è ingegneria. Se nasce dalla lettura di una tabella prezzi senza guardare gli errori, è ottimismo contabilizzato male.

La differenza tra un modello e un sistema

GPT-6.1 Terra rende più accessibile una classe di automazioni che fino a poco tempo fa era più costosa. È una notizia tecnica concreta, e i progressi dichiarati meritano test seri. Ma non compriamo affidabilità acquistando soltanto inferenza. L’affidabilità si costruisce con contratti, limiti, verifiche, dati e procedure di recupero. Il modello può diventare più veloce, più economico e più bravo a leggere lo schermo; la responsabilità di ciò che accade dopo il clic rimane nell’architettura.

Per questo la domanda da fare al prossimo fornitore di agenti non è “quanto costa un milione di token?”. È “quante pratiche chiude correttamente, come lo dimostri e chi paga quando non ci riesce?”. Se non sa rispondere, il problema non è la qualità del modello. È che sta vendendo una demo al posto di un processo.