Aggiornamento — estate 2026: per me ha smesso di funzionare
Entro l’estate 2026 questo workflow aveva smesso di funzionare in modo affidabile per me. Nel mio account era scomparso il contatore della finestra di 5 ore, mentre restava visibile il limite settimanale. In pratica veniva meno la finestra di reset più breve attorno alla quale avevo costruito questo metodo.
Il cambiamento più importante riguardava i task lunghi. Quando un lavoro consistente di Codex arrivava alla fine del mio limite settimanale, ho visto l’esecuzione fermarsi invece di continuare fino alla conclusione. Di conseguenza, la mia vecchia regola “avvia il task più pesante negli ultimi 3–5%” ha perso gran parte del suo valore: non potevo più contare sul fatto che un task già avviato superasse la fine del limite settimanale.
Voglio però separare con precisione ciò che ho osservato da una regola ufficiale del prodotto. Posso confermare ciò che è successo nel mio account e nel mio workflow, ma non posso dimostrare che OpenAI abbia eliminato definitivamente la finestra di 5 ore per tutti. La documentazione attuale di Codex continua infatti a citare sia finestre di 5 ore sia settimanali e afferma che un turno attivo può talvolta proseguire dopo il raggiungimento di un limite, nel rispetto dei limiti di fair use. Tratto quindi il cambiamento dell’estate 2026 come un comportamento reale che ho sperimentato, non come una regola universale per ogni account.
Il resto dell’articolo rimane come descrizione del workflow che funzionava per me prima di quel cambiamento. L’aggiornamento qui sopra sostituisce le raccomandazioni al presente del testo originale.
Quando il contatore di utilizzo di Codex del mio piano ChatGPT Plus scende a circa il 3–5%, non spendo più il residuo in prompt piccoli. Faccio l’opposto: avvio il più grande task di ingegneria che ho già preparato.
Nel mio caso significa di solito una migrazione completa a TypeScript, pulizia ESLint su tutto il repository, una deep bug review di una codebase oppure un grande refactoring strutturale. Spesso tengo pronti più progetti, così l’ultima parte di utilizzo può andare al lavoro pesante che è davvero pronto a partire.
Il motivo è un’osservazione ripetuta. Più di una volta ho avviato un lavoro importante vicino alla fine del limite visibile e poi ho visto Codex continuare a lavorare anche quando quel limite sembrava esaurito. A volte il task è andato avanti abbastanza da terminare. È successo abbastanza spesso da cambiare il mio modo di pianificare, ma non abbastanza da trasformarlo in una garanzia del prodotto.
L’osservazione che ha cambiato il mio workflow
Vicino a un limite di utilizzo l’istinto naturale è diventare conservativi: usare l’ultimo margine per richieste piccole, perché un task grande potrebbe essere interrotto. Oggi tratto quell’ultimo 3–5% in modo diverso. Per me è una finestra di lancio.
La domanda utile non è più “quanti prompt piccoli riesco ancora a fare?”, ma “qual è il task già pronto più prezioso che posso avviare finché ho ancora utilizzo incluso?”
Questo funziona solo perché il progetto è già pronto e il task è definito chiaramente. Non uso gli ultimi punti percentuali per scoprire cosa fare; li uso per iniziare l’esecuzione.
Una precisazione importante su nome e limiti
In origine chiamavo questa situazione “Codex Plus”, ma è una scorciatoia, non il nome ufficiale del prodotto. OpenAI descrive Codex come incluso in ChatGPT Plus. Vale la pena correggerlo per non far sembrare Codex Plus un piano o prodotto separato.
L’attuale documentazione OpenAI sull’utilizzo di Codex spiega inoltre che il consumo varia in base alle dimensioni e alla complessità del lavoro, al modello e a dove viene eseguito il task. Sono documentate finestre di utilizzo che includono una finestra di 5 ore e una settimanale. Quindi con “3–5%” intendo la percentuale residua mostrata dall’interfaccia di utilizzo, non il 3–5% del tempo reale, dei token o di una quantità garantita di lavoro.
Gli utenti Plus idonei possono anche estendere l’uso di Codex con crediti dopo aver esaurito la quota inclusa. Questo non invalida il workflow; ne chiarisce soltanto il confine. Sto descrivendo come distribuisco il mio utilizzo incluso, non un modo per aggirare una quota.
Cosa avvio nell’ultimo 3–5%
I task che tendo a riservare a questo momento sono operazioni di ingegneria ampie:
- migrazioni complete a TypeScript
- pulizia ESLint su tutto il repository
- deep bug review su codebase grandi
- grandi refactoring strutturali
Preferisco avviare uno di questi lavori come blocco sostanziale anziché distribuire l’utilizzo residuo su una sequenza di richieste a basso valore. Per task del genere, un repository preparato e un obiettivo chiaro contano più di una formulazione particolarmente ingegnosa del prompt.
Avere diversi progetti pronti aiuta per lo stesso motivo. Se un repository richiede ancora decisioni o setup, non spreco l’ultima finestra per prepararlo; posso iniziare su un altro progetto già pronto.
La preparazione è il vero vincolo
Il trucco non è “aspetta il 3% e poi incolla un prompt enorme”. Se il task è ambiguo, un budget limitato può sparire in esplorazione, chiarimenti o lavoro nella direzione sbagliata. Il mio pattern è utile solo quando il progetto è execution-ready e il task è ben delimitato.
Per chi vuole provare un workflow simile, un buon preflight consiste nel rendere espliciti scope, cosa deve cambiare e cosa no, i vincoli, come verrà validato il risultato e quale output ci si aspetta dall’agente. Sono salvaguardie di ingegneria generali, non prove che un particolare formato di prompt sblocchi più utilizzo.
Questa preparazione rende anche più facile riprendere un task grande se il limite lo interrompe davvero. Una migrazione o review parziale è molto più semplice da continuare quando scope e criteri di validazione erano chiari fin dall’inizio.
Cosa posso confermare — e cosa no
Quello che posso confermare dal mio uso è ristretto: in più occasioni un task già avviato ha continuato a fare progressi dopo che il limite visibile sembrava esaurito e, a volte, si è completato.
Non posso invece confermare il meccanismo. Non posso sostenere che OpenAI dia a ogni task in esecuzione un periodo di grazia nascosto, che l’ultimo 3–5% basti a completare qualunque lavoro grande, che il comportamento sia stabile o che rappresenti un modo per bypassare il limite. La documentazione OpenAI non promette nulla di tutto questo.
La distinzione conta. Pianifico attorno a un comportamento che ho osservato più volte, ma non ne dipendo. Se il task si ferma al limite, non è la prova che qualcosa si sia rotto. La strategia ha comunque raggiunto lo scopo se ho speso l’uso incluso residuo su qualcosa di più importante di qualche piccolo prompt.
Un task finito non è un task verificato
Più il task cresce, più diventa importante una seconda distinzione: completato non significa corretto. Una migrazione TypeScript che builda non prova il corretto comportamento runtime. Un ESLint pulito non prova la correttezza della business logic. Una bug review che segnala un pattern sospetto non ha necessariamente trovato un bug reale. Anche un refactoring con test verdi è affidabile solo quanto i test e i check che lo coprono.
Questo workflow cambia quando avvio il lavoro. Non abbassa lo standard di validazione. I grandi cambiamenti agentic richiedono comunque i controlli adatti al rischio: diff review, typecheck, test, build, runtime check o verifica specifica del progetto.
Quando questo pattern è poco adatto
Non considero ogni task grande adatto alla fine del limite. L’approccio è più debole quando il lavoro è ancora poco chiaro, richiede frequenti decisioni di prodotto, comporta operazioni distruttive o sensibili in produzione, oppure lascia il repository in uno stato rischioso se interrotto a metà.
In questi casi un task più piccolo e ben delimitato o una nuova finestra di utilizzo è in genere una scelta di ingegneria migliore. L’obiettivo non è rendere drammatico l’ultimo prompt, ma usare una risorsa inclusa scarsa per un lavoro che possa produrre progressi utili in sicurezza.
La mia regola oggi
Quando l’utilizzo Codex incluso in ChatGPT Plus scende a circa il 3–5%, smetto di ottimizzare il numero di prompt rimasti. Guardo i progetti preparati e avvio il task di ingegneria più pesante, chiaramente delimitato e davvero utile.
Se Codex continua a lavorare dopo che il contatore visibile arriva a zero, lo tratto come un comportamento utile che ho osservato, non come un diritto. Se si ferma, non mi sorprendo. Non ho trovato un modo per aggirare il limite. Ho trovato un modo migliore per decidere cosa avviare prima di raggiungerlo.