Mantenha o contexto da sessão do Claude Code abaixo de 60% para reduzir custos
TuBrief 편집팀
2026년 4월 13일
0
Computing/Software원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
커뮤니티의 다른 글
댓글 (0)
Log in to leave a comment
아직 작성된 글이 없습니다
원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
Você não deve permitir que o Claude Code vasculhe toda a pasta do projeto. À medida que o número de arquivos aumenta, a ocupação inicial do contexto sobe, o que afeta diretamente o seu bolso. Analisando os casos de uso do Model Context Protocol (MCP) divulgados pela Anthropic, é possível economizar mais de 30% no consumo de tokens ao consultar apenas as definições de tabela necessárias, em vez de fazer uma inserção de texto simples.
O método é simples. Crie um arquivo .mcp.json na raiz do projeto e digite o seguinte comando no terminal:claude mcp add db -- npx -y @bytebase/dbhub
Agora, conecte diretamente o PostgreSQL ou MongoDB. Você deve deixar claro para o Claude: "Não leia todo o esquema, busque apenas o DDL das tabelas relacionadas à função que estou corrigindo agora". Ao ler apenas dezenas de linhas necessárias em vez de milhares de linhas de esquema, você mantém o custo por sessão abaixo de 1 dólar e aumenta a precisão das respostas.
Fenômenos de alucinação, onde o agente para de escrever código e começa a falar bobagens, pioram quando não há restrições físicas. Mesmo quando o contexto está cheio e o julgamento fica nublado, o código de teste atua como um oráculo preciso. Na prática, estabelecer um loop de feedback automatizado reduz o tempo de depuração manual em mais de 5 horas por semana.
Primeiro, use o comando /test para fazer o agente escrever o código de teste que falha para a funcionalidade a ser implementada. Em seguida, configure um hook PostToolUse para rodar os testes toda vez que um arquivo for alterado. O ponto crucial aqui é forçar o agente: "Não toque no código de teste, escreva apenas a lógica mínima no corpo para passar neste teste". Não há necessidade de copiar e colar mensagens de erro manualmente. Se você deixar que ele veja e corrija os próprios erros, a integridade do código pronto para implantação sobe para 95%.
À medida que a conversa em uma sessão do Claude Code se prolonga, os resultados de execuções de ferramentas passadas se acumulam, fazendo os custos dispararem. Quando o contexto ultrapassa 70%, ocorre o fenômeno de "drift", onde ele esquece o que foi dito no início ou gera códigos desconexos. Eu limpo a sessão à força no ponto de 60%, quando a barra de contexto fica amarela.
Não se trata apenas de desligar. Crie um arquivo HANDOFF.md. Peça para ele resumir as decisões tomadas até agora e as tarefas pendentes. Depois, limpe a sessão com /clear e recomece. Basta fazer com que ele leia o HANDOFF.md recém-criado. Ao usar modelos de alto desempenho como o Claude 3.5 Sonnet, isso reduz pela metade o custo pago por históricos passados desnecessários, mantendo o fluxo de trabalho intacto.
O conhecimento do Claude está estagnado no momento em que foi treinado. Ao lidar com frameworks como o Next.js App Router, cujas sintaxes mudam frequentemente, o agente escrever códigos antigos é puramente culpa do usuário. Copiar e colar a documentação oficial é um desperdício de tokens e um incômodo.
Instale um MCP de busca de documentos com o comando claude mcp add context7. No prompt, basta especificar a versão, como "use context7 to fetch the latest NextAuth v5 documentation". Faça-o escrever o código consultando as especificações da API extraídas em tempo real. Isso pode eliminar mais de 40% do tempo desperdiçado com sintaxes obsoletas.
Ao confiar uma lógica de negócios complexa, o agente tende a sair escrevendo código primeiro. Se houver um buraco lógico, ele gastará dezenas de milhares de tokens extras tentando corrigi-lo. Você deve economizar esse custo implementando antecipadamente via prompt a capacidade de raciocínio estendido do Claude 4.5.
No arquivo CLAUDE.md, escreva: "Antes de escrever o código, explique primeiro a lógica passo a passo dentro de tags <thinking>". Peça para listar 3 possíveis situações de exceção primeiro e fixe o processo para que ele só comece a modificar os arquivos após você aprovar essa lógica. Gastar algumas centenas de tokens a mais para ver o processo de inferência é muito mais econômico do que desperdiçar dezenas de milhares corrigindo uma lógica errada. Não existe estratégia de orquestração melhor para um desenvolvedor solo.