O material não cabe na conversa: como trabalhar com projetos grandes no Claude Opus

Chega um ponto em que o projeto para de caber na conversa, e você percebe antes de entender: a resposta esquece decisão que já foi tomada, mexe de novo em arquivo que já foi corrigido, cita caminho que não existe

Não é o modelo ficando burro, é a janela ficando cheia

O Claude Opus 5, lançado em 24 de julho de 2026, veio com 1 milhão de tokens de contexto como padrão e como máximo (não existe variante menor), até 128 mil tokens de saída e raciocínio ligado por padrão

Parece espaço infinito… e ainda assim volume demais degrada a resposta

Então bora ao que interessa: neste post eu mostro o fluxo de trabalho pra dividir código e documento longo, decidir o que fica na conversa e quando é hora de largar tudo e recomeçar de um resumo

Antes de começar: o que ocupa espaço na sua janela

Antes do passo a passo, dois entendimentos que mudam tudo

Os números do Opus 5 que importam aqui

• Janela de contexto de 1 milhão de tokens, sendo o padrão e o máximo
• Até 128 mil tokens de saída
• Raciocínio (thinking) ligado por padrão
• Na API da Anthropic: US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de tokens de saída

Repare no preço de saída: cada compactação, cada resumo, cada rodada de raciocínio sai do mesmo bolso, beleza? Contexto grande não é só risco de qualidade, é conta também

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Por que atenção se dilui conforme o contexto cresce

A Anthropic descreve o contexto como um recurso finito com retornos decrescentes: quanto mais tokens, mais difícil recuperar a informação certa

O nome disso na engenharia de contexto da Anthropic é context rot

O porquê é da própria arquitetura: o transformer cria relações par a par entre todos os tokens, então o orçamento de atenção vai sendo dividido entre cada vez mais coisa

Se você conhece consulta em banco sem índice, é uma sensação parecida: não é que o dado sumiu, é que achar ficou caro

A mesma documentação aponta três técnicas pra tarefa que estoura a janela: compactação (resumir perto do limite e recomeçar do resumo), notas estruturadas guardadas fora da janela, e arquitetura de subagentes em que o agente principal só recebe resumos condensados

O passo a passo abaixo é basicamente isso na unha

E se você constrói na API Claude, essas mesmas três ideias já aparecem com nome e recurso próprio na plataforma: context editing, memory tool e compactação server-side, que eu detalho mais pra frente

Tome cuidado: nem toda plataforma te dá 1M

Se você roda o Claude Code através de Amazon Bedrock, Google Cloud ou Microsoft Foundry, a sessão compacta no limite de 200K

E elevar o valor acima de 200K não levanta esse teto, porque o Claude Code respeita a janela do modelo

Já me poupou tempo saber disso antes de ficar mexendo em configuração achando que era bug

A ferramenta base: /context

No Claude Code, o comando /context mostra o que está ocupando espaço na janela de contexto da sessão

É o seu ponto de partida em qualquer investigação, e é o primeiro passo do fluxo

Como trabalhar com projetos grandes no Claude Opus: o passo a passo

Passo 1: meça com /context antes de culpar o modelo

/context

Antes de reclamar da qualidade, olhe o que está lá dentro: arquivo enorme colado no início, saída gigante de comando, histórico de tentativa que já não vale mais

O erro comum deste passo: partir direto pro "a IA piorou" sem nunca ter olhado a composição da janela

Passo 2: escolha onde a auto-compactação entra

No Claude Code, modelos com janela nativa de 1M (como Opus 5 e Sonnet 5) fazem auto-compactação antes de a janela encher, por volta de 967 mil tokens por padrão

Dá pra escolher outro ponto:

/autocompact 500k

Ou pela variável de ambiente:

CLAUDE_CODE_AUTO_COMPACT_WINDOW

O erro comum deste passo: deixar a compactação acontecer no pior momento possível, no meio de uma execução longa, em vez de escolher um ponto que faz sentido pro seu tipo de tarefa

Passo 3: comprima na hora certa com /compact

/compact

O /compact comprime o histórico da conversa em um resumo, e é disparado automaticamente quando a sessão se aproxima do limite

Usar na mão tem uma vantagem: você escolhe o momento em que a tarefa está num ponto redondo, com o passo anterior fechado

O erro comum deste passo: compactar no meio de uma depuração, quando o valor está justamente nas mensagens de erro que você acabou de coletar

Passo 4: compacte só um pedaço pelo rewind

Nem sempre você quer resumir a conversa inteira, e isso muita gente não sabe que dá

Aperte Esc duas vezes ou rode:

/rewind

Escolha um checkpoint de mensagem e use uma das duas opções:

• Summarize from here: comprime dali pra frente, preservando o contexto anterior
• Summarize up to here: comprime o que veio antes, mantendo as mensagens recentes inteiras

Dá pra orientar o foco do resumo antes de confirmar: destaque a opção de Summarize com as setas, digite as instruções na linha add context (optional) e pressione Enter

Se você escolher pela tecla numérica, ele resume na hora, sem instruções

E fica tranquilo: resumir pelo rewind não mexe nos arquivos em disco, e as mensagens originais continuam no transcript da sessão

O erro comum deste passo: apertar o número por reflexo e perder a chance de dizer o que o resumo precisa segurar

Passo 5: recomece limpo com /clear

/clear

O /clear reseta o contexto entre tarefas não relacionadas

E tem uma coisa que a própria documentação diz e que dói um pouco no ego: recomeçar com um prompt mais específico costuma render mais do que insistir numa sessão longa cheia de correção acumulada

Sessão longa vira histórico de erro, e histórico de erro compete por atenção com o código que interessa

A lógica é a mesma de trabalhar em dois projetos ao mesmo tempo sem misturar o contexto: assunto separado, janela separada

O erro comum deste passo: emendar tarefa nova na conversa velha só porque "já está tudo ali"

Passo 6: escreva o que não pode se perder

Compactação é resumo, e resumo perde coisa

Então o que é regra fixa do projeto não mora na conversa, mora em arquivo

No Claude Code, o CLAUDE.md guarda instruções e convenções do projeto, e é lido no início de toda sessão

Dá até pra customizar o comportamento da compactação escrevendo instruções dentro dele, tipo:

## Ao compactar

Sempre preservar a lista completa de arquivos modificados e os comandos de teste do projeto

Um limite pra você já contar com ele: a memória automática carrega apenas as primeiras 200 linhas ou 25KB do MEMORY.md, o que vier primeiro

Ou seja, arquivo de memória gigante não é memória, é ilusão de memória

E não é só texto: até no visual existe essa diferença entre baixar o resultado do Claude Design e deixar o material morar só na conversa

O erro comum deste passo: repetir a mesma convenção em todo prompt, em vez de escrever uma vez no arquivo que é lido sempre

Passo 7: delegue leitura pesada a subagentes

Subagentes rodam em janela de contexto própria, com system prompt e permissões próprias

Eles são definidos como arquivos markdown em .claude/agents/, e o Claude detecta e aciona automaticamente pela descrição

O detalhe que faz a diferença: a janela do subagente começa vazia, sem a conversa do agente principal

O único conteúdo que passa do pai pro subagente é a string de prompt da ferramenta Agent

Então caminho de arquivo, mensagem de erro e decisão já tomada precisam ir escritos ali dentro, senão o coitado vai descobrir tudo de novo do zero

O erro comum deste passo: mandar "corrige aquele bug que a gente viu" pro subagente, que nunca viu nada 😅

Código, documentos longos e API: onde cada estratégia se aplica

Código de projeto grande

Aqui o jogo é dividir por responsabilidade: cada leitura pesada vai pra um subagente com janela própria, e o agente principal fica com a coordenação

A configuração toda mora no diretório .claude, tanto o do projeto quanto o ~/.claude da pasta do usuário: é de lá que saem CLAUDE.md, settings.json, hooks, skills, comandos, subagentes e memória automática

O Opus 5 ainda oferece uma escada de esforço configurável com cinco níveis: low, medium, high, xhigh e max (o xhigh apareceu no Opus 4.7)

Em xhigh ou max, convém definir um max_tokens alto, senão o raciocínio bate no teto antes de entregar

Documentos longos

Pra documento comprido, a documentação recomenda envolver cada documento em tags XML e pedir citações antes da tarefa:

<document>
  <source>contrato-2026.pdf</source>
  <document_content>
  ...conteúdo do documento...
  </document_content>
</document>

Duas coisas simples que mudam o resultado: peça que o Claude cite antes os trechos relevantes, e coloque as instruções no fim do prompt pra maximizar a recuperação

É o mesmo raciocínio do índice: você não faz o modelo ler tudo com a mesma força, você faz ele apontar o que importa primeiro

Quem constrói na API Claude

Na plataforma de desenvolvedor tem três recursos que resolvem isso sem você programar na unha:

• context editing: limpa automaticamente chamadas e resultados de ferramentas antigos de dentro da janela quando ela se aproxima do limite, com a estratégia clear_tool_uses_20250919, ativada pelo campo context_management
• memory tool: deixa o Claude guardar e consultar informação fora da janela, em arquivos que persistem entre conversas (tipo memory_20250818, com o beta context-management-2025-06-27)
• compactação server-side: resume a conversa automaticamente, sem a complexidade de integração do lado do cliente

Os dois primeiros combinam bem: o context editing avisa o modelo pra salvar o que importa antes da limpeza

Na prática: como isso aparece em um projeto real

Esse papo de janela cheia parece abstrato até você rodar um plano grande de ponta a ponta

No vídeo eu mostro um projeto em que o plano de implementação saiu com 14 tarefas, e todas foram concluídas até o fim da execução

Uma dessas tarefas ficou quase 10 minutos rodando na minha máquina, sozinha

No fim, pra testar o app pronto, eu lancei uma despesa de R$ 1.000 em alimentação e vi o fluxo funcionando

Agora liga isso no tema: execução longa é exatamente o cenário em que o histórico incha rápido, com saída de comando, log de teste e ida e volta de correção

É ali que a decisão aparece: compactar agora, resumir só um pedaço pelo rewind, ou fechar e recomeçar do resumo com um prompt mais específico

O hábito que mais me ajudou foi deixar design e plano morando em arquivo, não na conversa, e delegar a execução a subagentes

Assim, quando a janela precisa ser limpa, o que importa não estava lá dentro pra se perder =)

No vídeo acima você vê esse fluxo rodando de verdade, das skills que eu uso pra estruturar o projeto até a execução do plano tarefa por tarefa

Próximo passo

Volume grande não se resolve com mais texto, se resolve com disciplina de contexto

O Opus 5 te dá 1 milhão de tokens de janela, mas o que decide a qualidade da resposta é o que você escolheu deixar lá dentro

O próximo passo é bem concreto, e cabe na sua próxima sessão pesada:

1. Rode /context antes de qualquer conclusão sobre qualidade
2. Escolha o ponto de auto-compactação com /autocompact em vez de aceitar o padrão
3. Mova as convenções fixas do projeto pro CLAUDE.md

Depois disso, resumir vira decisão consciente e não acidente no meio da tarefa

Até o próximo post! 🙂