Sono combattuto tra Claude e Codex

Sono combattuto tra Claude e Codex perché ciascuna piattaforma prevale in una parte diversa del mio lavoro. Codex mi offre più tempo utile, un’interfaccia più fluida, risposte più chiare e frontend migliori. Claude, però, trasforma molto più in fretta i miei piani multi-agente in modifiche complete. Quando una feature coinvolge più sistemi, per me questo conta di più.

Parte del lavoro	Claude	Codex
Visione dell’architettura	La mia prima scelta	Valido, ma perde prima di vista l’obiettivo
Orchestrazione delle grandi feature	Di solito arriva prima alla fine	Spesso si prolunga molto di più
Implementazione frontend	Affidabile, ma spesso convenzionale	Più coerente, con spaziatura e scelte visive migliori
Comunicazione scritta	Fable comprende bene il sistema	Sol di solito lo spiega più chiaramente
Utilizzo incluso	Fable si ferma a metà della quota settimanale	I reset fanno sembrare la quota molto più ampia
Interruzioni di sicurezza	Più falsi positivi nel mio lavoro	Non perfetto, ma tarato meglio sui miei compiti
Passaggio tra telefono e desktop	Completo, ma diviso tra diverse modalità	Più coerente nell’uso quotidiano

Il confronto spiega perché resto combattuto. Codex vince in più aspetti dell’esperienza, ma Claude prevale sulle grandi feature che mi portano via più ore. Nel mio lavoro, nessuno dei due modelli è nettamente più intelligente. Sono i sistemi che li circondano a determinare quale dei due apro.

Perché pago entrambi? Ognuno è migliore in qualcosa che mi serve

Pago entrambi perché Claude si adatta al mio modo di lavorare sulle grandi feature, mentre Codex è il prodotto che preferisco per molti compiti più piccoli. Rinunciare a uno dei due significherebbe perdere qualcosa che uso ogni settimana. È una risposta fastidiosa, visto che sono due delle mie maggiori spese software ricorrenti.

Uso assistenti di coding fin dai primi tempi di GitHub Copilot, compreso il periodo in cui lavorare sul codice con ChatGPT significava copiare frammenti da una chat nel browser. Per anni, la mia configurazione stabile è stata Claude Max 20x per il coding e un piano ChatGPT più economico per la ricerca. Tendo a documentarmi prima di prendere decisioni tecniche o personali e, per questo lavoro, l’esperienza di ricerca di OpenAI mi è sempre risultata più adatta.

GPT-5.6 ha cambiato l’equilibrio. Nel mio lavoro Sol è più o meno capace quanto Fable 5, così sono passato al piano Pro 20x di OpenAI e ho mantenuto Claude Max 20x. [4] [9] Uso questi strumenti così tanto che a volte mi è servito un secondo abbonamento Claude Max. Se la quota di un piano si esaurisce più in fretta o mi ferma prima, cambia la quantità di lavoro che riesco a completare in quella giornata.

In pratica, la quota di OpenAI spesso mi sembra più generosa. Tra il 26 agosto e il 1° settembre 2026 ho visto arrivare altri tre reset globali, oltre alla serie di reset di cui ho scritto ad agosto. A mio avviso, quei festeggiamenti servono anche da marketing per un modello capace di consumare rapidamente la quota. L’effetto su di me è più semplice: i reset hanno dato al mio account altro margine e rendono difficile abbandonare Codex.

Cosa fa meglio Codex? Frontend e uso quotidiano

Nel lavoro quotidiano, Codex vince negli aspetti che noto subito: design del frontend al primo tentativo, spiegazioni scritte, controllo da remoto e gestione delle interruzioni dovute ai limiti. È più facile conviverci passando da un lavoro circoscritto all’altro, anche se Sol non scrive sempre codice backend migliore.

Il divario più evidente nella qualità riguarda il frontend. Al primo tentativo, GPT-5.6 tende a produrre layout con spaziatura, allineamento e gerarchia visiva migliori. La stessa OpenAI dichiara che il modello migliora l’estetica dei frontend e la capacità di giudicare il design. [1] Questo conferma la capacità, ma non confronta Sol con Fable 5. Il confronto viene dalla mia esperienza: Codex ha maggiori probabilità di creare un design adatto al prodotto esistente, mentre Claude restituisce più spesso un template già visto, a meno che io non descriva in dettaglio la direzione visiva.

Trovo anche Sol più facile da leggere. Di solito spiega una decisione con parole comuni, anche quando il lavoro sottostante è tecnico. Fable mi dà una visione architetturale migliore, ma la sua prosa può comunque diventare più difficile da seguire. La differenza conta perché l’agente principale dedica gran parte del tempo a discutere compromessi e comunicare i progressi, non soltanto a scrivere codice.

Questa facilità si ritrova anche quando mi allontano dalla scrivania. OpenAI documenta un accesso remoto che permette di continuare dal telefono una conversazione Codex in esecuzione su un Mac o un computer Windows collegato. Dal telefono posso guidare il lavoro attivo e controllare approvazioni, diff e output del terminale. [7] Codex offre inoltre compiti isolati nel cloud, anche se io uso soprattutto il collegamento al mio computer. [21]

Claude copre le stesse possibilità attraverso diverse modalità. Permette di continuare dal telefono le sessioni locali, avviare lavoro sul desktop tramite Dispatch ed eseguire sessioni nel cloud anche dopo lo spegnimento del computer. [17] [18] [22] Entrambe le piattaforme coprono gli usi principali, ma con Codex trovo più facile orientarmi. Claude distribuisce lavori simili tra Remote Control, Dispatch, sessioni locali e sessioni cloud.

I limiti di utilizzo rendono la differenza ancora più netta. La documentazione attuale di OpenAI dice che i messaggi locali e i compiti cloud su Pro 20x condividono una finestra di cinque ore e che possono applicarsi anche limiti settimanali, quindi il piano non è soltanto settimanale. Dice anche che un turno già attivo può proseguire dopo il raggiungimento del limite dell’account, nel rispetto dei controlli sul corretto utilizzo. [4] Claude può ora attendere e riprendere automaticamente un compito interrotto dopo il reset della sessione. [20] Nel mio lavoro, però, il limite continua a sembrare un arresto netto proprio nel momento sbagliato. Per me le regole precise del reset contano meno del fatto che la modifica di oggi raggiunga un punto in cui posso fermarmi senza rischi.

Perché Claude finisce prima? Il manager non perde il filo

Claude completa prima le mie grandi feature perché la sua orchestrazione si adatta al modo in cui divido il lavoro software. Un modello capace conserva il piano, prende le decisioni e comunica con me, mentre agenti separati si occupano di ricerca, implementazione, test e audit. Nei miei progetti, Claude mantiene l’agente principale concentrato sul coordinamento in modo più affidabile.

Anthropic chiama questo schema generale orchestrator-workers: un modello centrale scompone un compito, lo delega e riunisce i risultati. OpenAI documenta lo stesso schema di base come orchestrazione con un manager. [14] [15] Il nome conta meno della separazione dei ruoli: il manager conserva l’obiettivo e prende le decisioni, mentre gli agenti operativi ricevono compiti circoscritti e restituiscono prove.

I workflow dinamici di Claude Code rendono questa divisione particolarmente esplicita. Claude scrive uno script di orchestrazione, avvia agenti in parallelo e lascia al runtime la gestione delle diramazioni e dei risultati intermedi. Anthropic dichiara che una singola esecuzione può avviare nel tempo decine o centinaia di agenti, con un massimo di 16 attivi contemporaneamente quando il computer dispone di abbastanza CPU. [11] [12] Non me ne servono centinaia, ma per me conta che la conversazione principale non debba assorbire ogni file letto, risultato di un comando o deviazione durante il debug.

Nella mia configurazione, Fable 5 è l’agente principale. Definisce con me l’architettura e scrive il piano, poi gli agenti Opus implementano parti ben delimitate mentre altri agenti eseguono test e revisioni. Fable decide quali finding meritano un intervento e mi consulta quando una modifica cambierebbe il piano. Descrivo i dettagli dell’implementazione nel mio workflow con piano iniziale per Opus 5; qui conta che Fable resti responsabile dell’intero risultato.

responsabile

• Fable 5 conserva obiettivo, piano, decisioni e conversazione con l’utente

delega compiti definiti

agenti operativi

• agenti di ricerca esaminano il repository e le questioni aperte
• agenti Opus implementano parti circoscritte
• agenti di test e audit restituiscono prove e finding

restituisce prove

decisione

• revisione del responsabile accetta, rifiuta, reindirizza o consulta l’utente
• feature completata piano soddisfatto e controlli superati

In Claude Code, Fable e Opus supportano una finestra di contesto da un milione di token, ma il vantaggio maggiore è che i dettagli degli agenti operativi restano fuori dalla conversazione del manager. [13] Anche una finestra ampia si riempie se contiene ogni file letto, log degli agenti e risultato dei test. I workflow dinamici tengono separati questi dettagli e lasciano al manager un contesto ancora utile.

OpenAI descrive la stessa separazione per Codex: il thread principale dovrebbe conservare requisiti e decisioni, mentre gli agenti operativi gestiscono esplorazione, test e log. [5] Per questo pensavo di poter applicare senza difficoltà anche lì il mio workflow. Nelle mie esecuzioni, invece, l’agente principale di Codex rispetta il ruolo esclusivo di manager con meno costanza rispetto a Claude.

Perché Sol, pur essendo più veloce, finisce dopo? Crea più lavoro

Sol può generare testo più in fretta e impiegare comunque più tempo per finire, perché la velocità di output misura solo una parte di un’esecuzione. La maggior parte del tempo serve a scegliere cosa fare, usare strumenti, riaprire questioni e coordinare altri agenti. La generazione più rapida non aiuta se l’agente crea lavoro extra o rimette in discussione decisioni già prese.

Il 1° settembre 2026, Artificial Analysis ha misurato GPT-5.6 Sol a 77,1 token di output al secondo e Fable 5 a 66,9 nelle configurazioni confrontate con effort massimo. [3] Il vantaggio di circa il 15% nella velocità di generazione corrisponde alla sensazione che ho quando guardo Sol rispondere. Non coincide con i miei risultati complessivi, perché Codex spesso crea altro lavoro dopo che l’implementazione originale è già quasi terminata.

L’ambito extra si mangia il vantaggio di velocità di Sol

Gran parte del tempo aggiuntivo deriva dall’ingegneria superflua. Devo specificare molto chiaramente che Codex deve conservare l’architettura esistente, segnalare i finding non collegati senza correggerli e fermarsi quando i criteri di accettazione sono soddisfatti. Altrimenti Sol può aggiungere strati difensivi, nuovi helper o un intero sottosistema per un problema che richiedeva una sola modifica mirata. Ho misurato la stessa tendenza durante gli audit: Sol ha trovato molti più possibili problemi di Fable, ma la maggior parte non ha superato il triage.

Il coordinamento aggiunge un altro ritardo. Nelle esecuzioni Codex Ultra che ho utilizzato, l’agente principale faticava a limitarsi al ruolo di manager. Delegava il lavoro, ma poi continuava a ispezionare file, apportare modifiche o riaprire decisioni mentre gli altri agenti svolgevano i propri compiti. OpenAI descrive Ultra come la modalità con il massimo ragionamento e la delega automatica, e afferma che il thread principale raccoglie i risultati degli agenti operativi. [5] [19] Non promette che il thread principale non partecipi all’implementazione. I miei tentativi di imporre quel confine hanno ridotto il problema senza eliminarlo.

Più contesto e meno effort non interrompono il ciclo

Le esecuzioni lunghe aumentano la pressione sul contesto, ma ampliare la finestra non ha risolto il rallentamento. Inizialmente, lo stato di Codex mostrava 272.000 token, quindi ho impostato model_context_window a un milione nella configurazione. OpenAI documenta questa opzione e Sol supporta fino a 1,05 milioni di token. [6] [2] La cifra di 272.000 descrive ciò che mostrava la mia configurazione, non un valore predefinito universale stabilito da OpenAI. La finestra più grande aiuta, ma Codex la riempie comunque in fretta durante una lunga esecuzione multi-agente. Quando inizia la compattazione, ho meno fiducia che un vincolo stabilito all’inizio venga ancora rispettato allo stesso modo sei ore dopo.

Inoltre, il contesto lungo ha un costo. Nelle API OpenAI, per i prompt oltre 272.000 token l’intera richiesta viene fatturata al doppio della tariffa di input e a 1,5 volte quella di output. [2] OpenAI non afferma che la quota ChatGPT Pro applichi esattamente gli stessi moltiplicatori, quindi non uso quella formula per calcolare il consumo del mio abbonamento. La tariffazione mostra comunque perché allargare una finestra non equivale a rendere efficiente un lavoro lungo.

Ridurre l’impostazione di effort di Sol non ha risolto il problema. Codex diventa un po’ più veloce, ma il tempo risparmiato è modesto rispetto al calo nella qualità della pianificazione e della revisione. Neppure un goal risolve il problema. OpenAI descrive i goal come un modo per continuare il lavoro tra più turni fino a una condizione di arresto verificabile, proprio ciò che cerco. [8] Nelle mie esecuzioni lunghe, il goal mantiene Codex attivo senza aiutarlo a finire prima.

Cosa rende Claude più difficile da usare? Limiti e interruzioni

Il vantaggio di Claude nell’orchestrazione comporta limiti più stretti e più interruzioni di sicurezza dovute a falsi positivi. Il suo workflow per le grandi feature mi è più adatto, ma devo dedicare più tempo a controllare quale modello posso ancora usare e a ripartire quando un controllo di sicurezza interrompe un lavoro normale.

Il limite di Fable è la frustrazione più diretta. Pago Max 20x, ma Fable può usare soltanto metà della quota settimanale inclusa. [10] Capisco perché un fornitore possa limitare più severamente il proprio modello più costoso. Questo non rende l’interruzione meno problematica per il mio lavoro. Una grande feature non diventa meno importante quando si esaurisce quella quota più piccola.

Le interruzioni dovute alla sicurezza sono peggiori, perché spezzano la concentrazione senza far avanzare il lavoro. Anthropic ha riconosciuto che Fable 5 segnalava richieste innocue durante normali attività di coding e debug dopo la release di giugno 2026 e il ritiro temporaneo. [16] Oggi ne vedo meno rispetto all’inizio, ma questi controlli continuano ad attivarsi su lavori innocui più spesso di quanto mi aspetti.

Anche OpenAI avverte che le protezioni di GPT-5.6 possono intervenire su richieste legittime. [1] Codex non è privo di falsi positivi. Nei miei progetti, però, i suoi sistemi di classificazione sono stati più precisi: di solito capisco perché una richiesta a duplice uso ha causato una pausa, mentre durante il normale lavoro di sviluppo una pausa scatta più raramente. È la mia esperienza, non un confronto pubblicato sui tassi di errore dei filtri.

Questi problemi non pesano più del vantaggio nell’orchestrazione. Spiegano però perché continuo a considerare Codex anche dopo che Claude completa per primo un’altra grande implementazione.

Meglio Claude o Codex? Dipende dalle dimensioni del lavoro

Scelgo Claude quando la feature richiede ricerca nel repository, una decisione architetturale, diversi agenti di implementazione e un audit indipendente. Scelgo Codex per modifiche circoscritte, lavoro frontend e sessioni in cui apprezzo l’interfaccia più chiara e il maggiore margine di utilizzo che ottengo in pratica. Per ricerche estese, parto ancora da ChatGPT anziché da uno dei due harness di coding.

Questa divisione dipende dal workflow, non dalla convinzione che Fable 5 sia più intelligente di Sol. Se assegnassi a entrambi un unico compito piccolo e chiaro, mi fiderei di tutti e due per produrre codice valido. La differenza emerge quando una feature deve essere divisa in diversi compiti dipendenti tra loro e una sola conversazione deve conservare le ragioni alla base di ciascuno.

Codex diventerebbe la mia scelta predefinita se il suo manager restasse fuori dall’implementazione, controllasse meglio l’ambito, usasse il contesto lungo con maggiore efficienza e portasse una lunga esecuzione a una conclusione verificata. Claude sarebbe più facile da scegliere come unico abbonamento se la quota inclusa di Fable fosse meno restrittiva e il normale lavoro di coding attivasse meno controlli di sicurezza.

Per ora continuo a pagare entrambi. Avvio una grande feature con Claude perché la sua orchestrazione porta il lavoro allo stato finale che ho richiesto. Codex è invece il prodotto che continuo a voler usare perché tutto il resto è più semplice. Al momento, nessuna delle due piattaforme riunisce in un solo workflow l’orchestrazione di Claude e l’esperienza d’uso di Codex.