Redução da Cota do Claude Code: Os Agentes Estão Criando Novas "Montanhas de Código Herdado"?

A extensão da cota semanal do Claude Code atrai atenção; artigo analisa o mecanismo de consumo de tokens dos agentes. A execução prolongada de agentes leva ao crescimento contínuo do conjunto de trabalho, com cada etapa acumulando o estado histórico, além do fato de que mesmo após acertos de cache, os dados ainda ocupam contexto, resultando em custos computacionais que aumentam acumulativamente. Limpezas excessivas provocam “falhas semânticas”, forçando o agente a recuperar informações novamente. O artigo aponta que essa inconsistência entre o estado do código e a precisão da salvaguarda do estado de design pode levar à geração de “código legado” pela IA: agentes subsequentes não conseguem compreender as causas e efeitos do código inicial, acabando por formar códigos complexos com filas, contornos e tentativas que se compensam mutuamente.

Autor e fonte do artigo: LeiFeng.com

O código foi realmente escrito pelo Agent, mas os Agents posteriores já não sabem por que o Agent anterior o escreveu assim.

O bônus de 50% na cota semanal do Claude Code, originalmente programado para terminar em 19 de agosto, foi estendido pela Anthropic até 31 de agosto. Por volta da data limite original, surgiu uma discussão no Hacker News sobre o custo de uso do Claude Code: muitos descobriram que uma tarefa não tão complexa, quando executada em várias rodadas pelo Agente, consome rapidamente a cota.

O problema é que o Claude Code não consome apenas as poucas linhas de código geradas finalmente. Ler arquivos, buscar cadeias de chamadas, executar testes e processar logs — cada etapa continua a entrar no contexto subsequente. Quanto mais longa a tarefa, mais pesado o histórico que o Agente carrega, e mais o sistema depende de limpeza e compactação.

O código pode permanecer inteiramente no repositório, mas as razões originais de design podem se tornar cada vez mais tênues à medida que são comprimidas. Assim, o consumo de tokens e a dívida técnica começam a convergir no mesmo local.

Os limites de cálculo do Chat coding comum são claros. Insira um trecho de código, o modelo o lê e fornece uma explicação ou uma proposta de modificação; esse ciclo basicamente termina.

A unidade básica do Claude Code foi alterada para um loop de agente. O modelo primeiro observa o estado atual, decide qual arquivo ler ou qual comando executar em seguida; após a ferramenta retornar o resultado, o modelo realiza uma nova avaliação.

Ler o código-fonte, pesquisar referências, executar testes, visualizar o Git diff e modificar arquivos parecem ser um único processo contínuo, mas na verdade são uma série de solicitações de inferência independentes do modelo. A documentação oficial do Claude Code também apresenta esse ciclo de “julgamento do modelo — chamada de ferramenta — julgamento contínuo com base nos resultados” como o núcleo do funcionamento do Agente.

Por exemplo, um problema ocasional de perda de estado de login. O agente primeiro localiza a entrada e descobre que o estado vem do serviço, então continua lendo o serviço; ao ver o cache, busca quem o está escrevendo; em seguida, executa testes, mas o teste revela outra exceção, então analisa o fixture; após corrigir, valida novamente, e o teste antigo revela um problema de compatibilidade.

É possível que só agora ele tenha realmente começado a escrever aquelas linhas de código. Portanto,diff não existe uma proporção estável entre o tamanho e a quantidade de cálculo. Por trás de um patch de 5 linhas, podem haver apenas 3 inferências, ou já terem ocorrido 30 interações com ferramentas.

Se uma tarefa de Agent for dividida, é possível obter duas variáveis: uma é o step count, o número de passos que o Agent deu para concluir a tarefa; a outra é o working set, o número de itens de estado que o modelo ainda precisa conhecer ao chegar a este passo atual.

Apenas aumentar o número de etapas já aumentará o consumo. Se o working set continuar a crescer em sincronia, a situação será totalmente diferente. A etapa 3 pode precisar processar apenas milhares de tokens, mas a etapa 30 já pode estar carregando as regras do projeto, o código-fonte relacionado, os resultados dos testes, o histórico de modificações e as ferramentas para continuar o raciocínio.

Este também é o ponto de partida para a mudança na estrutura de custos do Coding Agent: o cálculo passa a depender de “quantos passos dar × quanto peso carregar em cada passo”, e não mais de quantas linhas de código foram escritas.

Dividir uma única solicitação de modelo do Agent pode ser aproximadamente vista como três partes. As partes relativamente estáveis incluem o prompt do sistema, CLAUDE.md, definições de ferramentas e regras do projeto; as partes em constante mudança incluem arquivos de código, resultados de pesquisa, logs de teste, Git diff e a trajetória das tarefas anteriores; por fim, há o raciocínio, texto e código gerados nesta rodada do modelo.

Existe um equívoco comum aqui: como o conteúdo anterior já foi lido, não deveria gerar custos repetidos. O problema é que, entre duas requisições de LLM, não existe uma memória interna acessível como em programas tradicionais. Se a próxima rodada ainda depender das informações da rodada anterior, esses estados relacionados precisam continuar presentes no contexto disponível.

O cache de prompt pode aliviar esse problema. A documentação oficial do Claude Code esclarece que, sem cache de prompt, cada solicitação precisa processar novamente todo o histórico; após um acerto no cache, os prefixos estáveis já processados podem ser reutilizados, reduzindo o cálculo repetitivo e os custos.

Mas o cache resolve “se o mesmo histórico pode ser reutilizado mais barato”, mas não resolve “se esse histórico ainda deve continuar existindo”. Após o estado antigo de 100K Token acertar o cache e se tornar mais barato, ele ainda ocupa o contexto e continua sendo o estado sobre o qual a inferência atual é construída.

Então, uma tarefa longa pode ser aproximadamente escrita como: a escala de entrada na etapa t é aproximadamente igual ao prefixo estável S, mais o conjunto de trabalho ativo atual W_t, mais as novas informações geradas nesta rodada Δ_t.

O verdadeiro problema é W_t. Se a cada passo, o Agente lê mais código-fonte, obtém mais logs e deixa mais decisões, e as informações antigas não são removidas a tempo, então W_t aumentará continuamente à medida que a tarefa avança.

In a highly simplified model with no caching or cleanup whatsoever, if the number of new valid states added per round is roughly constant, the total processed volume will exhibit a cumulative structure approaching 1 + 2 + 3 + … + n. That is, while the step count only doubles, the total historical states processed may increase much faster.

O sistema real possui cache, edição de contexto e compactação, e não segue mecanicamente essa curva de crescimento, mas a forma do problema não muda: quanto mais tempo o Agente operar, mais provável é que cada novo movimento se baseie em um histórico cada vez mais pesado.

Então, o prompt do usuário, que é muito curto na tarefa longa, perde rapidamente sua relevância. O que realmente começa a dominar os custos é o conjunto de trabalho que o modelo carrega continuamente para manter a continuidade da tarefa.

Por que o conjunto de trabalho está crescendo tão rápido? A saída da ferramenta é uma grande fonte. O código-fonte tem pelo menos estrutura; os logs frequentemente não têm.

Uma grep pode retornar centenas de referências, uma construção pode gerar grandes quantidades de avisos, uma falha de teste pode trazer toda a stack trace, e Docker, compiladores e gerenciadores de pacotes também produzem grandes volumes de texto sem valor duradouro para a tarefa.

Suponha que o teste na etapa 10 gerou 8K tokens de log. Quando entraram no contexto pela primeira vez, eram apenas 8K tokens. No entanto, o agente ainda precisa continuar verificando o código-fonte, fazendo alterações e retestando; enquanto esse log permanecer no histórico válido, ele aumentará o peso básico de muitas solicitações subsequentes.

Isso é muito semelhante ao write amplification nos sistemas de armazenamento: uma única gravação lógica causa mais processamentos subjacentes subsequentes. No caso do Agent, uma saída de ferramenta é gravada no histórico de execução e, em seguida, movida junto com a inferência subsequente.

Assim, o mesmo token 8K, quando colocado na rodada anterior ao término da tarefa ou no início da tarefa, tem um impacto total completamente diferente. O Claude Code agora também está reduzindo ativamente essa contaminação. A recomendação oficial é usar sub-agents para isolar tarefas de alta saída e menciona explicitamente que resultados de pesquisa, logs e grande quantidade de conteúdo de arquivos consomem o contexto da sessão principal; a própria definição das ferramentas também ocupa espaço, portanto, um conjunto de ferramentas muito grande também aumenta a carga de estado.

Mas aqui surge outro problema inverso: não se pode eliminar todos os logs apenas porque são caros. Em um log de 3.000 linhas, apenas 20 linhas podem estar relacionadas à causa raiz. O sistema não sabe antecipadamente quais são essas 20 linhas. Se a limpeza for feita muito cedo, o agente poderá precisar, mais tarde, de um desses detalhes e terá de executar o teste novamente ou reabrir o arquivo.

Isso pode ser chamado de falha de página semântica. Na memória virtual tradicional, quando um programa acessa uma página que já não está na memória, o sistema recarrega-a do disco; após descartar certas evidências anteriores, o Coding Agent também experimenta fenômeno semelhante, apenas manifestado como nova busca no repositório, leitura repetida de arquivos, execução novamente de comandos ou até mesmo a rederivação de um problema já analisado anteriormente.

Assim, a tarefa longa cai em um dilema: manter muitos históricos torna cada passo subsequente cada vez mais pesado; limpar de forma muito agressiva faz com que o agente constantemente recupere informações já vistas anteriormente.

Isso também explica por que o gerenciamento de contexto não pode ser simplificado como “inserir menos tokens”. O que realmente precisa ser resolvido é a seleção do conjunto de trabalho: quais informações devem permanecer no espaço de trabalho agora e quais são apenas produtos intermediários que já cumpriram sua função.

At this point, compaction, memory, and sub-agent truly have a reason to exist.

Quando o Claude Code se aproxima do limite de contexto, ele compacta automaticamente a sessão e também limpa alguns resultados de ferramentas mais antigos. O oficial também alerta que conversas irrelevantes, conteúdo de arquivos e resultados de comandos em sessões longas podem preencher a janela e interferir no desempenho do modelo.

Do ponto de vista do sistema, a compaction é semelhante a uma coleta de lixo semântica. O problema é que a coleta de lixo comum avalia se “este objeto ainda tem referências”, enquanto o Agente precisa determinar se “esta informação ainda terá significado no futuro”.

O segundo é muito mais difícil. Por exemplo, houve esta conclusão de design no início: um módulo não pode armazenar em cache o estado do usuário por conta própria, pois o sistema exige que o estado tenha apenas um proprietário e todas as modificações devem passar pelo serviço.

Depois de algumas etapas, se essa informação for resumida como: "O problema de estado foi resolvido anteriormente por meio da chamada do serviço." O fato não está errado, mas a informação já mudou. O conteúdo original contém uma constraint, enquanto o resumo posterior armazena apenas um event.

Na próxima vez que o Agente enfrentar um problema de desempenho e observar que as chamadas de serviço estão lentas, provavelmente adicionará novamente um cache no módulo. Ele não está violando as informações que atualmente possui; a relação causal que proibia o cache já não está mais em vigor.

O documento de contexto do Claude Code especifica claramente que algumas regras com escopo de caminho e os CLAUDE.md aninhados são compactados e resumidos junto com a sessão, e precisam ser lidos novamente para recarregar os arquivos correspondentes.

Memory tenta resolver o problema da preservação de conhecimento de longo prazo. Os arquivos CLAUDE.md e auto memory no diretório raiz do projeto podem extrair conteúdo como comandos de construção, especificações do projeto e experiências de depuração das conversas de curto prazo e recarregá-los no início da sessão. Mas a Anthropic também esclarece claramente sua posição: esses memory ainda são contextos e não são configurações obrigatórias.

Essa diferença é crucial. Se “não é possível acessar o banco de dados diretamente aqui” for escrito apenas na memória, ainda é uma frase em linguagem natural que o modelo precisa entender e seguir. Se a mesma regra for implementada como lint de dependência, restrição de tipo ou verificação CI, então se torna um invariant de software que não pode ser facilmente contornado.

O sub-agente resolve outro aspecto: isolamento do conjunto de trabalho. Delegar a um agente independente a tarefa de escanear um repositório ou analisar logs longos, e depois retornar ao agente principal apenas os resultados compactados, evita que o ruído original entre na linha principal. Um dos usos oficiais do sub-agente pelo Claude Code é o isolamento de contexto.

O custo também é interessante: o Agent principal obteve um estado mais limpo, mas perdeu parte da evidência original; múltiplos Agents rodando simultaneamente criam seus próprios contextos. Portanto, ao analisar compactação, memória e sub-agents juntos, eles já se parecem muito com uma hierarquia de memória da era dos Agents:

O contexto atual é memória de trabalho cara, a compactação é responsável por comprimir, a memória mantém o estado entre sessões e os sub-agentes isolam o ruído em espaços de endereço independentes. O problema também passou de “o contexto é grande o suficiente?” para outro nível:

Quais estados precisam ser salvos com alta fidelidade e quais estados precisam apenas de um resumo? Essa questão afetará diretamente a qualidade do código posterior.

Após compreender a estrutura de execução anterior, ao analisar o limite semanal do Claude Code, percebe-se que é difícil para a plataforma continuar medindo o Agente com base em "número de mensagens", pois uma única mensagem perdeu seu significado estável.

Mudar o nome de uma variável é uma mensagem; refatorar todo o módulo de autenticação também é uma mensagem. A primeira pode ser concluída em poucos passos, enquanto a segunda pode executar dezenas de ciclos, ler dezenas de arquivos e iniciar vários Agentes. O mesmo request pode ter necessidades de recursos completamente diferentes por trás.

Claude Code embala isso com limites de rolagem e cota semanal; o Codex agora calcula créditos claramente com base em tokens de entrada, tokens de entrada em cache e tokens de saída; os planos do Cursor fornecem diferentes pools de uso para Agentes, e o consumo de modelos de terceiros é afetado pelos preços da API do modelo.

Os idiomas da interface de três produtos são diferentes, mas os problemas subjacentes a serem resolvidos são muito semelhantes: como alocar recursos de raciocínio para um programa inteligente cujo caminho de execução não pode ser determinado antecipadamente. É difícil prever por quanto tempo um Coding Agent irá executar no início da tarefa.

O modelo pode rapidamente identificar a causa raiz ou fazer várias suposições incorretas consecutivas; pode passar no teste na primeira tentativa ou entrar em um loop de debug prolongado; pode precisar apenas de um agente ou dividir-se em vários sub-agentes.

As APIs tradicionais gostam de cobrar por requisição, porque a variação de recursos de uma única requisição ainda pode ser mantida dentro de um limite. O Agente dispersa essa estabilidade. Por isso, o Token começa a ter um pouco do caráter de tempo de CPU.

Essa analogia não pode ser equiparada. Modelos diferentes têm custos de computação distintos para processar a mesma quantidade de tokens, e os custos variam entre input, input em cache e output. Mas do ponto de vista do desenvolvedor, suas funções estão se tornando cada vez mais semelhantes: todas descrevem quanto recurso computacional é consumido para continuar a execução de uma tarefa.

Quando a Anthropic aumentou o limite de uso do Claude Code este ano, também ligou diretamente o aumento de cota ao aumento da capacidade de computação. Isso trará uma mudança interessante no indicador. Anteriormente, ao avaliar Agentes de Codificação, era comum comparar “quem resolveu bem um problema em uma única tentativa”. A partir de agora, pode ser mais significativo: quem consome menos cálculo efetivo para alcançar a mesma mudança de estado de projeto.

Se um Agent gastar uma grande quantidade de Token apenas repetindo a abertura de arquivos, a execução de testes novamente e a recuperação de contextos já perdidos, esses Token não resultam em um avanço de engenharia proporcional.

E esse tipo de recuperação ineficiente acaba encontrando-se com a dívida técnica no nível inferior.

Aqui, pode-se abstrair um software mantido por um Coding Agent como dois conjuntos de estados que evoluem simultaneamente. Um deles é o estado do código R_t. Arquivos, tipos, interfaces, testes e commits do Git pertencem a este nível. A linha adicionada pelo Agent no passo 20, retry, permanece intacta no passo 100, desde que não tenha sido excluída. O código mantém uma precisão muito alta na preservação das modificações passadas.

Outro conjunto é o estado de design M_t. Por que aqui é necessário retry, por que esse cache só pode estar no serviço, por que esse estado não pode ter dois proprietários, por que essa verificação aparentemente desnecessária não pode ser removida temporariamente — essas informações pertencem à causalidade do design.

M_t Não há armazenamento intrinsecamente sem perdas, como no Git. Ele está disperso em conversas, raciocínio, respostas de ferramentas, memória, arquivos de regras e resumos de compactação. À medida que as tarefas avançam, algumas partes são limpas, outras são resumidas e algumas precisam ser recuperadas novamente.

Isso gera uma assimetria crítica: os resultados alcançados podem ser acumulados com alta fidelidade, mas as relações causais que geram esses resultados são continuamente subamostradas. Isso é muito mais grave do que simplesmente dizer que “o agente esquece coisas”.

Em caso de um problema de concorrência, após análise, o Agente adicionou uma fila. Naquele momento, sua conclusão completa era: apenas o caminho de escrita A apresentava competição, portanto, a fila só poderia abranger A; o caminho de escrita B exige baixa latência e não pode entrar nessa fila.

O código salvou completamente a fila. Após longa execução, o estado do design pode ter se reduzido apenas a “usar a fila para resolver race condition”.

Posteriormente, B também apresentou um erro ocasional. Ao ler novamente o código, o agente naturalmente integrou B à fila existente.

Em seguida, o atraso aumentou, então foi adicionado um bypass. O bypass gerou inconsistências de estado ocasionais, então foi acrescentado retry na periferia. Até aqui, nenhuma modificação era necessariamente absurda. Cada correção, no contexto local observado na época, até poderia parecer bastante razoável. Mas o código já havia se transformado de “um modelo de concorrência claro” em uma rede de queue, bypass e retry que se compensam mutuamente.

A montanha de código de IA provavelmente se forma assim. Ela não necessariamente se manifesta como o modelo de repente gerando um monte de lixo, mas mais provavelmente como acúmulos contínuos de correções locais, com o modelo geral gradualmente desaparecendo.

Em softwares tradicionais, esse tipo de problema geralmente se forma lentamente por meio de transferências de equipe. Quando o autor original sai, novos desenvolvedores veem o código antigo, mas não sabem por que ele existe, então acabam adicionando uma camada adicional de lógica de compatibilidade.

O Agente de Codificação transformou “troca de pessoal” em “troca de contexto”. Os passos 20 e 100 ainda parecem ser a mesma sessão do Claude Code, mas os estados de design obtidos já não são mais idênticos. Do ponto de vista da informação, parece mais dois engenheiros mantendo o mesmo repositório por meio de um documento de transferência que constantemente encolhe.

Os testes também só resolvem parte disso. Testes são bons em proteger comportamentos: a interface deve retornar o quê, certas entradas não podem causar falhas, bugs anteriores não podem reaparecer. Muitas restrições de arquitetura, porém, não se manifestam naturalmente como entradas e saídas.

O estado só pode ter um proprietário, a camada de domínio não pode depender reversamente da IU, um determinado pacote não pode se conectar diretamente ao banco de dados, operações de escrita devem passar por um limite de transação unificado; essas restrições, se existirem apenas em documentos ou na memória do agente, são facilmente ignoradas em correções locais.

O resultado é um estado de engenharia muito problemático: os testes ainda estão verdes, mas o código já está se tornando cada vez mais difícil de explicar. Ainda mais perigoso é que existe um loop de feedback aqui.

A arquitetura está começando a ficar confusa; o próximo agente para entender a funcionalidade precisará ler mais arquivos; quanto mais complexas as dependências, maior o conjunto de trabalho; quanto mais pesado o conjunto de trabalho, mais o sistema precisa ser limpo e compactado; quanto mais fraca for a preservação da causalidade do design, mais fácil será para as modificações futuras dependerem do código atual e dos testes locais.

Assim, a complexidade do código começa a aumentar o custo dos tokens, e a pressão sobre os tokens, por sua vez, incentiva a manutenção de estados mais curtos e correções mais locais. Este é o mecanismo mais preocupante por trás do “quanto mais iteramos, mais problemas aparecem” no agent coding.

Não é um problema de capacidade de um modelo isolado, mas sim um problema de sistema causado por inconsistência na precisão da salvaguarda do estado do código e do estado do design.

O Agente de Codificação já está se tornando cada vez mais capaz de agir por longos períodos, mas “conseguir funcionar por várias horas” por si só não é necessariamente um bom indicador de desempenho.

Se um agente trabalha por 3 horas e depois precisa reler um arquivo que modificou 2 horas atrás, raciocinar novamente sobre por que um certo abstrato existe e executar novamente testes já realizados anteriormente, então grande parte do cálculo nessas 3 horas foi gasto na recuperação de estado.

A próxima pergunta se tornará: Quantas informações causais valiosas para decisões futuras um agente ainda retém após 50 passos, 100 passos?

Você pode chamá-lo de fidelidade de estado.

Porque ele mede não quantos tokens o contexto pode conter, mas quantas informações de design essenciais ainda permanecem disponíveis após chamadas de ferramentas, compressão,跨越 sessões e recuperação de memória. Isso também significa que a memória de longo prazo do Agente não pode depender apenas de contextos mais longos.

Alguns conhecimentos são mais adequados para serem armazenados na memória, como formas de construção de projetos e hábitos de desenvolvimento; algumas decisões devem ser registradas em ADRs estruturados ou índices de código; enquanto aquelas cuja violação comprometeria os limites arquiteturais do sistema são mais adequadas para serem codificadas diretamente em tipos, testes, regras de lint, dependências e CI.

Uma regra que já se tornou uma restrição executável pelo software não precisa ser “lembrada” pelo Agente. Na próxima rodada, o Agente pode esquecer uma conversa, mas não pode contornar facilmente o compilador e os testes.

Se a taxa de fidelidade for baixa, quanto mais tempo o Agente operar, mais minas ele está enterrando no sistema.

Este pode ser também o limite que o Coding Agent precisa atravessar para passar de “saber escrever código” a “ser capaz de manter software a longo prazo”: migrar o conhecimento de design de uma memória linguística probabilística para um estado de software recuperável, verificável e executável.

Caso contrário, quanto mais tempo operar autonomamente, mais absurdo se tornará o cenário. O agente escreve código cada vez mais rápido, e o projeto muda rapidamente, mas a cada período, ele precisa novamente compreender o mundo deixado pelo período anterior.

Uma frase comum em código hereditário tradicional é: “Não toque nisso, não se sabe por que vai explodir.”

O código herdado de IA pode ser ainda mais estranho: o código foi realmente escrito pelo Agente, mas os Agentes posteriores já não sabem por que o Agente anterior o escreveu assim.