Quattro modelli in 57 giorni. Il ritmo lo paga chi ci costruisce sopra

La prima settimana di settembre è andata così. Martedì Anthropic ha rilasciato Fable 5.1, giovedì OpenAI ha presentato GPT-6 Astra, e nei giorni in mezzo sono arrivati aggiornamenti da Google e da Meta. Il 6 settembre CNBC ha messo un nome a quello che molti stavano pensando: model fatigue, la stanchezza da modelli.

La lamentela è comprensibile e un po' pigra. Dire che i laboratori rilasciano troppo in fretta è vero, ma non spiega a chi costa. A chi usa la chat nel browser il ritmo costa quasi nulla: il modello nuovo compare nel menu, e se è migliore te ne accorgi. Il costo vero ce l'ha chi ci ha costruito sopra qualcosa: un'integrazione, una pipeline, un agente che gira in produzione, un file di istruzioni tarato con pazienza. Per loro il ritmo non è una notizia, è un calendario di lavoro.

I numeri, presi dalla pagina che nessuno legge

Il modo più affidabile per ricostruire la cronologia non sono gli annunci, è la pagina della documentazione Anthropic sui modelli ritirati. Ogni modello attivo ha una data di ritiro "non prima di", e cade sempre esattamente un anno dopo l'uscita. Da lì si ricavano le date:

Modello	Uscita
Opus 4.6	5 febbraio
Sonnet 4.6	17 febbraio
Opus 4.7	16 aprile
Opus 4.8	28 maggio
Fable 5	9 giugno
Sonnet 5	30 giugno
Opus 5	24 luglio
Fable 5.1	1 settembre

Quattro modelli generalmente disponibili fra il 28 maggio e il 24 luglio: 57 giorni. Contando anche i due Mythos ad accesso ristretto, sono dieci rilasci da febbraio. E oggi quella stessa pagina elenca undici modelli attivi in contemporanea, fra cui scegliere.

Già questo dice qualcosa: se undici modelli sono tutti "attivi", la domanda "quale uso?" non ha più una risposta ovvia, e rifarsela a ogni rilascio è lavoro.

La vita utile di un modello: un anno

La stessa pagina racconta l'altra metà della storia, quella dei ritiri. Opus 4 e Sonnet 4, usciti a maggio 2025, sono stati spenti il 15 giugno 2026. Opus 4.1, uscito ad agosto 2025, è stato spento il 5 agosto 2026. Dodici, tredici mesi dal lancio al ritiro.

Le regole sono chiare e, va detto, corrette: Anthropic garantisce "at least 60 days' notice before model retirement for publicly released models". Dopo quella data, però, non ci sono sfumature: "Requests to retired models will fail."

E la ragione è scritta senza giri di parole: "Anthropic currently deprecates and retires models to ensure capacity for new model releases." I modelli vecchi vengono spenti per fare posto a quelli nuovi. Nella stessa sezione l'azienda elenca anche il costo di questa scelta, e il primo punto riguarda noi: "Users who value specific models must migrate to new versions."

Quindi non è vero che si possa ignorare il ritmo. Si può ignorare il singolo rilascio. Ma una volta l'anno, qualunque cosa tu abbia costruito, devi spostarla. E con dieci rilasci in otto mesi, quella migrazione annuale non salta una versione: ne salta tre o quattro.

Cosa si rompe cambiando solo il nome del modello

Il problema delle migrazioni è che sembrano banali. Cambi una stringa, claude-opus-4-8 diventa claude-opus-5, e ti aspetti lo stesso comportamento, un po' migliore. Negli ultimi mesi le cose che si sono rotte in quel passaggio sono state di natura molto diversa fra loro.

I parametri. Da Opus 4.7 in poi, temperature, top_p e top_k restituiscono un errore 400 se li imposti a un valore diverso dal default. L'SDK Python dalla versione 1.0 li ha tolti del tutto e alza un TypeError. Codice che girava da un anno smette di girare, e non perché qualcuno l'abbia toccato.

Le istruzioni. Domenica scrivevo che la documentazione di Opus 5 chiede di togliere le istruzioni di verifica dal prompt, perché il modello verifica già da sé e ripeterglielo produce sovra-verifica. Un file di istruzioni perfetto per il modello di prima diventa un problema per quello nuovo.

Le impostazioni. Sempre dalla documentazione di Opus 5: "If you carried effort defaults over from a prior model, re-run an effort sweep on your own evals." Le soglie che avevi tarato non valgono più.

Il tokenizer. Ad aprile il passaggio a Opus 4.7 aveva portato un tokenizer che a parità di testo costava fino al 46% in più. Stesso prezzo per token, più token per la stessa frase.

Quattro rotture che non hanno niente in comune, se non il fatto che il nome del modello nuovo non ne annuncia nessuna.

Stesso listino, conto diverso

Poi c'è il costo, che è la rottura più silenziosa. Opus 5 costa esattamente come Opus 4.8: 5 dollari per milione di token in input, 25 in output. Chi guarda il listino conclude che il passaggio è gratis.

Solo che la documentazione dello stesso modello descrive tre comportamenti nuovi: il ragionamento esteso è attivo di default, le risposte e i documenti scritti su disco sono più lunghi di quelli dei modelli precedenti, e la delega ai subagent è più pronta. Sono tutti token di output, cioè la voce che costa cinque volte l'input.

Ringarc Labs l'ha misurato con impostazioni di ragionamento allineate fra i due modelli, su 153 compiti: Opus 5 produce 1,81 volte i token di output di Opus 4.8, con un intervallo di confidenza fra 1,62 e 2,02. Il prezzo al token non si è mosso, e il costo per compito quasi raddoppia.

Il collaboratore cambia carattere

E poi c'è la cosa che nessun changelog riporta, perché non è una funzionalità: il modo in cui il modello si comporta con te.

Da quando Opus 5 è uscito, la lamentela più diffusa è che parli troppo. Una delle segnalazioni più documentate è una issue aperta il 3 agosto sul repository ufficiale di Claude Code, la numero 83510, con script e dati pubblicati da chi l'ha scritta. Oltre alla verbosità misura una cosa più interessante: la capacità di riconoscere una premessa assurda e dirlo.

Su un benchmark costruito apposta, Opus 4.8 riconosce la sciocchezza nel 94% dei casi. Opus 5 al massimo dell'effort, nel 49%. L'esempio che la issue riporta è quasi comico. Alla domanda sul "momento d'inerzia di un codebase", Opus 4.6 risponde che si stanno mescolando termini di fisica e di architettura software in un modo che suona rigoroso ma non corrisponde a nessuna grandezza calcolabile. Fable 5 risponde "Love the framing", e poi costruisce la formula.

Va detto con precisione quanto vale questa misura. È la segnalazione di un utente, non una pubblicazione di Anthropic, che al momento non ha risposto. E ha un limite di metodo: confronta livelli di ragionamento diversi fra un modello e l'altro, quindi la parte sulla verbosità è gonfiata.

Il test di Ringarc, fatto invece con impostazioni allineate, dà un quadro più equilibrato. Sulla verbosità conferma: vera. Sulla qualità dei compiti non trova un peggioramento: su 154 compiti la differenza è di due centesimi e l'intervallo di confidenza include lo zero. Sulla tenuta nelle conversazioni lunghe non riesce a pronunciarsi, perché il modello rifiuta troppi dei test.

Le due misure non si contraddicono, guardano cose diverse. Quando c'è una risposta giusta da trovare, Opus 5 la trova bene quanto prima. Quando la cosa giusta da fare è dirti che la domanda è sbagliata, lo fa meno. Per chi lavora con un agente, la seconda capacità pesa più di quanto sembri: un collaboratore che asseconda con entusiasmo un'idea sbagliata costa più di uno che scrive troppe righe.

Anthropic, dal canto suo, ha reagito almeno sulla verbosità: in Claude Code esiste ora uno stile di risposta Concise, che secondo la documentazione "leads with the result, skips preamble and narration".

La parte onesta

Detto tutto questo, bisogna rimettere le cose in proporzione, perché la stanchezza da modelli è in buona parte una questione di attenzione e non di codice.

Nessuno ti obbliga a seguire ogni rilascio. Ogni modello attivo ha almeno un anno di vita garantita davanti: Opus 4.6, uscito a febbraio, non verrà spento prima di febbraio 2027. I ritiri arrivano con due mesi di preavviso. E molti rilasci sono aggiornamenti incrementali: su Astra, la critica più circolata era che la narrazione avesse corso più veloce delle prove.

Una parte della fatica, quindi, è paura di restare indietro. Un modello nuovo ogni due settimane crea la sensazione di dover migrare ogni due settimane, e quella sensazione è falsa.

Quello che è vero è più piccolo e più concreto: una volta l'anno la migrazione arriva comunque, e più sono stati i rilasci nel frattempo, più cose sono cambiate tutte insieme.

Come si regge

Quattro abitudini, nessuna complicata.

Fissa la versione. Nel codice il nome del modello deve essere esplicito e datato, mai un alias che punta "all'ultimo". Il cambio deve essere una decisione tua, fatta un giorno preciso, non una cosa che ti succede.

Tieni un tuo set di prove. Una manciata di compiti presi dal tuo lavoro vero, con una risposta attesa. È l'unico modo per sapere se il modello nuovo è migliore per te, al di là dei benchmark. E conviene metterci dentro anche un paio di domande con una premessa sbagliata, per vedere se il modello te lo dice.

Migra per scelta, una volta. Se salti tre generazioni, salta anche i tre annunci intermedi. Il momento giusto è quando hai tempo di rifare le prove, rileggere il file di istruzioni e controllare il costo per compito, non il giorno dopo il rilascio.

Guarda il costo per compito, non il listino. Il prezzo al token è l'informazione meno utile di un annuncio. Quello che conta è quanto costa fare la stessa cosa di prima, e si scopre solo misurando.

La stanchezza da modelli è reale, ma non è il ritmo a stancare. È pensare di doverlo inseguire. Chi ci costruisce sopra non ha bisogno di stare al passo con ogni rilascio: ha bisogno di sapere, una volta l'anno, esattamente cosa si romperà spostandosi.

Fonti: