O Uso de Energia do Claude Code Expõe o Custo Oculto dos Agentes de IA

O uso de energia do Claude Code atingiu uma estimativa de 170 quilowatt-hora durante o experimento de oito semanas de um pesquisador, apesar dos ganhos de eficiência na infraestrutura moderna de IA.

O cientista climático Zeke Hausfather acompanhou 1.138 instruções enviadas por meio do agente de programação da Anthropic. Essas instruções acionaram mais de 14.000 chamadas ao modelo e processaram 3,2 bilhões de tokens. Sua estimativa central equivale a cerca de 150 watt-hora por prompt humano.

Essa estimativa é aproximadamente 600 vezes maior do que o número publicado para a energia consumida por um prompt de texto típico do Gemini. O contraste desafia uma ideia reconfortante sobre inteligência artificial: a de que um prompt é uma unidade significativa para medir consumo.

Um agente de IA não apenas responde e para. Ele planeja, chama ferramentas, lê resultados, revisita seu contexto de trabalho e tenta novamente. Portanto, uma solicitação pode iniciar uma longa cadeia de computação que permanece em grande parte invisível para o usuário.

Esse é o verdadeiro conflito por trás do mais recente debate sobre energia de IA. Google e outros provedores tornaram respostas individuais notavelmente eficientes. Ao mesmo tempo, produtos agênticos estão transformando cada instrução do usuário em muitas respostas, chamadas de ferramentas e leituras repetidas de contexto.

O resultado não prova que todo agente de IA desperdiça eletricidade. Ele indica que comparações familiares por prompt já não descrevem uma categoria crescente de trabalho com IA. Desenvolvedores, compradores empresariais e planejadores de infraestrutura agora precisam de métricas baseadas em tarefas concluídas.

O Uso de Energia do Claude Code Muda a Unidade de Medida

A mudança importante não é o lançamento de um novo modelo. É a evidência de que um prompt humano pode ocultar todo um fluxo de trabalho computacional.

Hausfather examinou sua atividade no Claude Code de 31 de maio a 25 de julho de 2026. O Claude Code é um sistema de programação agêntico, o que significa que ele pode planejar e executar uma sequência de ações com orientação humana limitada.

Durante essas oito semanas, Hausfather inseriu 1.138 prompts. Seus registros apontaram mais de 14.000 chamadas separadas ao modelo, uma média de cerca de 12 chamadas para cada prompt que ele digitou.

As sessões processaram 3,2 bilhões de tokens. Tokens são as unidades que um modelo de linguagem lê e gera ao lidar com texto, código, instruções e contexto armazenado.

Hausfather estimou que a carga de trabalho consumiu cerca de 170 quilowatt-hora de eletricidade de data center. Seu intervalo de incerteza foi de aproximadamente 70 a 330 quilowatt-hora, pois a Anthropic não publica medições diretas de energia para cada chamada ao modelo.

A estimativa central resultante foi de aproximadamente 150 watt-hora por prompt humano. O intervalo plausível ficou entre 60 e 290 watt-hora.

Em comparação, o Google relatou que um prompt de texto mediano do Gemini Apps consumiu 0,24 watt-hora em seu ambiente de produção. Esse número incluiu a energia dos aceleradores, sistemas host, capacidade ociosa e overhead do data center.

As medições de produção do Google não são necessariamente incompatíveis com os cálculos de Hausfather. Elas descrevem um tipo diferente de atividade.

Um prompt de texto do Gemini pode gerar uma resposta concisa. Uma instrução no Claude Code pode iniciar uma sessão envolvendo pesquisa, geração de código, execução de comandos, depuração e avaliação repetida.

Essa distinção explica por que Hausfather argumenta que um prompt se parece mais com uma viagem do que com uma distância fixa. Contar viagens diz pouco a um analista, a menos que ele também saiba para onde cada viagem foi.

Sua sessão mediana no Claude Code consumiu uma estimativa de 0,6 quilowatt-hora. O intervalo plausível foi de 0,25 a 1,2 quilowatt-hora. Seu dia médio de trabalho chegou a uma estimativa de 3,0 quilowatt-hora.

O dia mais intenso atingiu uma estimativa central de 11 quilowatt-hora. Nesse dia, vários agentes paralelos trabalharam em uma grande análise geoespacial.

Esses números vêm de um único usuário excepcionalmente intensivo, não de uma amostra representativa de todos os clientes do Claude Code. Hausfather trabalha com dados climáticos complexos e se descreve como um usuário mais intenso do que a maioria das pessoas.

Ainda assim, o experimento identifica uma falha de medição que vai além de um pesquisador. O usuário vê uma instrução, enquanto a infraestrutura processa uma série ramificada de eventos computacionais.

A mudança importa porque as empresas cada vez mais comercializam agentes como substitutos para fluxos de trabalho completos. Se a promessa do produto diz respeito ao trabalho concluído, sua contabilização de recursos também deve medir o trabalho concluído.

Por Que os Agentes de IA Consomem Mais do Que Chatbots

Os agentes multiplicam a demanda de energia por meio de iteração, trabalho paralelo e processamento repetido de contexto, e não por causa de uma única resposta extraordinária.

Uma interação padrão com chatbot geralmente segue um caminho simples. O usuário envia texto, o modelo processa seu contexto e o sistema gera uma resposta.

Um fluxo de trabalho agêntico adiciona um ciclo de controle. O modelo decide o que fazer, usa uma ferramenta, observa o resultado, atualiza seu plano e inicia outra etapa de inferência.

Inferência é o processo de executar um modelo treinado para produzir um resultado. Cada etapa adicional de inferência exige processadores, memória, rede e equipamentos de suporte do data center.

O Claude Code pode pesquisar um repositório, ler arquivos, editar código, executar testes, inspecionar erros e revisar seu trabalho. Uma tarefa difícil pode envolver dezenas ou centenas dessas etapas.

Subagentes paralelos aumentam ainda mais a contagem. Eles podem explorar abordagens diferentes simultaneamente, ampliando a cobertura enquanto consomem capacidade computacional ao mesmo tempo.

Os registros de Hausfather revelaram que a saída visível representava apenas cerca de 0,4% de todos os tokens processados. Aproximadamente 96% eram leituras de cache.

Um cache armazena contexto de modelo previamente processado para que o sistema possa reutilizá-lo de forma mais eficiente. Ler contexto armazenado em cache custa menos do que processar uma entrada nova, mas ainda consome recursos.

O volume se torna importante porque um agente revisita repetidamente seu histórico de trabalho em expansão. Cada resultado de ferramenta, trecho de arquivo, instrução e decisão anterior pode continuar fazendo parte das chamadas posteriores ao modelo.

Isso cria um padrão cumulativo. Sessões mais longas geram mais contexto, e etapas posteriores podem precisar reler grande parte desse contexto antes de produzir outra ação.

Hausfather assumiu que tokens em cache consumiam 10% da energia necessária para entrada nova. Ele também calculou cenários inferior e superior usando 1% e 25%.

Essa ampla faixa mostra por que a estimativa final continua incerta. Os preços podem oferecer pistas sobre o uso de recursos, mas um preço reduzido por token não é um medidor direto de eletricidade.

Hausfather testou três métodos publicados de estimativa e obteve resultados dentro do intervalo mais amplo de 70 a 330 quilowatt-hora. A concordância sustenta sua conclusão geral sem eliminar a incerteza.

O mecanismo principal também aparece em pesquisas mais amplas sobre emissões. Um framework de contabilização de 2026 estima que um fluxo de trabalho agêntico que faz de 5 a 50 chamadas a modelos de fronteira pode consumir de 50 a 500 watt-hora.

O mesmo framework alerta que uma interação pode subestimar a computação subjacente em uma ordem de grandeza ou mais. Esse alerta se aplica diretamente a agentes apresentados por meio de uma interface simples de chat.

A gestão de contexto, portanto, torna-se uma decisão de infraestrutura, não apenas um recurso de usabilidade. As equipes podem reduzir processamento desnecessário ao limitar contexto irrelevante e direcionar a recuperação para as informações necessárias em cada etapa.

Uma base de conhecimento pesquisável bem mantida pode ajudar engenheiros a recuperar material específico em vez de carregar repetidamente grandes coleções de documentos. No entanto, a economia real depende da arquitetura do agente.

O roteamento de modelos também importa. Um sistema pode enviar classificação, extração e edições rotineiras para modelos menores, reservando modelos de fronteira para raciocínios difíceis.

Essa abordagem não elimina o custo energético do agente. Ela alinha a quantidade de computação ao valor e à dificuldade de cada operação.

IA Eficiente Encontra Fluxos de Trabalho Agênticos em Expansão

A tensão central é que cada inferência individual continua ficando mais barata, enquanto produtos agênticos consomem mais inferências para concluir cada tarefa.

O número de 0,24 watt-hora do Google oferece fortes evidências de que a otimização em produção pode reduzir a energia por resposta. A empresa mediu um prompt de texto mediano do Gemini em toda sua pilha de serviço, em vez de testar um acelerador isolado.

O Google também relatou uma redução de 33 vezes na energia por prompt mediano em um ano. Mudanças nos modelos, melhorias de software, atualizações de hardware e otimização de serviço contribuíram para essa redução.

Esse progresso importa. Estimativas estáticas baseadas em chips mais antigos ou sistemas de laboratório pouco utilizados podem superestimar substancialmente a eletricidade exigida por um serviço de produção moderno.

O processamento em lote permite que a infraestrutura atenda várias solicitações juntas. O cache evita a repetição de alguns cálculos. Uma utilização mais alta distribui o consumo de equipamentos ociosos por mais trabalho útil.

Processadores especializados também realizam mais cálculos para cada unidade de eletricidade. Hausfather citou estimativas que mostram grandes ganhos na eficiência de hardware de aprendizado de máquina desde 2016.

No entanto, eficiência por operação não reduz automaticamente o consumo total. Computação mais barata pode incentivar desenvolvedores a usar mais dela.

Produtos agênticos tornam esse efeito rebote visível. Quando uma chamada ao modelo se torna mais rápida e menos cara, designers podem adicionar etapas de planejamento, ciclos de verificação, uso de ferramentas e agentes paralelos.

Essas adições podem melhorar o resultado. Elas também podem consumir o dividendo de eficiência antes que ele reduza a demanda total de eletricidade.

Esta é uma versão do efeito Jevons, em que maior eficiência de recursos pode estimular demanda nova suficiente para compensar as economias esperadas. A IA não garante esse resultado, mas seus incentivos atuais favorecem mais computação.

Provedores de modelos competem em conclusão de tarefas, desempenho em programação e autonomia. Os usuários geralmente percebem se o agente resolve o problema, e não quantas chamadas ocultas foram necessárias.

A própria análise de uso da Anthropic constatou que 77% do uso empresarial de API própria amostrado seguia padrões voltados à automação. Tarefas de programação e escritório tiveram destaque.

Essa pesquisa não mediu o consumo de eletricidade. Ela mostra por que cargas de trabalho agênticas merecem atenção: o uso empresarial de APIs já enfatiza execução automatizada em vez de conversa isolada.

Os incentivos econômicos reforçam esse padrão. A Anthropic relatou baixa sensibilidade a preços entre as tarefas empresariais de sua amostra. Tarefas mais capazes e mais caras apareceram com mais frequência do que as mais baratas.

Se um agente de programação economiza várias horas de trabalho qualificado, uma empresa pode aceitar substancialmente mais inferências do que uma resposta de chat exige. A eletricidade por prompt então se torna menos útil do que a eletricidade por problema resolvido.

A mesma lógica se aplica à análise científica. O dia mais intenso de Hausfather deu suporte a um projeto geoespacial complexo, não a uma conversa casual.

Portanto, a comparação correta nem sempre é entre um agente e um chatbot. Pode ser entre um fluxo de trabalho assistido por agente e os computadores, viagens, mão de obra ou atrasos exigidos pelo processo anterior.

No entanto, essa comparação mais ampla precisa de dados reais. Não se pode simplesmente presumir benefícios de produtividade, e os provedores não devem usar benefícios potenciais para evitar divulgar o consumo de recursos.

A eficiência e o crescimento da carga de trabalho devem ser informados em conjunto. Um número menor por token pode coexistir com uma demanda crescente de eletricidade se o processamento total de tokens crescer mais rapidamente.

É por isso que a estimativa de uso de energia do Claude Code funciona como um alerta, e não como um veredito final. Ela revela como uma boa narrativa de eficiência pode omitir a expansão que ocorre acima da camada do modelo.

O Que a Estimativa do Claude Code Não Pode Comprovar

A comparação de 600 vezes é importante em termos de direção, mas não é uma medição direta do consumo de eletricidade da Anthropic.

Hausfather dispunha de registros de atividade excepcionalmente detalhados. Eles registravam identificadores de modelos, timestamps e categorias de tokens para respostas individuais de API.

Esses registros fornecem um sólido histórico da atividade computacional. Eles não revelam a potência elétrica real utilizada pelos servidores da Anthropic durante cada solicitação.

Portanto, a estimativa converte tokens em energia por meio de metodologias publicadas. Cada método exige pressupostos sobre hardware, utilização, processamento em lote, tratamento de cache e sobrecarga do data center.

A Anthropic não publicou os dados de energia por token ou por prompt necessários para substituir esses pressupostos por medições próprias. Os locais e as fontes de eletricidade que atenderam às sessões também permanecem não divulgados.

O tratamento do cache cria outra grande incerteza. Um token armazenado em cache evita a repetição de parte do trabalho, mas a economia exata depende do sistema de atendimento.

O caso central de Hausfather considerou que leituras de cache consomem 10 por cento da energia de uma entrada nova. Uma relação diferente alteraria substancialmente a estimativa total.

A amostra também representa uma pessoa ao longo de oito semanas. Hausfather utilizou numerosos subagentes para grandes tarefas analíticas, de modo que sua atividade está muito distante de uma sessão de programação de um usuário casual.

Sua sessão mediana envolvia cerca de 10 milhões de tokens e mais de 100 chamadas. Outras estimativas publicadas para sessões do Claude Code utilizaram cargas de trabalho menores.

Portanto, seria enganoso afirmar que todo prompt do Claude Code consome 150 watt-horas. A conclusão correta é mais limitada: algumas sessões avançadas com agentes consomem centenas de vezes mais energia do que prompts simples de chat.

A comparação com o Gemini também envolve diferentes provedores e tipos de carga de trabalho. O número do Google abrange o prompt de texto mediano no Gemini Apps, enquanto a estimativa de Hausfather cobre atividade intensiva do Claude Code.

Essa diferença é o ponto da comparação, mas limita o que a proporção pode estabelecer. Ela não mostra que o Claude é intrinsecamente menos eficiente do que o Gemini.

Somente testes controlados de tarefas comparáveis nos dois sistemas poderiam sustentar essa afirmação. Idealmente, os provedores divulgariam medições usando limites de sistema consistentes.

A estrutura da Watershed ilustra o quanto esses limites afetam os resultados. Ela constatou que benchmarks isolados podem superestimar em quatro a 20 vezes a eletricidade de inferência em produção, pois deixam de considerar processamento em lote e cache.

O erro oposto também é possível. Informar apenas a potência dos aceleradores ativos pode omitir servidores host, capacidade ociosa, resfriamento, rede e perdas na conversão de eletricidade.

As empresas deveriam divulgar informações tanto sobre as cargas de trabalho quanto sobre a infraestrutura. Campos úteis incluiriam tokens, classe de modelo, tipo de acelerador, sobrecarga do data center, pressupostos de utilização e fontes regionais de eletricidade.

A divulgação por tarefa concluída acrescentaria outra camada essencial. Um agente pode usar mais energia por tentativa, mas exigir menos repetições humanas ou concluir trabalhos que sistemas mais simples não conseguem finalizar.

As taxas de sucesso importam porque execuções malsucedidas de agentes também consomem eletricidade. Um fluxo de trabalho que trava repetidamente pode ter um resultado ruim de energia por resultado, mesmo quando cada chamada individual parece eficiente.

Compradores corporativos deveriam perguntar aos fornecedores como eles lidam com tentativas repetidas, crescimento de contexto, falhas de ferramentas e roteamento de modelos. Essas decisões de design afetam tanto os custos operacionais quanto os relatórios ambientais.

A posição cética não é que a estimativa de Hausfather deva ser ignorada. É que uma estimativa transparente expõe quanta informação crucial os provedores ainda retêm.

A Pressão Passa dos Usuários para os Compradores de Infraestrutura

O problema energético dos agentes será decidido mais por compras, arquitetura de software e fornecimento de eletricidade do que pela moderação individual nos prompts.

Hausfather anualizou sua carga de trabalho de oito semanas para aproximadamente 1,1 megawatt-hora de eletricidade de data center. Sua faixa se estendeu de 0,4 a 2,2 megawatt-horas.

Usando as emissões médias da rede elétrica dos EUA, ele estimou aproximadamente 370 quilogramas de emissões equivalentes de dióxido de carbono por ano. A faixa foi de 150 a 730 quilogramas.

Isso é significativo para um usuário de software, mas Hausfather não argumenta que a culpa pessoal ofereça a principal solução. Usuários intensivos de agentes ainda representam uma parcela limitada da demanda total de eletricidade.

O risco maior vem da escala. Uma empresa pode implantar milhares de agentes que operam continuamente em programação, atendimento ao cliente, finanças, pesquisa e trabalho administrativo.

Cada agente pode criar uma demanda modesta. Cargas de trabalho persistentes, multiplicadas por muitos departamentos, podem alterar os requisitos de infraestrutura.

As previsões para data centers já mostram a dimensão do desafio ao redor. A atualização de 2025 do Lawrence Berkeley National Laboratory estima um caso de referência para 2030 de 649 terawatt-horas para os data centers dos EUA.

Esse caso de referência equivale a 11,8 por cento de todo o uso de eletricidade dos EUA. A faixa de incerteza composta do relatório abrange de 521 a 843 terawatt-horas.

A previsão cobre toda a demanda de data centers, e não apenas agentes de IA. Ainda assim, os servidores de IA e suas taxas de utilização são incertezas centrais dentro do modelo.

Isso pressiona três grupos.

Provedores de nuvem e de modelos devem divulgar informações suficientes para que os clientes comparem sistemas. Sem relatórios consistentes, eficiência se torna uma afirmação de marketing, e não uma métrica de compras.

Desenvolvedores de aplicações devem decidir quando a autonomia justifica chamadas repetidas ao modelo. Um fluxo de trabalho com cinco agentes deve enfrentar um limiar de valor mais alto do que uma única solicitação a um modelo menor.

Compradores corporativos devem medir resultados. Eles precisam do custo, da energia, da latência e da taxa de sucesso associados a uma tarefa concluída, e não a um prompt médio.

Essas decisões também afetam o planejamento da rede elétrica. Grandes data centers exigem geração, transmissão, subestações, sistemas de resfriamento e capacidade firme capazes de atender à demanda de pico.

A localização importa porque a mesma carga de trabalho pode produzir emissões diferentes em sistemas elétricos distintos. A geração de baixo carbono reduz as emissões mesmo quando a computação subjacente permanece constante.

A flexibilidade da carga de trabalho pode ajudar. Algumas tarefas de treinamento, avaliação e agentes em segundo plano podem ser deslocadas para horários ou regiões com eletricidade mais limpa ou menos restrita.

Sessões interativas de programação oferecem menos flexibilidade porque os usuários esperam respostas rápidas. No entanto, pesquisas ou testes não urgentes de subagentes podem tolerar agendamento.

Modelos menores oferecem outra alavanca. Classificação rotineira, seleção de arquivos e verificações de sintaxe nem sempre exigem o maior modelo disponível.

Os desenvolvedores também podem limitar iterações, comprimir o contexto, reutilizar resultados validados e interromper fluxos de trabalho malsucedidos mais cedo. Esses controles podem reduzir custos e, ao mesmo tempo, melhorar a previsibilidade.

A melhor arquitetura nem sempre usará a menor quantidade de eletricidade. Ela deve usar a menor quantidade de computação que conclua de forma confiável a tarefa valiosa.

Esse padrão conecta o desempenho ambiental à disciplina de engenharia. Tentativas repetidas desperdiçadas, contextos excessivos e chamadas desnecessárias a modelos de fronteira geralmente também são problemas financeiros.

Três Sinais Mostrarão se a IA Agêntica Pode Escalar de Forma Responsável

A próxima fase do debate sobre energia de IA depende da divulgação pelos provedores, da eficiência no nível da tarefa e da eletricidade construída para novos data centers.

O primeiro sinal é o relato direto de energia pela Anthropic e outros provedores de modelos. Registros de tokens não podem responder a questões que exigem acesso ao hardware de produção e aos dados de atendimento.

Uma divulgação útil deveria distinguir entre chat simples, raciocínio, programação e fluxos de trabalho com múltiplos agentes. Ela deveria abranger a infraestrutura completa, e não apenas um processador.

Se os provedores publicarem medições comparáveis no nível da tarefa, a confiança nas estimativas de energia dos agentes melhorará. O silêncio contínuo reforçará as preocupações de que os clientes não conseguem avaliar os sistemas que implantam.

O segundo sinal é se a energia por tarefa concluída diminui, e não apenas a energia por token. Chips e software de atendimento melhores continuarão reduzindo o custo das operações individuais.

Os agentes ainda podem consumir esses ganhos ao usar contextos mais longos e mais chamadas. Os fornecedores deveriam informar o sucesso da tarefa ao lado da inferência total, das tentativas repetidas e da latência.

Uma queda no número no nível da tarefa mostraria que a eficiência está superando a expansão dos fluxos de trabalho. Um consumo crescente para resultados semelhantes sugeriria que a autonomia adicional está absorvendo as economias.

O terceiro sinal é o tipo de eletricidade associado à nova capacidade de data centers. A eficiência não pode determinar as emissões sem conhecer a fonte de geração.

Hausfather estima que executar a mesma carga de trabalho com um fornecimento de eletricidade majoritariamente limpa poderia reduzir suas emissões em cerca de 90 por cento. A redução exata varia conforme a localização e o método de aquisição.

Nova geração renovável, armazenamento, energia nuclear, recursos geotérmicos e transmissão podem reduzir a intensidade de carbono da demanda adicional. A geração dedicada a combustíveis fósseis move o sistema na direção oposta.

Esses sinais importam mais do que discussões sobre se um prompt de IA equivale a vários segundos de televisão. Essa comparação descreve uma interação restrita que os agentes estão deixando rapidamente para trás.

Uma pergunta melhor é se um agente concluiu um trabalho que justifique seu custo computacional completo. Respondê-la exige registros transparentes, medições dos provedores e acompanhamento honesto dos resultados.

Os desenvolvedores podem começar agora auditando contagens de chamadas, crescimento de contexto, tentativas repetidas e seleção de modelos. Compradores corporativos podem solicitar dados de recursos no nível da tarefa durante as compras, em vez de aceitar uma única média.

A estimativa de uso de energia do Claude Code não resolve se os agentes oferecem valor suficiente. Ela estabelece que sua verdadeira unidade de consumo é o fluxo de trabalho.

À medida que os agentes assumem atribuições mais longas, os usuários deveriam perguntar o que acontece depois de pressionar Enter. Quantos modelos são executados, com que frequência eles releem o contexto e quais fontes de eletricidade mantêm esse processo em movimento?