Negli ultimi mesi le prestazioni di Claude Code e del modello Opus 4.6 sono finite al centro di un acceso dibattito, tra accuse di regressione, modifiche ai limiti d’uso e chiarimenti ufficiali.
Summary
Uno scontento crescente tra sviluppatori e power user
Un numero crescente di sviluppatori e utenti avanzati di intelligenza artificiale sostiene che Claude Opus 4.6 e Claude Code siano oggi meno capaci, meno affidabili e più dispendiosi in termini di token rispetto a poche settimane fa.
Le lamentele si sono diffuse rapidamente su GitHub, X e Reddit, con post che descrivono una peggiore tenuta nel ragionamento, interruzioni dei task a metà e un aumento di allucinazioni e contraddizioni.
Alcuni utenti hanno definito il fenomeno “AI shrinkflation”: stessi prezzi, ma qualità percepita inferiore. Altri si sono spinti oltre, ipotizzando un throttling mirato nei periodi di forte domanda.
Tuttavia queste affermazioni restano, per ora, non dimostrate. Dipendenti di Anthropic hanno negato pubblicamente di degradare i modelli per gestire la capacità, pur riconoscendo modifiche recenti ai limiti d’uso e ai default di ragionamento.
VentureBeat ha contattato Anthropic per chiarimenti su eventuali cambiamenti relativi a ragionamento, gestione del contesto, throttling, parametri d’inferenza o metodologie di benchmark. Al momento della pubblicazione, non era ancora arrivata una risposta.
Dalla segnalazione GitHub dell’esponente AMD alla viralità sui social
Una delle critiche più dettagliate è nata come issue su GitHub, aperta il 2 aprile 2026 da Stella Laurenzo, identificata su LinkedIn come Senior Director nel gruppo AI di AMD.
Nel post Laurenzo sostiene che Claude Code sia regredito al punto da non poter essere più considerato affidabile per lavori di ingegneria complessi, supportando la tesi con l’analisi di 6.852 sessioni, 17.871 blocchi di pensiero e 234.760 chiamate a tool.
Secondo la sua analisi, da febbraio la profondità di ragionamento stimata sarebbe calata nettamente, mentre sarebbero aumentati stop prematuri, soluzioni “più semplici possibili”, loop di ragionamento e un passaggio misurabile da un approccio orientato alla ricerca a uno orientato alla semplice modifica.
Il punto centrale del post è che, per workflow di ingegneria avanzata, il ragionamento esteso non è un optional, ma una condizione di base per rendere il modello realmente utilizzabile.
Quella discussione su GitHub è poi entrata nel dibattito più ampio sui social, con utenti X come @Hesamation che l’11 aprile hanno rilanciato screenshot del post, trasformandolo in un caso virale.
Inoltre, la risonanza è aumentata perché la narrazione “Claude sta peggiorando” si è ancorata a un’analisi corposa, firmata da una figura senior in un grande produttore di chip, basata su log, pattern di utilizzo dei tool e correzioni degli utenti, non su semplici impressioni.
La replica di Anthropic: modifiche di prodotto, non downgrade segreto
La risposta pubblica di Anthropic si è concentrata nel distinguere tra percezione degli utenti e reale degradazione del modello. In un commento fissato in alto nello stesso thread GitHub, il responsabile di Claude Code Boris Cherny ha ringraziato Laurenzo per l’analisi, contestandone però la conclusione.
Cherny ha spiegato che l’header “redact-thinking-2026-02-12” citato nella critica indica solo un cambiamento di interfaccia, che nasconde parte del “thinking” UI-side per ridurre la latenza, ma non modifica budget di ragionamento o funzionamento interno.
Ha inoltre citato due cambiamenti di prodotto che potrebbero aver influenzato la percezione: il passaggio di Opus 4.6 ad adaptive thinking di default il 9 febbraio e, dal 3 marzo, l’impostazione predefinita su effort medio (livello 85), ritenuto da Anthropic il miglior compromesso tra intelligenza, latenza e costo.
Cherny ha aggiunto che chi necessita di ragionamento più esteso può impostare manualmente un effort più alto digitando /effort high nelle sessioni terminal di Claude Code.
Detto ciò, qui si concentra il cuore della controversia: critici come Laurenzo insistono che il comportamento del sistema nei flussi di lavoro di coding più impegnativi sia peggiorato in modo evidente, indicando log e pattern d’uso come prova.
Anthropic, invece, afferma che le modifiche principali hanno riguardato interfaccia e impostazioni di default, non un abbassamento segreto del modello di base. La distinzione è tecnica ma, per molti power user che percepiscono risultati peggiori, non risulta del tutto rassicurante.
La copertura mediatica di testate come TechRadar e PC Gamer ha ulteriormente amplificato il post di Laurenzo e l’ondata di consenso di parte della community.
Dai social all’etichetta di “AI shrinkflation”
Un altro post virale su X del 7 aprile, firmato dallo sviluppatore Om Patel, ha ripreso gli stessi argomenti in forma ancora più diretta, sostenendo che qualcuno abbia “misurato” quanto Claude sia diventato “più stupido”, riassumendo il risultato in un calo del 67%.
Quel thread ha contribuito a diffondere l’etichetta “AI shrinkflation” e a portare il caso fuori dalla nicchia degli utenti intensivi di Claude Code, estendendolo al dibattito AI più generale su X.
Queste accuse hanno avuto presa perché sembrano riflettere quanto molti utenti frustrati dichiarano di osservare: più task incompleti, maggior backtracking, consumo di token più elevato e la sensazione che il sistema sia meno disposto a sostenere ragionamenti profondi su progetti software complessi rispetto a inizio anno.
Benchmark e test trasformano lo scontento in caso pubblico
Le contestazioni più rumorose basate su benchmark si sono concentrate su BridgeMind, gestore del benchmark di allucinazione BridgeBench. Il 12 aprile, l’account ha dichiarato che Claude Opus 4.6 sarebbe passato dall’83,3% di accuratezza (posizione n. 2) al 68,3% (posizione n. 10) in un nuovo test, parlando apertamente di modello “nerfed”.
Quel post si è diffuso rapidamente, diventando uno dei pilastri della tesi secondo cui Anthropic avrebbe degradato il modello. Altri utenti hanno pubblicato test che suggerivano performance inferiori di Opus 4.6 rispetto a Opus 4.5 in compiti di programmazione pratici.
Inoltre, alcuni thread hanno richiamato risultati collegati a TerminalBench come presunta prova di cambiamenti nel comportamento del modello in specifici harness o contesti di prodotto.
L’effetto complessivo è stato cumulativo: screenshot di benchmark, confronti affiancati e testimonianze aneddotiche hanno iniziato a rafforzarsi a vicenda nello spazio pubblico.
Ciò è rilevante perché i claim basati su benchmark tendono a circolare molto più delle lamentele soggettive. Un calo da n. 2 a n. 10 o uno swing marcato di accuratezza offrono l’immagine di una prova oggettiva, anche quando il confronto è più complesso.
Contestazioni sui benchmark e limiti dei confronti
La replica più incisiva alle affermazioni di BridgeBench non è arrivata da Anthropic ma dal ricercatore software e AI Paul Calcraft, che su X ha definito la comparazione fuorviante perché il primo test su Opus 4.6 si basava su 6 task, il secondo su 30.
Calcraft ha parlato di un “benchmark diverso” e ha aggiunto che, sui 6 task comuni, il punteggio di Claude sarebbe passato da 87,6% a 85,4%, una variazione modesta, mentre il grosso dello scostamento sembrava derivare da un singolo caso di fabbricazione senza ripetizioni.
A suo giudizio, differenze di questo tipo possono rientrare nel rumore statistico ordinario. La sua analisi ridimensiona uno dei claim più chiari e virali, senza però escludere che qualcosa nel comportamento del modello possa essere cambiato.
Anche il post originale di BridgeBench è stato poi corredato da una community note, che evidenziava come i due run avessero coperture diverse (6 contro 30 task) e che nel sottoinsieme comune il cambiamento fosse contenuto.
Nel complesso, il caso mostra come non tutte le affermazioni abbiano la stessa solidità. Alcune nascono da esperienza diretta, altre da modifiche di prodotto documentate, altre ancora da confronti di benchmark che non sono sempre perfettamente omogenei.
Limiti di sessione, domanda in crescita e sospetti sulla capacità
La controversia attuale si inserisce anche sullo sfondo di un cambiamento di policy confermato da Anthropic a fine marzo. Il 26 marzo 2026, il tecnico Anthropic Thariq Shihipar ha annunciato che, per gestire la crescente domanda di Claude, l’azienda avrebbe rivisto il funzionamento dei limiti di sessione di 5 ore per utenti Free, Pro e Max nelle ore di picco, lasciando invariati i limiti settimanali.
Ha spiegato che, nei giorni feriali tra le 5 e le 11 del mattino (ora Pacifico), gli utenti avrebbero consumato più velocemente le loro 5 ore di sessione. Nonostante alcuni miglioramenti di efficienza, circa il 7% degli utenti, soprattutto Pro, avrebbe iniziato a colpire limiti che prima non incontrava.
In un’email del 27 marzo 2026 a VentureBeat, Anthropic ha precisato che i clienti Team ed Enterprise non erano toccati da queste modifiche e che la variazione non era ottimizzata dinamicamente per singolo utente, ma applicata alla fascia oraria di picco dichiarata. L’azienda ha ribadito gli investimenti nel potenziamento della capacità.
Queste dichiarazioni riguardavano i limiti di sessione e non un downgrade del modello. Tuttavia, per molti osservatori, il collegamento è immediato: domanda in forte crescita, razionamento dell’uso nelle ore di punta, e quindi sospetto che anche la qualità possa essere stata ritoccata.
Cache dei prompt e costi: un’altra fonte di attrito
Un’ulteriore issue GitHub ha allargato il fronte del contendere a prezzi e quote. Nell’issue #46829, l’utente seanGSISG sostiene che il time-to-live (TTL) della cache dei prompt di Claude Code sia passato, a inizio marzo, da un’ora a cinque minuti, sulla base di quasi 120.000 chiamate API estratte da log di sessione su due macchine.
Secondo la segnalazione, questa modifica avrebbe causato un aumento sensibile dei costi di creazione di cache e del consumo di quota, soprattutto nelle lunghe sessioni di coding, dove un contesto cacheato che scade rapidamente deve essere ricostruito spesso.
In questo caso Anthropic non ha negato che qualcosa sia cambiato. In risposta sul thread, Jarred Sumner ha confermato che il cambiamento del 6 marzo era reale e intenzionale, ma ha respinto l’idea di una regressione, spiegando che Claude Code usa durate di cache diverse per differenti tipi di richieste.
Sumner ha sottolineato che una cache di un’ora non è sempre più economica, perché la scrittura iniziale costa di più e conviene solo se il contesto viene riutilizzato abbastanza volte. A suo dire, la modifica rientra in un lavoro continuo di ottimizzazione, e il comportamento precedente al 6 marzo non rappresentava lo “steady state” previsto.
Successivamente, Cherny è intervenuto con una risposta più dettagliata, definendo la cache a un’ora “sfumata” e spiegando che il team sta sperimentando euristiche per migliorare tasso di hit, uso di token e latenza per gli abbonati.
Ha aggiunto che Anthropic mantiene cache a cinque minuti per molte query, incluse quelle di sub-agent raramente ripresi, e che la disattivazione della telemetria disabilita anche alcuni gate sperimentali, facendo tornare Claude Code al default di cinque minuti in certi casi.
Infine, Cherny ha dichiarato che l’azienda prevede di esporre variabili d’ambiente per permettere agli utenti di forzare direttamente cache di un’ora o cinque minuti. Ciò non conferma che il sistema sia diventato complessivamente più costoso, ma mostra che le impostazioni di cache sono state oggetto di sperimentazione proprio mentre crescevano le lamentele su consumo di quota e cambi di comportamento.
Prestazioni di Claude Code, effort di default e accuse di downgrade
Dipendenti legati ad Anthropic hanno respinto pubblicamente le accuse più radicali. In una risposta molto condivisa su X, Cherny ha definito “falsa” l’idea che l’azienda abbia segretamente “nerfato” il sistema di sviluppo.
Ha spiegato che Claude Code era stato impostato su effort medio in seguito a feedback di utenti che lamentavano un consumo eccessivo di token, e che la modifica era stata comunicata sia nel changelog sia in un dialog mostrato all’apertura dello strumento.
La documentazione pubblica conferma il movimento di questi default. Nel changelog si legge che il 7 aprile Anthropic ha cambiato l’effort predefinito da medio ad alto per gli utenti API-key e per chi utilizza Bedrock, Vertex, Foundry, Team ed Enterprise.
Inoltre, ciò indica che Anthropic ha aggiustato attivamente queste impostazioni a seconda dei segmenti di utenza, dinamica che può influire in modo significativo sulla percezione delle prestazioni di Opus 4.6 anche se i pesi del modello restano invariati.
Shihipar, sempre su X l’11 aprile, ha anche smentito che l’azienda “degradi” i modelli per gestire meglio la domanda. Ha aggiunto che modifiche alle thinking summaries hanno influenzato il modo in cui alcuni utenti misuravano il “pensiero” del sistema, e che finora Anthropic non ha trovato prove a supporto dei claim qualitativi più estremi.
Fiducia, percezione e concorrenza nel mercato AI
Il dato certo è che tra Anthropic e una parte dei suoi utenti più esigenti si è aperto un problema di fiducia. Per chi usa Claude Code tutto il giorno, variazioni anche sottili in output di ragionamento visibile, effort di default, consumo di token, latenza o limiti d’uso possono risultare indistinguibili da un modello oggettivamente più debole.
Di conseguenza, le due parti rischiano di parlarsi a vuoto: gli utenti descrivono frustrazione e calo di affidabilità; l’azienda risponde citando impostazioni, UI, changelog e negando regressioni mirate.
Queste visioni non sono necessariamente in contraddizione. Un sistema può risultare peggiore all’uso pur senza un vero “nerf” dei pesi, se cambiano contesto, politiche di inferenza o priorità tra costi e profondità del ragionamento.
Nel frattempo, il confronto competitivo resta intenso. Il principale rivale OpenAI ha recentemente riorientato risorse sul proprio prodotto di coding per imprese, introducendo anche un abbonamento ChatGPT di fascia più media per stimolare l’adozione.
Per Anthropic, questo tipo di polemiche non aiuta, perché alza il rischio di migrazione verso alternative percepite come più stabili, in un momento in cui la fidelizzazione dei clienti enterprise è cruciale.
Un quadro ancora misto tra dati, percezioni e scelte di prodotto
Ad oggi, il quadro rimane sfumato. Diverse delle affermazioni più virali provengono da sviluppatori con log dettagliati e un utilizzo ripetuto nel tempo, incluse analisi statistiche di migliaia di sessioni.
Alcuni elementi di benchmark sono stati ridimensionati da osservatori esterni che ne hanno messo in discussione la metodologia o la comparabilità. Allo stesso tempo, Anthropic ha confermato modifiche concrete a limiti, cache e effort di default, che incidono direttamente sull’esperienza utente.
Nel complesso, la discussione sulle prestazioni e sulla regressione reale o percepita di Claude sembra destinata a proseguire finché l’azienda non offrirà ulteriori dati pubblici e strumenti di misurazione più solidi, capaci di allineare meglio aspettative degli utenti e decisioni di prodotto.
