La context window è il campo di battaglia degli AI coding agent
La riduzione silenziosa del contesto di Codex da 372k a 272k non è un incidente: è la spia di due architetture economiche divergenti.
OpenAI ha fatto merge di una pull request su Codex che riduce la context window di GPT 5.6 Sol da 372.000 a 272.000 token: un taglio di 100.000 token, più di un quarto della capacità precedente. Non un bug. Non un errore di configurazione.
La PR #33972 si chiama "Backport refreshed bundled model metadata" e modifica 118 righe (+64, −54) in un file JSON di metadata modello: una scelta deliberata, silenziosa, annegata in un hotfix.
La spiegazione era arrivata cinque giorni prima del merge: il 13 luglio Tibo, che lavora su Codex e ChatGPT presso OpenAI, ha pubblicato un lungo tweet in risposta alle prime reazioni della community. Il thread completo è reperibile al link ufficiale. Ed è più interessante della riduzione stessa.
(1) Non è corretto: non è dovuto a un sovrapprezzo 2X oltre i 272k di contesto. Non facciamo pagare di più per contesti più lunghi sull'abbonamento a GPT 5.6 Sol, perché controlliamo tutte le impostazioni. È dovuto a qualcos'altro, che proverò a spiegare qui sotto. La lunghezza complessiva della traiettoria, cioè la somma di tutte le context window attraverso le compattazioni, cambia poco in base allo sforzo di ragionamento. Allo stesso modo, la qualità complessiva dell'output è simile per lunghezze di contesto superiori a 272k. I benefici di contesti più lunghi sono principalmente velocità complessiva (perché non aspetti la compattazione), capacità di gestire input enormi e potenzialmente costi inferiori se il sistema è ben calibrato e centri la cache perfettamente. La ragione reale è quella che vedete rappresentata nel grafico qui sotto, cioè la differenza tra la linea arancione e la linea blu. È causata dal costo complessivo delle letture dalla cache che cresce con la dimensione del contesto spostato avanti e indietro tra le chiamate agli strumenti. Il punto di equilibrio in termini di costo non è quindi necessariamente usare la massima lunghezza di contesto possibile. Ciò su cui stiamo lavorando è calibrare il sistema in modo diverso per poter tornare più in alto senza che questo comporti un addebito maggiore per l'utilizzo.
A corredo, un grafico che mostra due curve di costo cumulativo: una per contesto a 300k token, una per 200k. La prima cresce più rapidamente, con un delta che si allarga a ogni turno di conversazione. Il motivo sono i prefix cache reads: più contesto hai, più token devi ricaricare dalla cache a ogni tool call, e il costo cresce in modo non lineare.
Il problema non è il modello: è l'architettura
Qui il punto non è se GPT 5.6 sia più o meno capace con 272k token. Tibo stesso dice che "la qualità dell'output è simile sopra i 272k" e che "i benefici di contesti più alti sono soprattutto velocità e capacità di gestire input enormi". Il punto è che OpenAI sta ottimizzando i propri costi di inferenza lato server, e lo sta facendo a scapito dell'esperienza dello sviluppatore.
La questione è tecnica e ha poco a che fare con il modello in sé. Riguarda il modo in cui un agente di coding consuma contesto. Ogni tool call (leggere un file, eseguire un comando, cercare nel codice) aggiunge output al transcript.
Ogni volta che l'agente chiama il modello successivo, l'intero transcript (o una sua porzione compattata) viene reinviato. Se il contesto è grande, il prefix caching deve recuperare una porzione più ampia di token già computati: un'operazione che ha un costo computazionale reale, non azzerabile.
La differenza di Anthropic non è Opus: sono 1 milione di token
Questo è il punto che troppi analisti continuano a perdere. Si discute se Claude Opus sia migliore di GPT 5.6 sui benchmark, se ragioni meglio, se scriva codice più pulito. Ma la vera differenza competitiva di Anthropic in questo momento non è la qualità del modello: è la capacità di offrire 1 milione di token di contesto gestibile senza compattazioni premature. Come documentato nella guida tecnica di Anthropic sulle context window, Claude Opus 4.8 e Sonnet 5 gestiscono nativamente 1M token con compattazione lato server opzionale, non forzata.
La differenza è enorme. Con Codex a 272k, la compattazione automatica scatta attorno all'80% di utilizzo, quindi il contesto realmente usabile è circa 217.000 token. Con Claude, lo stesso sviluppatore arriva a 300-400k token prima di doversi preoccupare, e sessioni fino a 600-700k sono riportate come utilizzabili.
Non è questione di potenza bruta: è questione di quanta architettura software puoi tenere in testa all'agente prima che inizi a dimenticare. È la differenza tra dover spezzettare un task complesso in 5 sotto-sessioni con piani scritti a mano e poterlo affrontare in un unico flusso di lavoro continuo.
"La mancanza di contesto lungo è la ragione principale per cui continuo a usare Anthropic."
Questa citazione, come le successive, proviene dalla discussione su Hacker News seguita alla PR.
La community ha già deciso
La PR di OpenAI ha scatenato una discussione su Hacker News. Il sentiment è inequivocabile. Non è il solito rumore da forum: sono sviluppatori che descrivono esattamente come e perché stanno cambiando provider.
La frustrazione non riguarda solo il numero assoluto (272k). Riguarda il comportamento della compattazione automatica. Su Codex, la compattazione è opaca, non disabilitabile, e non c'è modo di tornare indietro nella cronologia della conversazione dopo che è scattata. Il risultato è un ciclo noto a chiunque abbia usato Codex su codebase complesse:
La compattazione uccide le mie sessioni, allucina ed è peggio che ricominciare da capo. Ho passato abbastanza tempo a urlare al computer quando brucia token su una codebase grande, arriva al 15%, compatta automaticamente e allucina così tanto che deve rileggere l'intera codebase, arriva al 15%, compatta automaticamente...
La risposta più emblematica nel thread è questa, nella sua semplicità brutale:
npm uninstall -g @openai/codex && curl -fsSL [claude-installer-url] | bashLo script, copiato dal thread HN, rimuove Codex e installa Claude Code via curl dalla pagina ufficiale Anthropic.
"Questa è stata la goccia che ha fatto traboccare il vaso per declassare il mio abbonamento OpenAI e spostare la maggior parte della mia spesa su Anthropic e Claude Code."
Context-bonsai: quando la community costruisce ciò che il vendor non offre
Che la riduzione della context window abbia spinto la community a costruire soluzioni fai-da-te la dice lunga sul problema. Context Bonsai è un progetto open source che aggiunge due operazioni agli agenti di coding: prune (archivia selettivamente porzioni di conversazione finite, lasciando un riassunto) e retrieve (recupera porzioni archiviate se servono di nuovo).
Non è un wrapper. È un plugin che si integra a livello di harness, manipolando il transcript prima che venga inviato al modello. Il contenuto archiviato non viene distrutto: rimane recuperabile. La differenza con la compattazione proprietaria di OpenAI è che qui il modello decide cosa archiviare, con selettori testuali precisi che devono matchare esattamente un messaggio. Se il selettore è ambiguo, il prune viene rifiutato.
Context Bonsai è già stato portato e verificato su Codex, Claude Code, Pi, Cline, Kilo e Hermes. È un workaround a un problema che non dovrebbe esistere: gli sviluppatori stanno costruendo sistemi di gestione del contesto perché non si fidano di quelli integrati.
Cosa significa per il futuro degli AI coding agent
La context window sta diventando il vero campo di battaglia della programmazione assistita.
Qualità del modello? GPT 5.6 e Claude Opus sono entrambi eccellenti. Prezzo? Gli abbonamenti flat mascherano i veri costi. Funzionalità? I comandi slash e le integrazioni sono ormai commodity.
La differenza che conta, per uno sviluppatore che lavora su progetti reali, è quanto a lungo l'agente può mantenere il contesto prima di perdere il filo. E qui Anthropic ha un vantaggio strutturale: ha scelto di investire in infrastruttura per supportare 1M token, mentre OpenAI sta scoprendo che l'economia dei cache reads rende insostenibile persino mantenerne un terzo.
La community ha già dimostrato di preferire contesto grezzo a compattazione intelligente ma opaca.
La migrazione verso Claude Code che vediamo nei forum è un segnale. Resta da vedere se OpenAI troverà un modello di pricing che allinei gli incentivi (pay-per-token con soglie) o continuerà a comprimere la context window sperando che la compattazione proprietaria diventi abbastanza buona da non far sentire la differenza.
È una scommessa rischiosa. La community ha già dimostrato di saper cambiare provider in una riga di terminale.
Further Reading
openai
Vibecodelicious(1) is not correct, it is not due to 2X charging after 272k context, we don't charge for longer context on the subscription for GPT 5.6 Sol as we control all the settings. It is due to something else, which I will attempt to explain below.
— Tibo (@thsottiaux) July 13, 2026
The overall trajectory length, which is… pic.twitter.com/Y2XktTy7wB
