L’arrivo di GPT-6 Astra rende meno indicativo il semplice confronto tra i prezzi per milione di token quando si deve valutare il costo operativo di un modello AI. Il nuovo modello di OpenAI presenta infatti tariffe nominali elevate, pari a 10 dollari per milione di token di input e 50 dollari per milione di token di output nella fascia standard, ma può utilizzare quantità di token sensibilmente differenti rispetto ad altri modelli per completare lo stesso lavoro. Nei sistemi agentici, inoltre, una singola attività può comprendere più chiamate al modello, ragionamento, utilizzo di strumenti, retry e verifiche, rendendo il prezzo unitario dei token soltanto una delle componenti del costo complessivo. Di conseguenza, per gli ingegneri diventa più utile misurare quanto costa arrivare a un risultato effettivamente accettabile piuttosto che limitarsi al costo di una singola richiesta.
Il cambiamento emerge chiaramente dai benchmark di coding agent. Nel test indipendente DeepSWE v1.1, GPT-6 Astra con reasoning xhigh e Gemini 3.8 Flash con reasoning high raggiungono entrambi un risultato del 74%, ma presentano profili economici molto diversi: Astra registra un costo medio di 6,52 dollari per attività e produce circa 30.000 token di output, mentre Gemini arriva a 2,36 dollari per attività generando circa 143.000 token. Il modello OpenAI utilizza quindi circa un quinto dei token di output, ma il maggiore prezzo unitario impedisce a questa riduzione di tradursi automaticamente in un costo complessivo inferiore. Il confronto mostra perché due modelli con una qualità simile possano occupare posizioni molto differenti quando vengono misurati separatamente costo, quantità di token e capacità.
Un comportamento simile compare confrontando GPT-6 Astra con GPT-5.6 Sol. Nelle valutazioni dell’Artificial Analysis Intelligence Index, le configurazioni a massimo reasoning dei due modelli raggiungono entrambe un valore arrotondato di circa 61 punti; Astra utilizza circa l’11,5% di token di output in meno, ma il costo per attività risulta superiore di circa il 75,7%. In altri test, tuttavia, la situazione cambia: sui workload nei quali Astra completa il compito con meno tentativi, meno reasoning o una configurazione meno costosa, il costo finale può risultare competitivo nonostante il prezzo per token superiore. È quindi necessario confrontare specifici operating point e specifici workload, evitando di attribuire a un modello un unico livello di convenienza valido per qualunque attività.
La metrica più utile diventa così il cost per accepted task, cioè il costo per attività che supera effettivamente i criteri di accettazione definiti per il sistema. Il calcolo deve comprendere le spese API prodotte sia dai tentativi riusciti sia da quelli falliti, le eventuali chiamate a strumenti esterni, i retry, le esecuzioni correttive e, quando rilevante, il tempo umano necessario per controllare o correggere il risultato. La somma di queste componenti viene poi rapportata al numero di attività effettivamente accettate. Un modello meno costoso per singola chiamata può quindi diventare più caro se produce un numero elevato di risultati respinti o richiede ripetute correzioni, mentre un modello con tariffe API maggiori può risultare economicamente conveniente se aumenta in misura sufficiente il tasso di successo al primo tentativo e riduce il lavoro di revisione.
Il tasso di accettazione modifica infatti direttamente l’economia del sistema. Se, in una semplificazione, un’attività costa 0,40 dollari per tentativo e l’80% dei risultati viene accettato, il costo atteso del solo modello sale a circa 0,50 dollari per risultato valido. Un modello che costa soltanto 0,20 dollari per tentativo ma produce risultati accettabili nel 40% dei casi arriva allo stesso costo atteso di 0,50 dollari prima ancora di considerare revisione umana e altri costi del workflow. Nei sistemi agentici più lunghi, questo effetto può essere amplificato dal fatto che un tentativo fallito può avere già consumato molti token, effettuato chiamate a tool e occupato tempo di esecuzione prima di essere respinto.
Anche la latenza deve essere misurata a livello dell’intera attività e non soltanto attraverso la velocità di generazione dei token. Per un agente, il tempo percepito comprende chiamate a strumenti, interrogazioni esterne, code, retry, verifiche e possibili fasi di revisione. Le metriche p50 e p95 end-to-end risultano quindi più utili del semplice throughput del modello, perché descrivono rispettivamente il comportamento tipico e le esecuzioni più lente che possono influenzare un servizio in produzione. Un modello capace di generare rapidamente una risposta può comunque produrre un workflow lento se utilizza molti tool o deve ripetere più volte il lavoro, mentre una singola esecuzione più costosa può ridurre la latenza complessiva se evita passaggi successivi.
Il costo deve inoltre essere separato nelle diverse categorie di token realmente fatturate. Per GPT-6 Astra, nella fascia standard, l’input non memorizzato in cache costa 10 dollari per milione di token, le letture dalla cache 1 dollaro, le scritture in cache 12,50 dollari e l’output 50 dollari. Quando il prompt supera 272.000 token di input vengono applicate tariffe long-context superiori all’intera richiesta, con 20 dollari per milione di token di input, 2 dollari per le letture dalla cache, 25 dollari per le scritture e 75 dollari per l’output. Questo rende necessario registrare separatamente input, cache, output e dimensione del contesto anziché utilizzare come metrica un generico numero totale di token.
Le modalità di elaborazione aggiungono un’altra variabile. Workload asincroni che non richiedono una risposta immediata possono essere eseguiti con modalità più economiche come Batch o Flex, mentre elaborazioni sensibili alla latenza possono utilizzare modalità più veloci con un costo maggiore. Il modello, il livello di reasoning e la modalità di esecuzione formano quindi insieme un operating point che deve essere valutato per ciascun tipo di lavoro. Anche all’interno della stessa famiglia, aumentare il reasoning può produrre incrementi non lineari nel consumo di token e nel costo, per cui utilizzare sempre l’impostazione più potente non rappresenta necessariamente la configurazione economicamente migliore.
Per i team di engineering diventa quindi importante costruire eval basate su attività realmente rappresentative dell’ambiente di produzione e definire prima dell’esecuzione che cosa costituisce un risultato accettabile. Su un workflow di coding, per esempio, l’accettazione può richiedere che la patch superi i test automatici e una revisione del codice; per un sistema di estrazione dati può significare rispetto dello schema e corrispondenza esatta con i valori della fonte; in un assistente aziendale può includere correttezza della risposta e gestione appropriata dell’escalation. Le esecuzioni dei modelli candidati possono poi essere confrontate registrando costo totale, numero di tentativi, token, tempo end-to-end, chiamate ai tool e minuti di revisione, mantenendo costanti dataset, prompt e criteri di valutazione.
I benchmark pubblici rimangono utili per individuare i modelli da testare, ma non definiscono automaticamente la soluzione economicamente migliore per una specifica applicazione. I dati disponibili mostrano, ad esempio, che pochi punti percentuali di capacità possono essere associati a differenze di costo di un ordine di grandezza e che modelli più economici possono essere sufficienti per attività delimitate, mentre i sistemi frontier possono risultare vantaggiosi sulle richieste più ambigue, lunghe o difficili. Ne deriva un’architettura nella quale la selezione del modello può avvenire a runtime: le attività più semplici vengono indirizzate verso configurazioni che soddisfano il livello minimo di qualità al costo più basso, mentre quelle che falliscono, presentano catene di dipendenze lunghe o comportano un costo elevato in caso di errore possono essere inoltrate a modelli e livelli di reasoning superiori.
Con GPT-6 Astra, quindi, il costo per milione di token continua a essere necessario per calcolare la fattura API, ma non è più sufficiente per stabilire l’economia di un sistema AI. Per valutare correttamente un modello occorre mettere insieme qualità effettivamente accettata, costo completo per attività, tasso di successo al primo tentativo, retry, consumo delle diverse categorie di token, utilizzo degli strumenti, latenza end-to-end e tempo umano di revisione. Il parametro economicamente rilevante si sposta così dal costo dell’intelligenza consumata al costo del lavoro che il sistema riesce effettivamente a portare a termine.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)