OpenAI afferma che le correzioni di Codex possono estendere l'utilizzo fino al 50%

OpenAI afferma che gli utenti di Codex dovrebbero poter sfruttare l'utilizzo dal 10% al 50% più a lungo dopo che gli ingegneri hanno corretto diversi bug che consumavano l'allocazione disponibile. L'aggiornamento, rilanciato attraverso Google News, ha incluso anche un reset per gli utenti a pagamento di Codex e ChatGPT Work. Questa combinazione sembra un semplice aumento della capacità, ma la cifra in evidenza comprende diverse correzioni e carichi di lavoro molto variabili.

La distinzione è importante perché OpenAI non ha annunciato un aumento uniforme del 50% delle quote. Ha affermato che il miglioramento dipende da come ogni persona utilizza Codex. Chi esegue sessioni ricche di immagini potrebbe vedere un risultato, mentre un utente colpito da un obiettivo fuori controllo potrebbe sperimentare qualcosa di completamente diverso.

L'aggiornamento segue mesi di lamentele riguardo ad allocazioni che si esaurivano più rapidamente del previsto. Alcune segnalazioni riguardavano restrizioni isolate sugli account, mentre altre descrivevano loop di modello inutili, chiamate ripetute agli strumenti o pianificazioni di automazione attivate troppo spesso. OpenAI ha ora riconosciuto diversi meccanismi che possono sprecare utilizzo, ma non ha pubblicato un benchmark riproducibile del miglioramento complessivo.

Il conflitto principale non è quindi tra OpenAI e un altro assistente di programmazione. È tra la promessa di efficienza di OpenAI e la limitata visibilità che gli utenti hanno sulla misurazione dell'utilizzo di Codex. L'azienda afferma di aver corretto problemi concreti, ma i clienti non possono ancora collegare in modo indipendente ogni cambiamento di quota a una risposta del modello, a una chiamata di strumento, a un worker in background o a un'automazione non riuscita.

Cosa afferma OpenAI di aver corretto in Codex

L'aggiornamento mira all'attività sprecata degli agenti, non a un semplice errore di fatturazione o a un'espansione universale dei limiti degli account.

Il responsabile dell'ingegneria di OpenAI Thibault Sottiaux ha affermato che l'azienda aveva esaminato migliaia di segnalazioni e distribuito una serie di correzioni. Una ripubblicazione pubblica del suo aggiornamento sull'utilizzo elenca problemi relativi alla compattazione del contesto, ai worker di memoria, agli obiettivi, alle automazioni e ai sottoagenti.

La compattazione del contesto è il processo di abbreviazione di una lunga conversazione affinché l'agente possa continuare entro la finestra di contesto disponibile. Secondo Sottiaux, Codex talvolta conservava immagini vecchie durante questo processo. Quelle immagini potevano mantenere il contesto abbastanza grande da attivare un altro ciclo di compattazione.

OpenAI ha stimato che la correzione di questo comportamento abbia ridotto l'utilizzo di circa il 10% per le persone che lavorano frequentemente con immagini. Questo gruppo può includere sviluppatori che chiedono a Codex di ispezionare screenshot, stati del browser, riferimenti di design o errori nei test visivi.

Il problema della memoria aveva una portata più limitata ma una coda lunga più grave. I worker di memoria in background potevano ereditare hook di arresto, ovvero regole eseguite quando un agente tenta di terminare. Un hook che impediva il completamento poteva lasciare un worker a verificare ripetutamente se fosse autorizzato a fermarsi.

OpenAI ha affermato che il problema interessava meno dell'1% degli utenti. Tuttavia, secondo quanto riportato, l'azienda ha individuato un thread che ha verificato 15.000 volte se potesse fermarsi. L'esempio mostra perché un bug di orchestrazione apparentemente raro possa consumare una capacità significativa.

Gli obiettivi hanno creato un'altra modalità di errore. Un obiettivo configurato poteva concludersi, ma talvolta l'agente proseguiva oltre il punto di arresto previsto. Codex poteva anche continuare a riprovare uno strumento non funzionante anziché riconoscere che l'operazione non era più produttiva.

OpenAI ha affermato che gli esempi osservati consumavano tra il 15% e il 70% di un'allocazione settimanale. Questa fascia non è una media e non va interpretata come tale. Descrive esempi provenienti da una coda problematica in cui il sistema non riusciva a interrompere correttamente il lavoro.

Anche le automazioni personalizzate potevano essere eseguite più frequentemente di quanto previsto dalle relative pianificazioni. Un'attività non supervisionata che si attiva troppo spesso è particolarmente difficile da diagnosticare perché l'utente potrebbe non osservare il momento in cui avviene il consumo.

La correzione dei sottoagenti riguarda la selezione dei modelli. I sottoagenti sono agenti di supporto che gestiscono parti delegate di un'attività più ampia. OpenAI ha affermato che modelli più piccoli, incluso Luna, potevano talvolta selezionare assistenti più capaci anche quando l'utente non li aveva richiesti.

Un assistente più capace può consumare l'allocazione in modo diverso rispetto al modello che l'utente si aspettava di eseguire. Correggere questo comportamento dovrebbe rendere l'esecuzione delle attività più prevedibile, sebbene OpenAI non abbia pubblicato una stima separata dei risparmi per la modifica dei sottoagenti.

Si tratta di bug tecnicamente distinti. Uno ingrandiva il contesto, un altro impediva la terminazione di un worker, un altro ignorava il confine di un obiettivo e un altro aumentava la frequenza delle automazioni. Riunirli in un titolo dal 10% al 50% rende l'annuncio facile da comprendere, ma nasconde una notevole variabilità sottostante.

Il reset associato complica ulteriormente l'interpretazione. Un reset rinnova un'allocazione, mentre una correzione dell'efficienza cambia la velocità con cui il lavoro futuro la consuma. Gli utenti che hanno ricevuto entrambe le modifiche contemporaneamente non possono valutare il miglioramento ingegneristico confrontando il proprio dashboard prima e subito dopo l'aggiornamento.

Perché il titolo di Google News richiede una lettura attenta

“Fino al 50% in più” descrive un risultato favorevole per un carico di lavoro, non un aumento garantito per ogni account Codex a pagamento.

Il rapporto che circola tramite Google News riflette accuratamente il limite superiore della dichiarazione pubblica di OpenAI. Tuttavia, il linguaggio “fino a” richiede sempre un denominatore. I lettori devono sapere quale misura di utilizzo è migliorata, quali modelli sono stati testati e quali schemi di attività hanno prodotto il maggior guadagno.

OpenAI non ha affermato che ogni account abbia ricevuto il 50% in più di capacità settimanale. Non ha nemmeno pubblicato una semplice tabella che mostrasse come una vecchia allocazione fosse diventata 1,5 volte più grande. L'affermazione si riferisce invece a quanto più lontano dovrebbe arrivare l'utilizzo esistente dopo l'eliminazione di diverse fonti di spreco.

La differenza risulta più chiara con un esempio ipotetico. Se un carico di lavoro in precedenza attivava cicli di compattazione non necessari, la correzione di tali cicli consente alla stessa allocazione di supportare lavoro più utile. Il limite nominale può rimanere invariato mentre la capacità effettiva migliora.

Un altro utente potrebbe non aver mai incontrato quel bug. Il guadagno di quella persona dalla stessa correzione sarebbe vicino allo zero. Potrebbe comunque beneficiare di modifiche agli obiettivi, agli strumenti, ai sottoagenti o al comportamento di attesa, ma solo quando il suo flusso di lavoro raggiunge quei percorsi.

Le stesse indicazioni di Codex di OpenAI affermano che il consumo dipende dal modello, dalla complessità dell'attività, dal contesto, dal ragionamento, dalla velocità e dagli strumenti. Codex, ChatGPT Work e altre funzionalità di agente idonee possono inoltre attingere da un'allocazione e da un pool di crediti condivisi.

Questo sistema condiviso rende inaffidabili i confronti informali. Una persona potrebbe attribuire un cambiamento nel dashboard a una sessione di programmazione con Codex, anche se ha contribuito un'altra funzionalità di agente. Allo stesso modo, due prompt con formulazioni comparabili possono consumare in modo diverso quando uno attiva molte interazioni con strumenti.

La fascia dal 10% al 50% dovrebbe pertanto essere intesa come una stima operativa. Indica che OpenAI si aspetta meno sprechi in vari tipi di carico di lavoro. Non fornisce una conversione stabile tra prompt, token, attività completate e quota dell'abbonamento.

Google News è rilevante in questo caso come canale di scoperta, non come origine dell'affermazione. La dichiarazione alla base è arrivata da un responsabile dell'ingegneria di OpenAI, mentre un articolo indipendente l'ha proposta a un pubblico più ampio. Google non ha testato Codex né verificato il miglioramento riportato.

Questa attribuzione è importante perché l'aggregazione può comprimere l'incertezza. Un titolo conciso lascia poco spazio per distinguere un reset automatico, un worker in background riparato e una stima di efficienza. I lettori possono facilmente interpretare tutti e tre come un unico aumento permanente della quota.

L'annuncio manca anche di risultati sulla distribuzione. OpenAI non ha mostrato pubblicamente un miglioramento mediano, un miglioramento a percentile elevato o la quota di utenti che dovrebbe collocarsi vicino a uno degli estremi della fascia indicata.

Senza queste informazioni, il numero del 50% dice agli utenti cosa dovrebbero sperimentare alcuni carichi di lavoro, ma non quanto sia comune tale risultato. Il limite inferiore del 10% potrebbe essere più rilevante per un gruppo, mentre gli outlier precedentemente colpiti possono registrare un recupero pratico molto maggiore.

Per questo l'aggiornamento non dovrebbe essere liquidato come linguaggio di marketing. I bug divulgati sono fonti specifiche e plausibili di lavoro sprecato. Tuttavia, le prove pubbliche supportano l'affermazione che l'efficienza dovrebbe migliorare, non la conclusione che ogni utente di Codex disponga ora del 50% di capacità in più.

I limiti di utilizzo di Codex sono diventati un problema di affidabilità del prodotto

Il consumo della quota ora influisce sulla possibilità che un agente completi un'attività, rendendo il comportamento di misurazione parte dell'affidabilità del prodotto.

Un chatbot convenzionale completa la maggior parte delle interazioni in un'unica risposta. Un sistema agentico può ispezionare file, cercare repository, chiamare strumenti, attendere processi, delegare lavoro e riesaminare decisioni precedenti. Una richiesta dell'utente può quindi produrre molti cicli di modello sottostanti.

Ogni ciclo non necessario conta. Un nuovo tentativo ripetuto con uno strumento non si limita a ritardare una risposta. Può consumare un'allocazione condivisa, ampliare il contesto attivo e creare ulteriori opportunità per altri tentativi.

Questo rende un bug di arresto più grave di un difetto dell'interfaccia poco elegante. Se un obiettivo è già stato completato, ogni azione successiva rappresenta lavoro che l'utente non ha richiesto. Il sistema può apparire attivo mentre riduce silenziosamente la capacità disponibile per le attività successive.

Lo stesso problema si applica alla compattazione del contesto. La compattazione è necessaria durante le sessioni lunghe perché un agente non può trasferire una cronologia illimitata in ogni nuova richiesta al modello. Tuttavia, una strategia di compattazione fallita può elaborare ripetutamente informazioni che avrebbero dovuto essere scartate.

Le immagini sono particolarmente rilevanti perché possono occupare una parte sostanziale del contesto. Uno sviluppatore che utilizza screenshot per il debug dell'interfaccia potrebbe sperimentare una crescita del contesto più aggressiva rispetto a chi gestisce un piccolo repository esclusivamente testuale.

L'automazione aggiunge un ulteriore livello di rischio. Gli utenti spesso creano attività pianificate proprio perché non vogliono supervisionare ogni esecuzione. Se una pianificazione viene eseguita troppo frequentemente, i flussi di lavoro più colpiti sono anche quelli che con minore probabilità riceveranno un intervento umano immediato.

OpenAI aveva già documentato un incidente Codex più circoscritto nel giugno 2026. Il suo rapporto sullo stato affermava che alcuni account erano stati erroneamente soggetti a limitazioni di frequenza da parte dei sistemi di prevenzione di abusi e frodi. L'azienda ha descritto l'impatto come limitato e ha affermato di non aver osservato un degrado più ampio.

Quell'incidente e le correzioni più recenti non dovrebbero essere riuniti in un'unica causa. Il problema di giugno riguardava limitazioni di frequenza errate per determinati account. La nuova divulgazione descrive diversi modi in cui Codex poteva eseguire lavoro interno non necessario.

Insieme, tuttavia, spiegano perché le segnalazioni degli utenti sono state difficili da interpretare. Un'allocazione che cala rapidamente potrebbe derivare da un'attività lunga, da una scelta di modello costosa, dall'utilizzo condiviso degli agenti, da un contesto eccessivo, da un obiettivo fuori controllo o da una restrizione a livello di account.

Gli utenti non possono separare in modo affidabile queste possibilità con un unico indicatore percentuale. Possono controllare gli orari di reset e le ampie categorie di allocazione, ma non ricevono un registro completo per turno che associ ogni operazione interna al consumo della quota.

Il problema cresce man mano che Codex si estende oltre lo sviluppo software. OpenAI ha affermato a giugno che Codex contava più di 5 milioni di utenti attivi settimanali, oltre sei volte il suo pubblico dopo il lancio dell'app desktop a febbraio. L'azienda ha inoltre affermato che i knowledge worker rappresentavano circa il 20% degli utenti nel suo rapporto sull'adozione.

Quegli utenti chiedono sempre più spesso a Codex di creare report, analizzare dati, preparare presentazioni e automatizzare flussi di lavoro. Potrebbero avere meno esperienza nel diagnosticare un ciclo di agenti rispetto agli sviluppatori che ispezionano abitualmente i log dei processi.

Un comando del terminale non riuscito è visibile. Un worker di memoria in background che controlla migliaia di volte una condizione di arresto, invece, non lo è. Una maggiore adozione aumenta quindi l’importanza di spiegazioni sull’utilizzo che funzionino anche per chi non possiede una conoscenza approfondita dei sistemi.

I team affrontano un ulteriore problema di pianificazione. Un project manager non può stimare facilmente quante attività delegate possa supportare una quota settimanale quando il consumo dipende dalla struttura del contesto, dalla scelta del modello, dal comportamento degli strumenti e da un’orchestrazione nascosta.

Le correzioni riducono diverse fonti note di variabilità. Non eliminano la necessità di una misurazione prevedibile. Affinché Codex diventi un’infrastruttura affidabile, gli utenti devono fidarsi sia del lavoro che completa sia della contabilizzazione che lo accompagna.

Il vero avversario è il divario di verificabilità

OpenAI ha fornito un meccanismo credibile per il miglioramento, ma agli utenti mancano ancora i dati necessari per riprodurne il risultato principale.

Un issue aperto nel repository di Codex illustra il divario. Il suo autore chiede a OpenAI di definire cosa misuri l’espressione “l’utilizzo dura più a lungo” e di divulgare il carico di lavoro, i modelli, i livelli di effort e il periodo di osservazione alla base di tali affermazioni.

L’issue spiega inoltre come passaggi ripetuti dell’agente possano moltiplicare il consumo. Quando uno strumento restituisce il controllo al modello, Codex potrebbe rielaborare il contesto della conversazione prima di decidere cosa fare successivamente. Cicli aggiuntivi possono incrementare l’input in cache, il ragionamento e altre attività ponderate sulla quota.

Test della community citati nell’analisi dell’utilizzo hanno rilevato che il batching esplicito talvolta riduceva il consumo stimato. Questi esperimenti sono utili segnali ingegneristici, ma non rivelano il ledger privato degli abbonamenti di OpenAI.

I loro limiti contano. I campioni erano ridotti, le attività tendevano verso indagini con molta lettura e alcuni confronti coinvolgevano condizioni di contesto o ragionamento differenti. Anche il costo stimato equivalente alle API non coincide con un’effettiva variazione della quota Codex.

L’issue identifica le domande centrali ancora senza risposta. OpenAI non ha definito pubblicamente se il miglioramento misuri token grezzi, utilizzo interno ponderato, lavoro completato, durata a tempo reale o un altro indicatore proxy.

Non ha nemmeno fornito risultati per percentile. Una singola media nasconderebbe comunque i fallimenti nella coda lunga descritti nell’annuncio. Gli utenti devono sapere in che modo i carichi di lavoro tipici differiscano da quelli che in precedenza incappavano in compattazioni ripetute o in comportamenti di arresto fuori controllo.

Anche il confine del rollout rimane poco chiaro. Alcune correzioni possono avvenire interamente sui server di OpenAI, mentre altre potrebbero dipendere da un aggiornamento dell’app Codex o della riga di comando. La dichiarazione pubblica non ha indicato una versione minima del client per ciascuna modifica.

Questa incertezza non dimostra che i miglioramenti siano falsi. Mostra che l’affermazione non è verificabile in modo indipendente dai dati pubblici. I meccanismi divulgati sono coerenti con i comportamenti segnalati dagli utenti e ogni correzione dovrebbe logicamente ridurre il lavoro sprecato.

Tuttavia, la capacità effettiva non coincide con la qualità delle attività completate. Un’ottimizzazione che riduce i cicli del modello appare efficiente solo se Codex continua a produrre un risultato corretto e completo. Un benchmark utile deve misurare sia il consumo sia l’esito.

Anche la diversità delle attività conta. Ricerca nei repository, debug delle interfacce, generazione di codice, test di lunga durata, automazione del browser e lavoro multi-agente sollecitano parti diverse del sistema. Un singolo dato aggregato non può indicare agli utenti come sia cambiata ciascuna categoria.

Il reset crea inoltre un problema temporaneo di misurazione. Supponiamo che un utente confronti la propria percentuale settimanale immediatamente prima e dopo che OpenAI l’ha aggiornata. Ciò rivela il reset, non la quantità risparmiata grazie al comportamento dell’agente corretto.

Un test più pulito inizierebbe dopo il reset e ripeterebbe un’attività controllata. Utilizzerebbe lo stesso stato del repository, prompt, modello, livello di ragionamento, autorizzazioni, strumenti e versione del client. Confronterebbe quindi il lavoro completato e le variazioni effettive della quota.

Anche questo approccio presenta limiti, perché gli output del modello sono probabilistici. Sarebbero necessarie esecuzioni multiple e il loro ordine dovrebbe alternarsi per ridurre i bias ambientali. In genere, gli utenti non dispongono del tempo e della quota necessari per condurre uno studio simile.

OpenAI è in una posizione migliore per pubblicare queste prove. Può osservare le operazioni interne, identificare le coorti interessate e distinguere i token del modello dall’overhead di orchestrazione. Può inoltre confrontare i risultati su migliaia di carichi di lavoro di produzione senza esporre i contenuti dei clienti.

Finché ciò non accadrà, l’interpretazione più solida e difendibile è limitata. OpenAI ha corretto diversi comportamenti specifici che talvolta sprecavano una quota significativa. L’azienda prevede che utenti diversi ottengano tra il 10% e il 50% in più di utilizzo effettivo, ma il pubblico non può ancora riprodurre tale intervallo.

Cosa significano le correzioni per sviluppatori e team

Il beneficio pratico consiste in meno fallimenti invisibili, ma i team dovrebbero comunque considerare la dashboard dell’utilizzo uno strumento diagnostico limitato.

Gli sviluppatori che si affidano a Codex per lunghe attività sui repository hanno il motivo più evidente per interessarsene. Un obiettivo che continua dopo il completamento può sprecare il budget residuo necessario per test, revisione o una correzione successiva.

Il cambiamento può migliorare la continuità del flusso di lavoro anche quando i limiti nominali restano fissi. Una parte maggiore della quota dovrebbe essere destinata al lavoro richiesto anziché a controlli di arresto ripetuti, immagini obsolete, strumenti non funzionanti o modelli di supporto inattesi.

Lo sviluppo con molte immagini potrebbe registrare un vantaggio diretto dalla correzione della compattazione. Esempi comuni includono la revisione di screenshot delle interfacce, il confronto di pagine renderizzate, l’esame di diagrammi o il debug di test di accettazione basati sul browser.

Gli utenti non dovrebbero presumere che ogni attività visiva diventi più economica del 10%. OpenAI ha collegato tale stima alle persone che fanno ampio uso di immagini e non ha pubblicato la definizione del campione. La lunghezza del contesto e la struttura dell’attività possono ancora modificare il risultato.

I responsabili dell’automazione dovrebbero esaminare attentamente i job pianificati. OpenAI afferma di aver corretto pianificazioni personalizzate che potevano essere eseguite troppo frequentemente, ma l’utilizzo storico non rivela automaticamente quali esecuzioni fossero indesiderate.

Un team può confrontare i timestamp dell’automazione con la pianificazione prevista. Esecuzioni passate inattese potrebbero spiegare un consumo insolito, anche se non possono dimostrare che il bug appena divulgato abbia causato ogni discrepanza.

I flussi di lavoro guidati da obiettivi meritano un’attenzione analoga. I team dovrebbero definire una condizione di completamento osservabile e verificare che l’output finale la soddisfi. La correzione dovrebbe ridurre l’esecuzione continuativa, ma criteri di accettazione chiari restano utili.

Gli strumenti non funzionanti sono un altro segnale d’allarme. Se un servizio esterno non è disponibile o un comando non può riuscire, i tentativi ripetuti possono diventare costosi. Un flusso di lavoro ben progettato dovrebbe stabilire limiti ai tentativi e preservare informazioni sufficienti per un tentativo successivo.

Anche gli utenti dei subagent dovrebbero verificare quali modelli partecipano al lavoro delegato, quando tale informazione è disponibile. La correzione di OpenAI dovrebbe impedire ai modelli più piccoli di selezionare helper più capaci senza richiesta, migliorando l’allineamento tra l’intento dell’utente e il costo di esecuzione.

Per le organizzazioni, questi cambiamenti rafforzano la necessità di un archivio ricercabile di prompt, decisioni, log e output finali. Una knowledge base ingegneristica locale può aiutare i team a collegare un risultato inatteso ai file e alle istruzioni che lo circondano.

Tale archivio non sostituisce la telemetria sull’utilizzo di OpenAI. Fornisce a un team prove proprie sulla portata dell’attività, sui guasti degli strumenti e sul completamento. Quando una quota cala in modo inatteso, questi dettagli rendono una segnalazione al supporto più utile.

I team dovrebbero evitare di confrontare semplici conteggi di prompt. Una richiesta Codex può rispondere dal contesto esistente, mentre un’altra avvia test, cerca file, attende processi e delega lavoro. Le unità di attività completate offrono una misura operativa più utile.

Una metrica interna pratica potrebbe tracciare modifiche accettate, documenti revisionati o analisi completate per finestra di quota. Dovrebbe inoltre registrare le esecuzioni non riuscite, poiché un agente che consuma meno ma produce lavoro inutilizzabile non ha migliorato la produttività.

Gli sviluppatori dovrebbero separare i reset temporanei dall’efficienza ricorrente. Una dashboard aggiornata crea immediatamente margine, ma il valore duraturo deriva dalla rapidità con cui attività equivalenti consumano quel margine in seguito.

La stessa cautela si applica ai riepiloghi di Google News e ai post sui social. Sono strumenti utili di scoperta, ma le decisioni operative dovrebbero seguire la dichiarazione sottostante e le prove dirette sul prodotto. Un titolo non può rivelare se un particolare flusso di lavoro abbia interessato un percorso di codice corretto.

Il materiale di assistenza pubblicato da OpenAI indirizza gli utenti alla dashboard dell’utilizzo e al comando /status per le informazioni sull’account. Questi strumenti mostrano un’ampia disponibilità, ma non forniscono una piena attribuzione per operazione.

Se l’utilizzo appare ancora incoerente, gli utenti dovrebbero registrare il modello, il livello di effort, la versione del client, l’ora di avvio dell’attività, gli strumenti, le caratteristiche del contesto e la variazione della quota osservata. Questo pacchetto offre a OpenAI una strada più chiara per distinguere il consumo previsto da un altro difetto.

Cosa osservare dopo il picco di Google News

Il prossimo test sarà stabilire se OpenAI trasformerà un aggiornamento di riparazione una tantum in un’efficienza Codex costantemente misurabile.

Il primo segnale è la stabilità dell’utilizzo dopo che l’effetto del reset sarà scomparso. Nell’arco di diverse finestre di quota, attività comparabili dovrebbero consumare meno o almeno diventare più prevedibili. Se continuano le segnalazioni di cali inspiegati, le correzioni attuali hanno affrontato soltanto una parte del problema.

Questa osservazione deve tenere conto delle modifiche al carico di lavoro. Un utente che cambia modello, abilita più ragionamento, aggiunge strumenti o amplia il contesto del repository non può effettuare un confronto pulito tra prima e dopo.

Il secondo segnale è una migliore attribuzione. OpenAI espone già informazioni generali sull’utilizzo, ma gli utenti necessitano di un collegamento più chiaro tra le variazioni della quota e i turni del modello, i cicli degli strumenti, le automazioni, i subagent e il lavoro in background.

Reportistica per attività renderebbe più semplice identificare regressioni future. Ridurrebbe inoltre le speculazioni quando una percentuale visibile cambia più rapidamente di quanto un utente si aspettasse.

Il terzo segnale è una metodologia pubblicata per l’intervallo dal 10% al 50%. OpenAI potrebbe definire la metrica, descrivere i carichi di lavoro testati, indicare quali versioni del client contano e mostrare la mediana insieme agli esiti nella coda lunga.

Tale divulgazione rafforzerebbe l’affermazione dell’azienda anche se alcune categorie ottenessero meno del massimo indicato nel titolo. Un miglioramento trasparente del 10% su un carico di lavoro definito è più utile di un numero maggiore che gli utenti non possono collegare al proprio lavoro.

Il comportamento dei concorrenti fornirà un contesto di supporto. Altri fornitori di agenti affrontano la stessa tensione fondamentale tra lunghe esecuzioni autonome e quote prevedibili. Una contabilizzazione dell’utilizzo più chiara può diventare un vantaggio di prodotto man mano che gli agenti di coding gestiscono progetti più grandi.

Per ora, gli sviluppatori dovrebbero considerare l’aggiornamento una manutenzione significativa con un problema di misurazione irrisolto. OpenAI ha indicato diversi difetti concreti, descritto un comportamento grave nei casi anomali, resettato gli utenti paganti e prevede che la quota esistente supporti più lavoro.

L’incertezza rimanente riguarda entità, distribuzione e durata. Google News ha dato ampia visibilità al limite massimo del 50%, ma solo risultati ripetuti dopo il reset possono mostrare dove si collochino effettivamente gli utenti tipici.

Osservate le prossime attività comparabili, registrate ciò che fa Codex e separate il lavoro completato dal movimento della dashboard. Se la stessa quota ora produce più output accettato, le correzioni stanno funzionando dove conta. Se il consumo inspiegato persiste, OpenAI avrà bisogno di un altro ciclo di ingegnerizzazione e di prove molto più chiare.