Claude Code taglia il limite del 17%: 5 fix misurati

Il limite settimanale di Claude Code è sceso del 17% a metà settembre 2026, quando la promo estiva è finita. Chi ha i piani più grandi segnala una settimana vuota già il mercoledì. L'annuncio di Anthropic dice che i limiti sono stati alzati in modo permanente del 25%, e il post subito dopo chiama la stessa modifica una riduzione del 17%.

Ogni lista di consigli per far durare di più il limite arriva senza un solo numero. Questo articolo dà a ogni fix un numero misurato e li mette in classifica. Due risultati spiccano: quasi metà di un mese di token è andata ai subagent, e una sola pausa lunga fa sì che il messaggio successivo riscriva buona parte della sessione.

Le misure qui vengono da un mese di log di Claude Code di un singolo sviluppatore: 455 sessioni e 63.398 richieste, dal 3 settembre al 3 ottobre.

La promo è andata da maggio al 13 settembre e ha reso il limite settimanale più alto del 50%. Il limite di ogni finestra di cinque ore non si è mai mosso. A fine agosto l'account sviluppatori di Anthropic ha annunciato un aumento permanente del 25%, e un post dopo lo stesso thread dice che in realtà è una riduzione del 17%. Le due frasi sono vere:

Periodo	Limite settimanale (vecchio limite = 100)
Prima della promo	100
Durante la promo (da maggio al 13 settembre)	150
Livello permanente dal 14 settembre	125

Da 150 a 125 è il 17% che la gente sente. Un utente con due dei piani più grandi ha scritto che essere al 100% di mercoledì non gli era mai successo prima. Un altro, con lo stesso piano, era all'86% un martedì mattina. Il taglio non è l'unica causa: a inizio settembre è uscito un modello più vorace, quindi non ogni settimana vuota dipende da questa modifica.

Da parte tua vedi una percentuale. La schermata /usage divide l'uso recente tra skill, subagent, plugin e ogni server MCP collegato, e segnala i cache miss. Un tasto la fa passare dall'ultimo giorno agli ultimi sette. Quello che non vedi è la dimensione del limite in token: Anthropic pubblica percentuali e moltiplicatori, mai un conteggio di token. Tutto ciò che è misurato qui sotto è quindi in token, da un solo carico di lavoro, e non è una quota della tua settimana.

Contare i token dai log ha una trappola. Il log scrive la stessa risposta più volte, quindi sommando ogni riga si arriva a 18,6 miliardi di token. Contata una volta sola, sono 9,3 miliardi. Un conteggio ingenuo quasi raddoppia tutto.

Un subagent è un altro Claude che la tua sessione avvia per un lavoro secondario, e che riferisce quando ha finito. Nel mese misurato, i subagent hanno consumato il 48,1% di tutti i token in 2.631 esecuzioni.

Misura	Quota dei subagent
Tutti i token	48,1%
Token di output	63,9%
Pesata come il listino pubblico pesa output e scritture in cache	55,3%

Ogni subagent paga anche un prezzo d'ingresso. Prima di fare qualsiasi cosa, la sua richiesta d'apertura porta già una mediana di 47.117 token: le istruzioni, la lista dei tool e la lista delle skill, tutto rimandato di nuovo. Qualcun altro lo ha misurato su un'altra macchina e ha trovato da 16.000 a 21.000 token per ogni avvio, per agent con un prompt proprio minuscolo. Come dice quell'articolo, il file dell'agent è un errore di arrotondamento dentro il costo del suo stesso avvio.

Il modello è l'altra metà. Di default un subagent eredita il modello della conversazione principale, quindi portare la sessione sul modello più grande mette sopra anche tutti gli aiutanti. Nei log misurati, il modello più piccolo ha gestito meno dell'1% delle richieste dei subagent. Il fix è una riga nel file dell'agent: un campo model impostato su un modello più piccolo per lavori come lanciare i test o cercare file.

Ne vengono due abitudini. Salta il subagent per un lavoretto che puoi fare sul posto, e fissa un modello piccolo su quelli che tieni.

Il limite di questo risultato: nessuno ha misurato quanto fissare il modello faccia risparmiare come quota della settimana, e un modello piccolo che ha bisogno di più passaggi può costare di più. Il 48% viene da un lavoro che si ramifica molto. La tua quota sta nella schermata /usage.

Claude Code tiene la tua conversazione in una cache dei prompt sul server, e rileggerla costa una frazione di quanto costa rimandarla. Per la sessione principale quella cache vive un'ora. Per un subagent vive cinque minuti.

La documentazione lo dice chiaramente: i subagent hanno cinque minuti, anche con un abbonamento, finché non ne scegli di più lunghi. Lo stesso vale per tutto ciò che sta fuori dalla conversazione principale, compresi il lavoro in background e la compattazione. I log misurati concordano: ogni scrittura in cache di un subagent è finita nel livello da cinque minuti, e ogni scrittura di una sessione principale in quello da un'ora.

Uno sviluppatore su Reddit ha notato cosa comporta: uno dei suoi subagent ha riscritto tutto il suo contesto otto volte in un solo giorno. Il fix è una riga nel file delle impostazioni, "subagentPromptCacheTtl": "1h".

La sua misura	Prima	Dopo
Scritture in cache	12,2 milioni di token	3,0 milioni di token
Finestra di cinque ore con quattro subagent	dal 2% al 100%	dallo 0% al 22%

È un solo utente che confronta due giorni diversi, non un test controllato. Nei log misurati qui conta poco: solo 95 richieste di seguito dei subagent su 41.790 (circa due su mille) sono arrivate dopo un'attesa di più di cinque minuti, anche se ognuna ha riscritto circa 75.000 token.

Quindi dipende da come lavorano i tuoi subagent. Se aspettano una build lunga, una review o te, attivala. Se lavorano a brevi raffiche, lasciala stare, perché una cache che dura un'ora costa di più da scrivere.

La cache della sessione principale dura un'ora. Dopo una pausa più lunga non c'è più, e il messaggio successivo non può rileggere nulla. La documentazione lo spiega: il messaggio che mandi dopo la pausa manca la cache ed elabora di nuovo tutto il tuo contesto.

Pausa prima del messaggio	Richieste	Cache riscritta (mediana)
Meno di 5 minuti	18.029	1.176 token
Da 5 a 60 minuti	414	1.327 token
Più di 60 minuti	79	130.332 token

La sessione tipica in quel momento conteneva 175.523 token, quindi la maggior parte è stata scritta di nuovo. E il contatore non tratta una scrittura come una lettura. Uno sviluppatore ha messo un proxy di logging davanti a Claude Code e ha osservato la sua finestra di cinque ore: secondo i suoi rapporti, un token scritto in cache pesa circa quaranta volte un token letto.

Claude Code lo sa. Quando riprendi una sessione grande dopo una lunga pausa, ti propone di riprendere da un riassunto. Accetta.

L'abitudine più economica viene prima. Quando un task è finito, fai clear della sessione mentre la cache è ancora calda. Il clear non costa niente e il task dopo parte piccolo. Anche compattare funziona, ma compattare una sessione enorme è già una richiesta enorme.

Una pausa non è l'unico modo per perdere la cache. Cambiare modello a metà sessione la svuota, perché ogni modello tiene la sua. Sui modelli più recenti, cambiare l'effort no. Claude Code ti chiede di confermare un cambio di modello mentre la cache è calda, e quella richiesta è l'avviso.

I limiti: 79 ritorni a freddo sono un campione piccolo, e alcuni seguono una compattazione. Un riassunto perde anche dei dettagli, quindi questo fix costa un po' di continuità.

L'effort è quanto a lungo il modello può pensare prima di rispondere. Ci sono cinque livelli, da low a max, e il pensiero è fatturato come output. Il default è high sulla maggior parte dei modelli e medium sui due più recenti.

La documentazione dice che il budget di pensiero può arrivare a decine di migliaia di token per richiesta e che il livello più alto è incline a pensare troppo. Sui modelli più recenti il pensiero non si può spegnere affatto, quindi il livello è l'unico controllo.

Uno sviluppatore ha eseguito gli stessi 29 task reali a tutti e cinque i livelli:

Livello di effort	Costo medio per task	Task superati (su 29)
low	2,50 $	23
medium	3,15 $	28
high	5,01 $	26
xhigh	6,51 $	25
max	8,84 $	27

La qualità non ha seguito il costo. Medium ha superato più task di qualsiasi livello sopra di sé, e per dollaro ha anche dato più successi. Con le sue parole, la curva sembra avere il picco a medium. Il team di Claude Code lavora allo stesso modo: uno dei suoi ingegneri costruisce con low o medium, fa la review, e lancia la verifica solo con high.

Il problema è perché questo fix può costare qualità. Sui problemi difficili che aveva scelto, low ha superato zero volte su cinque e high cinque su cinque. Un tentativo low è durato due minuti, uno high trentatré.

Quindi adatta l'effort al passaggio: medium per costruire, high quando un errore costa caro (un bug in codice vecchio, una migrazione, un controllo finale), max quasi mai. I log di sessione registrano l'effort di ogni richiesta, così puoi controllare cosa hai usato davvero.

Quei costi sono in dollari su un modello più vecchio, non una quota della settimana: nessuno l'ha pubblicata. E un tentativo economico che fallisce e viene rifatto costa più di uno che funziona.

Alcuni fix stanno in ogni lista e spostano appena l'ago. Si possono provare gratis. Semplicemente non è lì che è andata la settimana.

Quello che si carica all'inizio è il vero fix di questo gruppo. Un articolo ha misurato la richiesta d'apertura da una cartella vuota a 29.061 token, e a quasi 39.000 dentro un progetto reale. Nei log misurati qui la richiesta d'apertura mediana è di 55.989 token, da 15.764 a 105.020 a seconda del progetto. Il comando /context mostra cosa c'è dentro (file di memoria, skill, liste di tool) e nomina ogni file di memoria caricato. Togli quello che non usi mai. Il guadagno è modesto perché quel blocco si scrive una volta e si legge dalla cache a ogni turno successivo. Fa male a un avvio a freddo e a ogni avvio di subagent.

Consiglio popolare	Misurato
Togliere i server MCP	1.350 token per 51 tool su tre server; 18 token per un server con un tool
Disattivare i suggerimenti di prompt	dal 3 al 4% per un utente; il "fino al 10%" veniva da un solo account con contesti enormi
Filtrare l'output della shell	circa lo 0,1% del volume totale, misurato da un contributore di uno di quei filtri

Le definizioni dei tool ora sono rimandate di default, ed è per questo che i server MCP pesano così poco. La documentazione definisce piccolo il costo dei suggerimenti di prompt. Tutti e tre crescono con la dimensione del tuo contesto, e i server costano di più sui modelli più vecchi dove il rinvio è disattivato. Spegnili pure, ma non aspettarti di riavere la settimana.

In classifica per quanto è stato misurato:

Posto	Fix	Misurato	Difetto
1	Meno subagent, e più economici	48,1% dei token; 47.117 per avvio	Meno parallelismo
2	Non riprendere una sessione fredda	130.332 token riscritti contro 1.176	Un riassunto perde dettagli
3	Effort: medium per costruire	3,15 $ contro 5,01 $ per task; 28 su 29 superati	Low fallisce sui problemi difficili
4	Cache dei subagent a un'ora	da 12,2 a 3,0 milioni di token scritti in cache	Conviene solo se i subagent aspettano
5	Riduci quello che si carica all'inizio	+9.744 token su una base di 29.061	Si paga una volta per sessione

I tre popolari (server MCP, suggerimenti di prompt, output della shell) non sono dove è andata la settimana.

I limiti, senza giri di parole: questa classifica è in token, da un mese di lavoro di una sola persona, più le misure di altri. Anthropic non pubblica la dimensione del limite in token, quindi nessuno da fuori può trasformarle in una quota della tua settimana. Il tuo ordine può essere diverso, e la schermata /usage te lo dirà.

I due fix più grandi sono abitudini, non impostazioni, e sono gratis: lancia meno subagent, e non riprendere mai per intero una sessione fredda.