Claude Opus 4.7 com contexto de 1M: dá para ler um repo inteiro?

Mas a palavra-chave é orçamento. O contexto não é ocupado só pelos arquivos .py, .ts, .java ou equivalentes. Também entram na conta:

• instruções do usuário;
• system prompt e regras da aplicação;
• histórico da conversa;
• resultados de ferramentas;
• mensagens de erro;
• logs de CI;
• stack traces;
• testes e saídas de comandos;
• espaço necessário para a resposta final.

Ou seja: 1 milhão de tokens é uma janela enorme, mas ainda é uma janela com borda.

Três condições para ler um repo de uma vez

1. Tudo precisa caber no mesmo orçamento

Não basta somar apenas os arquivos-fonte. A tarefa completa precisa caber: código, configuração, documentação relevante, instruções, resultados de busca, logs e qualquer contexto adicional que você queira que o modelo considere.

2. É preciso reservar espaço para a resposta

O Opus 4.7 pode gerar até 128 mil tokens de saída. Se você quer um relatório de auditoria, um plano de refatoração, uma análise arquivo por arquivo ou um patch grande, não faz sentido preencher a janela de entrada até o último token. A resposta também precisa respirar.

3. A contagem precisa ser feita com o tokenizer do Opus 4.7

A Anthropic afirma que o novo tokenizer do Opus 4.7 pode usar aproximadamente de 1x a 1,35x tokens para processar o mesmo texto em comparação com modelos anteriores, e que o endpoint /v1/messages/count_tokens retornará uma contagem diferente da usada no Opus 4.6. Portanto, estimativas antigas ou baseadas só em número de caracteres podem enganar.

O que as fontes oficiais sustentam

Por que “repo inteiro” pode ser uma armadilha

Um repositório real raramente é só o código que importa. Ele pode conter artefatos de build, snapshots, arquivos minificados, pastas vendor, dependências copiadas, documentação duplicada, fixtures enormes, cache, logs antigos e arquivos gerados automaticamente.

Colocar tudo isso no prompt pode até caber em 1 milhão de tokens, mas ainda assim ser uma má ideia. O modelo terá de gastar atenção e orçamento com material pouco útil, enquanto o que realmente importa — arquitetura, pontos de entrada, testes, dependências internas e mudanças recentes — pode ficar diluído.

Por isso, a pergunta mais útil não é “cabe o repo inteiro?”, mas sim: qual é o menor conjunto de arquivos que permite responder bem à tarefa?

E a tal estabilidade em tarefas longas?

Dá para ser otimista, mas não absoluto.

A Anthropic descreve o Opus 4.7 como adequado para fluxos agentic complexos, trabalho de longa duração e codebases maiores. Também afirma, no anúncio do modelo, que ele lida com tarefas complexas e longas com rigor e consistência.

Isso apoia uma conclusão moderada: o Opus 4.7 foi posicionado oficialmente como um modelo mais forte para tarefas longas, fluxos com agentes e projetos de código maiores. Mas não prova que qualquer repo, em qualquer linguagem, com qualquer volume de ruído, será analisado perfeitamente em uma única rodada.

Para uso sério — auditoria de segurança, refatoração grande, correções automáticas em CI/CD ou agentes rodando por muito tempo — o ideal é validar no seu próprio repositório, com testes reais e casos de falha conhecidos.

Um fluxo prático para analisar um repo grande

1. Comece pelo mapa do projeto

Antes de enviar arquivos em massa, gere uma visão geral: diretórios principais, linguagens, pontos de entrada, módulos críticos, testes, configuração, dependências e mudanças recentes. Isso ajuda a separar o que é essencial do que é ruído.

2. Exclua o que quase nunca ajuda

Em geral, vale deixar fora da primeira rodada:

• artefatos de build;
• arquivos gerados;
• dependências em vendor ou equivalentes;
• logs gigantes;
• caches;
• bundles minificados;
• arquivos duplicados;
• documentação que não afeta a tarefa.

3. Recalcule tokens com o Opus 4.7

Não reaproveite a contagem de outro modelo. Como o tokenizer do Opus 4.7 pode usar até cerca de 1,35x tokens para o mesmo conteúdo, a estimativa precisa ser feita com a contagem própria do modelo.

4. Não use o 1 milhão até o limite

Mesmo que caiba, lotar a janela pode ser ruim. Se a resposta esperada for longa — por exemplo, uma revisão detalhada, uma lista de riscos ou um patch — deixe espaço para a saída. O limite de saída do Opus 4.7 chega a 128 mil tokens, e isso deve entrar no planejamento.

5. Para monorepos, trabalhe em etapas

Em projetos grandes, uma abordagem mais robusta costuma ser:

1. pedir ao modelo uma leitura arquitetural;
2. identificar áreas relevantes;
3. buscar referências e chamadas entre módulos;
4. analisar arquivos críticos;
5. confrontar hipóteses com testes e logs;
6. só então pedir correções, plano de mudança ou relatório final.

Essa estratégia combina melhor com a forma como a Anthropic posiciona o Opus 4.7: tarefas complexas, fluxos agentic e codebases maiores.

6. Peça transparência sobre a cobertura

Ao final, vale exigir que a resposta diga explicitamente:

• quais arquivos foram considerados;
• quais não foram lidos;
• quais suposições foram feitas;
• quais riscos ficaram em aberto;
• quais testes devem ser executados;
• quais pontos exigem revisão humana.

Isso não garante que a análise esteja perfeita, mas reduz o risco de confundir “o modelo viu bastante contexto” com “o modelo entendeu o repo inteiro”.

Veredito

Sim: o Claude Opus 4.7 pode, em alguns casos, analisar um repo inteiro de uma vez. Ele tem suporte oficial a 1 milhão de tokens de contexto e até 128 mil tokens de saída.

Mas a resposta correta é condicional. Se o repositório, as instruções, os resultados de ferramentas, o histórico e a margem para a resposta couberem no orçamento, a abordagem pode funcionar. Se o projeto for grande demais ou barulhento demais, a melhor prática continua sendo selecionar arquivos, dividir a análise em etapas e validar as conclusões com testes reais.