Limite output Claude Code: come aumentarlo

Limite output Claude Code: la risposta rapida

I due controlli sono stati introdotti in Claude Code 2.1.261 il 4 settembre 2026. Risolvono un problema ben preciso: il comando è stato eseguito e i dati esistono, ma al modello ne arriva una porzione troppo piccola inline.

Sono limiti espressi in caratteri, non in token. È come allargare lo sportello attraverso cui passa il risultato: Claude riceve una parte maggiore del log in una sola volta, ma ogni riga aggiuntiva occupa anche spazio nella sessione.

Prima recupera l’output mancante

Aumentare il limite non è la prima mossa da fare. Conviene recuperare il log completo, individuare le informazioni mancanti e solo dopo stabilire se quel tipo di comando merita più spazio inline.

Per un comando riuscito, Claude Code invia inline circa 30,000 caratteri per impostazione predefinita. Se l’output è più lungo, Claude riceve una breve anteprima iniziale e il percorso del file salvato nella directory della sessione. Basta chiedere a Claude di leggere il file in quel percorso o di cercarvi le informazioni necessarie. In genere consuma meno contesto che inserire l’intero log in ogni turno simile.

Un comando non riuscito viene gestito diversamente. Quando l’output è troppo lungo, Claude riceve un estratto di circa 10,000 caratteri preso dall’inizio e dalla fine, senza il percorso del file salvato. Se lo stack trace mancante si trova nel mezzo, riesegui il comando scrivendo l’output completo in un file noto:

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

Il file .claude/logs/test-full.log diventa così la fonte attendibile. Chiedi a Claude di cercare nomi dei test non riusciti, eccezioni e stack trace, senza incollare tutto il file nella chat. In questo modo anche il codice di uscita originale resta visibile come prova.

Quando passano in background, i comandi indicano già il file in cui stanno scrivendo. Anthropic ora segnala TaskOutput come deprecato e consiglia di usare Read su quel percorso, spesso la soluzione più pulita per recuperare l’output.

Applica la modifica minima che serve davvero

Se lo stesso comando riuscito supera regolarmente la finestra predefinita, aumenta soltanto bashOutputMaxChars. Partire da 60,000 caratteri raddoppia all’incirca lo spazio inline standard senza arrivare subito al tetto di 128,000:

{
  "bashOutputMaxChars": 60000
}

Inserisci l’oggetto nell’ambito che corrisponde al problema:

Esegui /status per verificare quale file abbia caricato Claude Code. Poi ripeti lo stesso comando e confronta il conteggio di wc -c con il valore scelto. Se il log è ancora più grande, per un risultato riuscito Claude Code dovrebbe fornire di nuovo un’anteprima e il percorso del file salvato.

Per un’attività in background usa invece taskOutputMaxChars. Vale lo stesso intervallo da 4,000 a 128,000 caratteri. Se un’attività terminata supera comunque il limite, Claude riceve i caratteri più recenti: il file di output resta quindi il riferimento affidabile per consultare l’intera cronologia.

Entrambe le impostazioni prevalgono sulle rispettive variabili d’ambiente usate in precedenza. Quando è presente bashOutputMaxChars, Claude Code ignora BASH_MAX_OUTPUT_LENGTH; con taskOutputMaxChars, ignora TASK_MAX_OUTPUT_LENGTH. Usare insieme vecchi e nuovi controlli complica la diagnosi, quindi è meglio mantenere un’unica fonte attendibile.

Il costo in contesto si sposta, non scompare

Portare un comando riuscito dai circa 30,000 caratteri predefiniti a 60,000 può evitare una lettura separata del file, se il risultato completo rientra nella nuova soglia. Può però inserire subito nella sessione fino a circa 30,000 caratteri in più. Con 128,000 caratteri, la finestra consentita supera di poco quattro volte quella predefinita per i comandi riusciti.

Non esiste una conversione fissa e attendibile da questo aumento in caratteri a token o dollari. Codice sorgente, JSON, testo e Unicode vengono tokenizzati in modo diverso; inoltre costi e quote dipendono dal modello e dal tipo di account. Il criterio pratico è più semplice:

• Aumenta il limite quando la parte omessa contiene informazioni che Claude deve recuperare di continuo.
• Mantieni il valore predefinito quando basta una ricerca mirata nel file salvato.
• Riduci di nuovo un’eccezione di progetto al termine dell’analisi rumorosa.
• Non aumentare entrambe le impostazioni solo perché un comando è stato troncato una volta.

Questo intervento completa il lavoro di riduzione del costo di contesto delle skill di Claude Code. I metadati delle skill occupano contesto prima dell’inizio del lavoro; l’output degli strumenti arriva durante l’esecuzione. Risolvere un problema non risolve l’altro.

Sette workflow che ne traggono vantaggio, in ordine di utilità

1. Riepiloghi dei test in un monorepo

Un release engineer che esegue una suite di test molto ampia può ottenere un risultato riuscito i cui riepiloghi e avvisi dei vari package superano la finestra inline predefinita. Aumentare bashOutputMaxChars per quel repository permette di ricevere l’intero riepilogo già nel primo risultato. Il vantaggio consiste in meno letture successive durante ogni controllo di release, a patto che l’output rientri davvero nel limite scelto.

2. Ambienti di integrazione in background

Un team di piattaforma può lasciare in esecuzione un server locale, un emulatore o un ambiente di integrazione come attività in background, mentre Claude si occupa di altro. Aumentando taskOutputMaxChars, Claude riceve una porzione maggiore dell’output recente quando controlla l’attività. Il file completo resta comunque importante, perché dopo l’overflow l’impostazione privilegia i caratteri più recenti.

3. Analisi degli avvisi di compilatori e linter

Un team applicativo può completare una build con successo e produrre comunque migliaia di avvisi. Una finestra più ampia per i comandi riusciti può mostrare quelli relativi ai package che altrimenti resterebbero oltre l’anteprima. È un compromesso utile quando il team sta smaltendo un arretrato di warning e il risultato completo conta più di una sessione snella.

4. Dry run delle migrazioni di database

Un data engineer può eseguire con successo un dry run che elenca ogni modifica proposta allo schema. Mantenere inline un piano di dimensioni limitate permette a Claude di confrontare le modifiche correlate in un solo risultato. La revisione rimane così più lineare, ma soltanto dopo aver escluso dal log segreti e identificativi di produzione.

5. Audit di dipendenze e licenze

Un security engineer può ricevere un lungo inventario generato con successo, con risultati distribuiti anche nella parte centrale. Un limite Bash impostato a livello di repository può rendere disponibile l’intero report circoscritto per una sessione di audit. Si riduce così il rischio che un package sfugga solo perché si trovava fuori dall’anteprima.

6. Analisi dei test instabili

Un QA engineer deve ricostruire la sequenza esatta attorno a un errore sporadico, ma il risultato del comando non riuscito mostra solo un estratto iniziale e finale. Aumentare l’impostazione Bash non cambia questo comportamento. Salvando la nuova esecuzione in un file noto e cercando poi un intervallo temporale o il nome di un test, si conservano le prove senza riempire la sessione.

7. Generatori di codice molto verbosi

Chi esegue un generatore può avere bisogno una sola volta del report completo di un’operazione riuscita, per esempio per controllare ogni file creato o ignorato. Un’impostazione locale temporanea può ampliare il risultato durante l’analisi e poi essere rimossa. Si ottiene una verifica più pulita delle modifiche generate, evitando che un’eccezione occasionale diventi la regola permanente del team.

Per chi non conosce ancora l’organizzazione dei file di configurazione, la guida completa alla configurazione di Claude Code spiega il ruolo dello strumento prima di intervenire su questo caso limite.

Cosa vale la pena costruire

Opportunità principale: un broker di log consapevole del contesto

Si può creare un wrapper locale dei comandi per i team che sviluppano con l’AI: conserva sempre il log grezzo, ne misura il numero di caratteri, indicizza gli intervalli importanti e restituisce un manifest compatto con i percorsi. Dovrebbe proporre un limite inline specifico per comando soltanto quando le stesse informazioni vengono recuperate ripetutamente.

Il mercato collegato è piccolo, ma commercialmente interessante. Negli Stati Uniti, i dati sulle keyword stimano 320 ricerche mensili per log analyzer, con intento transazionale e un costo per clic di $60.95. I budget dedicati all’osservabilità confermano che la gestione dei log ha già acquirenti: Better Stack propone un pacchetto da 40 GB per log, trace e metriche a $25 al mese con fatturazione annuale, oltre alla chat AI SRE a $5 per milione di token. Questi prodotti risolvono un problema più ampio, ma la spesa dimostra che i team pagano per trovare il segnale nei log.

La versione minima vendibile comprende un wrapper multipiattaforma, una directory locale per i log, un contatore di caratteri, un indice degli errori e un report che Claude possa leggere in modo selettivo. Il punto critico è la fiducia. I log di build possono contenere credenziali, dati dei clienti e percorsi proprietari: archiviazione local-first e regole chiare per oscurare le informazioni sensibili sono parte del prodotto, non semplici rifiniture. È l’opportunità migliore perché risolve la decisione ricorrente che sta dietro all’impostazione, non la sola modifica del JSON.

Opportunità di nicchia: un aggregatore delle prove di test

Si può sviluppare un adattatore che esegue i framework di test più comuni, conserva intatto il log e fornisce a Claude una breve mappa delle evidenze con i nomi dei test non riusciti, gli intervalli degli stack trace e il percorso da leggere per approfondire. I team QA e developer experience sarebbero disposti a pagare quando una singola suite rumorosa produce ogni giorno lo stesso lavoro di triage.

La query test failure analysis totalizza negli Stati Uniti circa 20 ricerche al mese, con bassa concorrenza e difficoltà della keyword pari a 11. Non è una domanda sufficiente per proporre un SaaS generico e indipendente. Basta però a giustificare una funzione mirata all’interno del broker di log o uno strumento a pagamento per i team con suite di test costose.

Un MVP richiede adattatori per due o tre runner, archiviazione deterministica del log grezzo e una vista affiancata delle evidenze estratte e delle righe sorgente. Il problema è la frammentazione: Jest, Pytest, Gradle e i runner personalizzati formattano gli errori in modi diversi, e un estrattore troppo sicuro di sé può eliminare proprio l’indizio necessario a Claude. Il file grezzo deve restare sempre accessibile con una sola lettura.

Quando questa impostazione non serve

Questa impostazione non offre altri messaggi Claude, non aumenta la quota settimanale, non amplia la finestra di contesto del modello e non aggira i limiti di utilizzo degli strumenti. Modifica esclusivamente la gestione inline dei caratteri per due percorsi di risultato locali di Claude Code.

Non rende sicuro neppure un output illimitato. L’output dei comandi riusciti salvato da Claude Code viene troncato oltre 64 MiB, mentre un comando viene terminato se il flusso di output supera 5 GB. Soprattutto, un risultato inline di 128,000 caratteri può sottrarre spazio al contesto utile della conversazione. Il massimo è una misura di protezione, non un valore consigliato.

Le sessioni cloud introducono anche un’insidia legata all’ambito. Leggono un file .claude/settings.json incluso nel commit, ma non le impostazioni utente o locali presenti sul computer. In quelle sessioni arrivano soltanto le impostazioni dell’organizzazione gestite dal server. Se un valore sembra ignorato, controlla /status prima di modificarlo di nuovo.

Per sviluppare un workflow consapevole del contesto attorno ai propri sistemi di test e log, il punto di partenza è la progettazione di sistemi AI in produzione.