Como aumentar o limite de output do Claude Code

Como ajustar o limite de output do Claude Code

Os dois controles chegaram no Claude Code 2.1.261, em 4 de setembro de 2026. Eles resolvem um problema bem específico: o comando foi executado e a evidência existe, mas uma parte pequena demais dela chegou ao modelo inline.

Esses valores medem caracteres, não tokens. Pense neles como a largura de uma portinhola: ao abri-la, Claude recebe uma fatia maior do log de uma só vez, mas cada linha adicional também ocupa espaço na sessão.

Primeiro, recupere o output que ficou de fora

Aumentar o limite não deve ser a primeira providência. Antes, recupere o log completo, encontre a evidência ausente e só então avalie se aquela categoria de comando realmente precisa de mais espaço inline.

Por padrão, Claude Code envia aproximadamente 30,000 caracteres inline quando um comando termina com sucesso. Se a saída for maior, Claude recebe uma prévia curta do começo e o caminho do arquivo em que o restante foi salvo no diretório da sessão. Peça a Claude para ler ou pesquisar esse caminho. Na maioria dos casos, isso consome menos contexto do que despejar o log inteiro em todas as execuções parecidas.

O comportamento muda quando o comando falha. Se a saída for longa demais, Claude recebe um trecho de aproximadamente 10,000 caracteres, combinando o início e o fim, sem o caminho do arquivo salvo no resultado. Caso o stack trace necessário esteja no meio, execute outra vez e grave toda a saída em um arquivo conhecido:

# 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"

O arquivo .claude/logs/test-full.log passa a ser a fonte confiável. Em vez de colar tudo no chat, peça a Claude para procurar nele os nomes dos testes que falharam, as exceções e os stack traces. O procedimento também mantém o código de saída original como evidência visível.

Comandos em segundo plano já informam o arquivo em que estão gravando quando passam a rodar em background. Agora, Anthropic marca TaskOutput como obsoleto e recomenda usar Read nesse caminho de saída, o que costuma ser a forma mais limpa de recuperar o conteúdo.

Faça a menor mudança que resolva o problema

Se o mesmo comando bem-sucedido estoura a janela padrão com frequência, aumente apenas bashOutputMaxChars. Começar com 60,000 caracteres praticamente dobra o limite inline padrão sem adotar de imediato o teto de 128,000 caracteres:

{
  "bashOutputMaxChars": 60000
}

Salve esse objeto no escopo correspondente ao problema:

Execute /status para confirmar qual arquivo foi carregado pelo Claude Code. Depois, rode o mesmo comando novamente e compare a contagem de wc -c com o valor definido. Se o log ainda for maior, Claude Code deverá voltar a fornecer uma prévia e o caminho do arquivo salvo para um resultado bem-sucedido.

Para tarefas em segundo plano, use taskOutputMaxChars. O mesmo intervalo de 4,000 a 128,000 caracteres se aplica. Quando uma tarefa concluída ainda ultrapassa o limite, Claude recebe os caracteres mais recentes; por isso, o arquivo de saída continua sendo a fonte confiável para consultar todo o histórico.

As duas configurações têm precedência sobre as variáveis de ambiente antigas. Quando bashOutputMaxChars está presente, Claude Code ignora BASH_MAX_OUTPUT_LENGTH. Quando taskOutputMaxChars está presente, ele ignora TASK_MAX_OUTPUT_LENGTH. Misturar os dois mecanismos complica o diagnóstico, então mantenha uma única fonte confiável.

O custo de contexto muda de lugar, mas não desaparece

Elevar a saída de um comando bem-sucedido do padrão de aproximadamente 30,000 caracteres para 60,000 pode evitar uma etapa separada de leitura do arquivo quando todo o resultado cabe na janela. Também pode colocar imediatamente até cerca de 30,000 caracteres adicionais na sessão. Em 128,000, a janela permitida passa de quatro vezes o tamanho padrão para comandos bem-sucedidos.

Não existe uma conversão fixa e honesta desse aumento em caracteres para tokens ou dólares. Código-fonte, JSON, prosa e Unicode são tokenizados de formas diferentes, e a cobrança ou cota varia conforme o modelo e o tipo de conta. Na prática, o orçamento pode seguir regras mais simples:

• Aumente o limite quando a parte omitida contiver evidências de que Claude precisa repetidamente.
• Mantenha o padrão quando uma busca direcionada no arquivo salvo responder à pergunta.
• Remova ou reduza uma exceção de projeto assim que a investigação ruidosa terminar.
• Não aumente as duas configurações só porque um comando foi cortado uma vez.

Esse ajuste complementa o trabalho de reduzir o custo de contexto das skills do Claude Code. Os metadados das skills ocupam contexto antes de a tarefa começar; o output das ferramentas chega durante o trabalho. Corrigir um deles não corrige o outro.

Sete fluxos que mais se beneficiam, em ordem

1. Resumos de testes em monorepos

Ao rodar uma suíte de testes extensa, uma pessoa responsável pelo release pode receber um resultado bem-sucedido cujos resumos de pacotes e avisos ultrapassam a janela inline padrão. Aumentar bashOutputMaxChars naquele repositório pode manter o resumo inteiro já no primeiro resultado. O ganho está em evitar leituras adicionais a cada verificação de release, desde que a saída realmente caiba no limite escolhido.

2. Ambientes de integração em segundo plano

Uma equipe de plataforma pode manter um servidor local, emulador ou ambiente de integração em execução como tarefa de background enquanto Claude trabalha em outra frente. Aumentar taskOutputMaxChars permite que Claude receba uma parte maior da saída recente ao consultar a tarefa. O arquivo completo ainda é importante porque, depois do estouro, a configuração prioriza os caracteres mais recentes.

3. Varreduras de avisos do compilador e do linter

Uma equipe de aplicações pode concluir um build com sucesso e, ao mesmo tempo, produzir milhares de avisos. Uma janela maior para comandos bem-sucedidos expõe alertas de pacotes que ficariam fora da prévia. Isso compensa quando a equipe está eliminando um backlog de warnings e valoriza mais o resultado completo do que uma sessão enxuta.

4. Simulações de migração de banco de dados

Uma pessoa da engenharia de dados pode executar um dry run bem-sucedido que imprime todas as alterações de schema propostas. Manter um plano de tamanho controlado inline permite que Claude compare mudanças relacionadas no mesmo resultado. A continuidade da revisão é a vantagem, mas somente depois de excluir segredos e identificadores de produção do log.

5. Auditorias de dependências e licenças

Uma pessoa da engenharia de segurança pode receber um inventário longo e bem-sucedido, com descobertas espalhadas pelo meio. Um limite do Bash definido no escopo do repositório pode disponibilizar todo o relatório delimitado em uma única sessão de auditoria. Assim, diminui o risco de um pacote passar despercebido apenas porque ficou fora da prévia.

6. Investigação de testes instáveis

Uma pessoa de QA precisa da sequência exata em torno de uma falha esporádica, mas o resultado do comando com erro mostra apenas um trecho do início e do fim. Aumentar a configuração do Bash não muda esse comportamento de falha. Salvar a nova execução em um arquivo conhecido e depois pesquisar por um intervalo restrito de tempo ou pelo nome do teste preserva a evidência sem lotar a sessão.

7. Geradores de código verbosos

Uma pessoa desenvolvedora pode precisar uma única vez do relatório completo de sucesso de um gerador, talvez para conferir todos os arquivos criados ou ignorados. Uma configuração local temporária amplia esse resultado durante a investigação e pode ser removida em seguida. O ganho é uma auditoria mais clara das alterações geradas, sem transformar uma exceção pontual em padrão permanente da equipe.

Para quem ainda está conhecendo a organização dos settings, o guia mais amplo sobre como usar Claude Code mostra onde a ferramenta se encaixa antes de você ajustar esse caso específico.

O que vale a pena construir

Melhor oportunidade: um broker de logs sensível ao contexto

Crie um wrapper local de comandos para equipes que programam com IA. Ele deve sempre armazenar o log bruto, medir a quantidade de caracteres, indexar os trechos importantes e devolver um manifesto compacto com os caminhos dos arquivos. A recomendação de limite inline por comando só deve aparecer quando a mesma evidência for recuperada repetidas vezes.

A demanda adjacente é pequena, mas tem valor comercial claro. Dados de palavras-chave dos EUA estimam 320 buscas mensais por log analyzer, com intenção transacional e custo por clique de $60.95. Os orçamentos existentes de observabilidade confirmam que já há compradores para tratamento de logs: a Better Stack informa um pacote de 40 GB de logs, traces e métricas por $25 ao mês com cobrança anual, além de chat de SRE com IA por $5 a cada milhão de tokens. Esses produtos atendem a uma necessidade mais ampla, mas os gastos mostram que equipes pagam para encontrar sinal em meio aos logs.

A versão mínima que já pode ser vendida reúne um wrapper multiplataforma, um diretório local de logs, um contador de caracteres, um índice de falhas e um relatório que Claude possa consultar de forma seletiva. O obstáculo é a confiança. Logs de build podem conter credenciais, dados de clientes e caminhos proprietários; portanto, armazenamento local por padrão e regras claras de remoção de dados sensíveis fazem parte do produto, não são mero acabamento. Essa é a oportunidade mais forte porque resolve a decisão recorrente por trás da configuração, em vez de apenas editar o JSON.

Oportunidade de nicho: um empacotador de evidências de testes

Crie um adaptador que execute frameworks de teste conhecidos, preserve o log sem alterações e entregue a Claude um mapa curto de evidências, com os nomes dos testes que falharam, os intervalos dos stack traces e o caminho do arquivo para inspeção detalhada. Equipes de QA e de experiência de desenvolvimento pagariam por isso quando uma única suíte ruidosa gera o mesmo trabalho de triagem todos os dias.

A consulta test failure analysis recebe uma estimativa de 20 buscas mensais nos EUA, com baixa concorrência e dificuldade de palavra-chave 11. Não é demanda suficiente para vender um SaaS independente e amplo. É, porém, o bastante para justificar uma função específica dentro do broker de logs ou uma ferramenta paga para equipes com suítes de teste caras.

Um MVP precisa de adaptadores para dois ou três executores, armazenamento determinístico do log bruto e uma visualização lado a lado das evidências extraídas e das linhas de origem. O problema é a fragmentação: Jest, Pytest, Gradle e runners próprios apresentam falhas de maneiras diferentes, e um extrator confiante demais pode remover justamente a pista de que Claude precisava. O arquivo bruto deve estar sempre a uma leitura de distância.

Quando essa configuração não ajuda

Esse controle não compra mais mensagens do Claude, não eleva a franquia semanal, não amplia a janela de contexto do modelo e não contorna o limite de uso de ferramentas. Ele apenas muda o tratamento de caracteres inline em dois caminhos de resultados locais do Claude Code.

Também não torna segura uma saída ilimitada. Outputs de comandos bem-sucedidos salvos pelo Claude Code são truncados depois de 64 MiB, e o comando é encerrado se o fluxo ultrapassar 5 GB. Mais importante: um resultado inline de 128,000 caracteres pode expulsar contexto útil da conversa. O máximo é uma proteção, não uma recomendação.

Sessões na nuvem acrescentam uma armadilha de escopo. Elas leem um .claude/settings.json incluído no commit, mas não os arquivos de settings locais ou de usuário da sua máquina. Só configurações organizacionais gerenciadas no servidor chegam a essas sessões. Se um valor parecer ignorado, confira /status antes de alterá-lo novamente.

Se você quer um fluxo de desenvolvimento sensível ao contexto e integrado aos seus próprios sistemas de testes e logs, o melhor ponto de partida são os sistemas de IA em produção.