Custo real de agentes IA em produção: tokens, tempo e falhas que ninguém fala
TL;DR: Rodar agentes de IA em produção custa mais do que o painel de billing mostra. O custo de tokens cresce de forma não linear em pipelines multi-agente, a latência se acumula a cada turno e as falhas multiplicam tudo por retry. Este post cobre os números reais, o impacto do novo tokenizador do Opus 4.7 e quando faz sentido (ou não) usar agentes de verdade.
A demo funcionou perfeitamente. Cinco ferramentas encadeadas, resposta em 8 segundos, output limpo.
Aí você bota em produção.
Primeira semana: a fatura da API veio três vezes maior que o esperado. O agente travou em loop em 23% das sessões. A latência média passou de 8 para 47 segundos porque o contexto cresceu entre os turnos. E você percebeu que não tinha nenhuma métrica para entender por quê.
Isso acontece com mais frequência do que aparece nos posts de lançamento. Tenho rodado agentes com Claude Code em projetos reais, e o que vou descrever aqui são as surpresas que aparecem quando o custo de agentes IA em produção encontra a teoria.
Por que o custo de tokens não é linear?
O maior erro de cálculo ao estimar custo de agentes: pegar o preço por token, multiplicar pela estimativa de tokens por tarefa e chamar de pronto. Para uma chamada isolada, funciona. Para pipelines multi-agente, esse cálculo subestima o custo real em ordens de grandeza, porque o contexto cresce a cada turno e cada subagente recebe uma cópia dele.
O problema é duplo. Primeiro, o contexto cresce a cada turno. Na primeira chamada, você manda 500 tokens. Na segunda, o histórico da primeira já está incluído: são 1.000. Na terceira, 2.000. Um estudo da Stevens University sobre a economia escondida dos agentes chama isso de crescimento quadrático: o custo não cresce com o número de turnos, cresce com o quadrado deles.
Segundo, cada subagente começa seu próprio contexto. Num sistema com orquestrador mais três subagentes, você não tem um contexto crescendo: tem quatro. O mesmo conteúdo (o plano de execução, o contexto do projeto, as instruções do sistema) é repassado para cada subagente separadamente. Segundo a mesma fonte, sistemas multi-agente consomem até 200% mais tokens que sistemas de agente único rodando a tarefa equivalente.
Na prática, num projeto como o que descrevi em como o Claude Code entregou uma feature enquanto eu dormia, o orquestrador distribui contexto para cada persona especializada. Cada uma recebe o briefing, as instruções e o histórico relevante. Isso é necessário para que funcionem bem, mas o custo de tokens por execução é multiplicado pelo número de agentes ativos. Já escrevi sobre como estruturar um sistema de agentes para evitar que o contexto exploda. Vale ler antes de escalar.
O patamar real para tarefas de engenharia de software com agentes sem restrição de orçamento: entre $5 e $8 por tarefa. Para tarefas simples, o overhead de um pipeline multi-agente pode custar mais que a tarefa em si.
O que acontece com a latência em cadeia?
Se um agente demora 30 segundos num turno, uma cadeia de cinco agentes sequenciais demora 2,5 minutos no melhor caso. Cada handoff tem overhead de serialização e prefill. O tempo não some: ele se acumula em cada etapa, e o resultado final na prática é pior do que o cálculo simples sugere.
O primeiro problema é a acumulação de latência de coordenação. Cada handoff entre agentes tem overhead: serializar o output de um, passar para o próximo, aguardar o prefill do contexto no novo modelo. Esse overhead cresce com o número de agentes. Dados de produção mostram que a latência de coordenação salta de 200ms com 5 agentes para 2 segundos com 50.
O segundo problema é o prefill de contextos grandes. Quando o contexto acumulado é longo (e em sessões multi-turno ele cresce rápido), o tempo para o modelo processar os tokens de entrada antes de começar a responder aumenta. Em contextos de tamanho máximo, o tempo de prefill pode superar 2 minutos.
A solução para o problema de latência que mais funciona na prática é o prompt caching. Se seu sistema tem instruções de sistema, documentação do projeto ou contexto fixo que se repete em cada chamada, o caching reduz custo de entrada em até 90% e latência em até 75%. Para pipelines de agente onde o system prompt é o mesmo em cada execução, isso é direto de implementar e o impacto é imediato.
Como as falhas multiplicam o custo?
Agentes de IA falham em aproximadamente 1 de cada 3 tarefas em uso empresarial real. Não em ambiente de teste, não com prompts cuidadosamente construídos: em produção de verdade. Sem retry logic adequada, a falha custa apenas a tentativa que falhou. Com retry, o custo explode: cada nova tentativa reenvia o contexto acumulado inteiro. Um loop de 90 segundos com três retries pode custar mais que dez execuções bem-sucedidas.
O dado importante não é a taxa de falha em si: é o que acontece depois da falha. Um agente que falhou no turno 8 de 10, numa sessão onde o contexto cresceu progressivamente, vai refazer o prefill daquele contexto acumulado em cada retry. O custo da falha não é o custo de um turno: é o custo do contexto inteiro de novo.
Um exemplo concreto de como loops de retry explodem o custo: num agente de suporte ao cliente auditado, 23% das conversas travavam em loops de erro. Um timeout da API de CRM disparava retries que falhavam da mesma forma, porque não havia backoff exponencial nem limite de tentativas. O agente tentava por 90 segundos antes de desistir. Em cada tentativa, re-enviava o contexto completo da conversa.
O que você precisa ter antes de ir para produção:
- Limite máximo de turnos por sessão (não deixe o contexto crescer indefinidamente)
- Backoff exponencial em retries (não re-tente imediatamente na mesma falha)
- Fallback para agente mais simples quando o principal falha
- Alerta quando o custo por sessão ultrapassar um threshold
O impacto do tokenizador novo do Opus 4.7
O Claude Opus 4.7 lançou em 16 de abril de 2026 com a tabela de preços idêntica ao 4.6: $5 por milhão de tokens de entrada, $25 por milhão de tokens de saída.
O que mudou: o tokenizador.
Anthropic documentou que o novo tokenizador usa "de 1,0 a 1,35x mais tokens" para o mesmo conteúdo. Medições independentes em conteúdo real mostram números maiores. Segundo testes publicados no Claude Code Camp, o impacto por tipo de conteúdo foi:
- Documentação técnica: 1,47x mais tokens
- Código TypeScript: 1,36x mais tokens
- Código Python: 1,29x mais tokens
- Prosa em inglês: 1,20x mais tokens
- Conteúdo CJK: 1,01x (praticamente sem impacto)
Para quem usa Claude Code com agentes (que trabalham essencialmente com código e documentação técnica), o aumento real está no topo da faixa: 30 a 47% a mais por chamada com o mesmo conteúdo. A análise da Finout estima aumento de 20 a 30% no custo total por sessão típica de Claude Code, com janelas de 5 horas do plano Max sendo consumidas 30% mais rápido.
O custo nominal não subiu. O custo real, para quem trabalha com código via API, subiu. Vale recalibrar os orçamentos antes de migrar workloads do 4.6 para o 4.7.
Uma nota importante sobre contexto de uso pessoal: quem usa o Claude Code nos planos Pro ($20/mês) ou Max ($100-200/mês) não paga por token diretamente. O custo é fixo mensal. O impacto do tokenizador novo nesse caso é que os limites de uso diário e semanal são consumidos mais rápido, não que a fatura sobe. O custo variável por token descrito acima é relevante principalmente para quem acessa via API com faturamento por uso.
Se você quer entender a fundo como o Claude Code funciona internamente, o post sobre o vazamento do codebase do Claude Code cobre o que dá para extrair do código real.
Quando faz sentido usar agentes e quando não faz?
Agentes fazem sentido quando a tarefa tem múltiplos passos com decisão entre eles, o paralelismo real reduz o tempo de execução e o valor gerado justifica $5 a $8 por execução. Para extração simples, classificação ou qualquer coisa que um modelo menor resolve numa chamada direta, o overhead de coordenação custa mais do que economiza.
Agentes adicionam overhead em tokens, latência e complexidade operacional. Esse overhead se justifica quando a complexidade da tarefa é grande o suficiente para dominar esses custos fixos.
Faz sentido usar agentes quando:
A tarefa requer múltiplos passos com dependência entre eles e decisão em cada passo. Um agente que lê um ticket, planeja a implementação, divide o trabalho entre coders especializados e revisa o output é mais eficaz que uma única chamada tentando fazer tudo de uma vez.
A tarefa se beneficia de paralelismo real. Como mostrei no post sobre a feature que o Claude Code entregou enquanto eu dormia, dois subagentes rodando em repos separados simultaneamente comprimem o tempo de execução de forma que um agente único não consegue.
O valor criado por execução justifica o custo. Para uma tarefa de engenharia que valeria dois dias de trabalho humano, pagar $5 a $8 por execução faz sentido econômico.
Não faz sentido quando:
A tarefa é uma extração ou classificação simples. Uma chamada direta com um modelo menor (Haiku, Flash) faz o trabalho a um custo 10 a 20 vezes menor, sem o overhead de coordenação.
A latência de 30 segundos ou mais é inaceitável para o usuário. Em casos de uso síncronos com usuário aguardando, pipelines multi-agente são a arquitetura errada.
Você não tem como medir o que está acontecendo. Rodar agentes sem observabilidade é queimar dinheiro no escuro.
Métricas para não operar no escuro
A primeira métrica que você precisa é custo por tarefa. Não custo total de API por mês: custo por unidade de trabalho concluída. Isso revela o que está custando de verdade e permite comparar antes e depois de otimizações.
A segunda é taxa de sucesso por tipo de tarefa. Agentes de tarefas diferentes têm taxas de sucesso diferentes. Agregar tudo numa única métrica esconde onde o sistema está falhando.
A terceira é tamanho médio de contexto por turno, com alerta para crescimento anormal. Contexto crescendo além do esperado é sinal de loop ou de prompt mal estruturado que está re-enviando informação desnecessária. O sistema de memória entre sessões ajuda a controlar o que é carregado no contexto a cada execução.
A quarta é latência p95 e p99, não só a média. A média esconde os casos problemáticos. Numa cadeia de agentes, os outliers de latência são os que estão trazendo a experiência do usuário para baixo.
O objetivo é transformar a inferência numa linha de custo observável, com alertas e limites. Sem isso, você descobre os problemas na fatura do mês seguinte.
Essa é a parte que os posts de lançamento de ferramentas raramente cobrem. O que funciona no ambiente controlado de uma demo tem custos diferentes em produção real: contexto que cresce, falhas que se multiplicam, tokenizadores que mudam as contas.
Tenho escrito sobre isso com frequência, incluindo os erros que aparecem ao longo do caminho. Se você quer acompanhar o que estou aprendendo rodando agentes em produção, me segue no LinkedIn. Posto lá quando saem experimentos novos, métricas reais e análises como esta.
Perguntas Frequentes
Por que o custo de tokens cresce tão rápido em pipelines de agentes? Em pipelines multi-agente, cada turno inclui o histórico de todos os turnos anteriores no contexto. O custo não cresce linearmente com o número de chamadas: cresce de forma quadrática, porque cada chamada paga pelos tokens acumulados até ali. Sistemas multi-agente podem consumir até 200% mais tokens que sistemas de agente único para a mesma tarefa.
O que é o custo real de rodar agentes IA em produção comparado à estimativa inicial? A maior diferença vem de três fatores que as estimativas simples ignoram: crescimento do contexto entre turnos, custo de subagentes que recebem cópias do mesmo contexto, e custo de retries quando o agente falha. O custo de infraestrutura em produção chega a ser 380% maior que as estimativas de piloto, segundo dados de empresas que escalaram agentes.
Como o novo tokenizador do Claude Opus 4.7 afeta o custo de rodar agentes? O tokenizador do Opus 4.7 usa de 1,20 a 1,47x mais tokens para o mesmo conteúdo em relação ao 4.6, dependendo do tipo. Código e documentação técnica (o que agentes de engenharia manipulam mais) são os mais afetados. Para quem acessa via API, o preço por token não mudou, mas o número de tokens por chamada aumentou, o que resulta em faturas 20 a 30% maiores. Para quem usa nos planos Pro ou Max (custo fixo mensal), o efeito é que os limites de uso são consumidos mais rápido, não que a fatura sobe.
Qual a taxa de falha real de agentes IA em produção? Dados de uso empresarial real mostram que agentes falham em aproximadamente 1 de cada 3 tarefas. A falha em si não é o maior problema: o maior problema é quando não existe retry logic adequada (com limite de tentativas e backoff exponencial), porque a falha vira um loop que consome tokens em escala.
Como saber se faz sentido usar agentes para uma tarefa específica? A regra prática: se a tarefa tem múltiplos passos com decisão entre eles, se beneficia de paralelismo e cria valor suficiente para justificar $3 a $8 de custo de API por execução, agentes fazem sentido. Para extração simples, classificação ou qualquer coisa que uma única chamada a um modelo menor resolve, o overhead de um pipeline de agentes não se justifica.