Quanto custa um agente em produção em 2026: planilha real depois de 6 meses

Tem um arquivo de Excel aberto no canto da minha tela há seis meses. Cada linha é um dia de operação de um agente em produção: input tokens, output tokens, cache writes, cache reads, retries, eval de runtime, traços no Langfuse, sandbox que travou, hora de plantão. Quando eu olho o totalzão e comparo com o que a calculadora oficial dos labs cuspiu no começo, a diferença é constrangedora.

A calculadora da OpenAI mente. A da Anthropic também. Não porque os números do pricing estão errados — eles estão certos. É que pricing de token é um item de linha, não a fatura. A fatura tem mais cinco linhas que ninguém mostra antes de você assinar.

Neste post eu abro o balancete completo desses seis meses. Cada bucket de custo, com número, percentual e fonte. No fim, o veredito do build vs buy: quando vale construir e quando você está só pagando para reinventar o Cursor.

TL;DR

• O que é: balancete real de seis meses operando um agente em produção, com seis buckets de custo que a calculadora oficial não mostra.
• Stack/Modelos: Claude Sonnet 4.6 como workhorse, Haiku 4.5 para triagem, Opus 4.7 em ~10% dos casos difíceis. Langfuse self-hosted, Qdrant Cloud, queue em Redis, sandbox em E2B.
• Custo médio mensal no mês 6: ~US$ 23,8k para ~200k tarefas/mês. A inferência pura é US$ 12,5k. O resto (US$ 11,3k) é o que ninguém te conta.
• Verdict build vs buy: abaixo de 30 devs, Cursor for Teams ou Claude Code Enterprise vencem feio. Acima, depende do quanto seu produto é diferenciado.

O contexto — por que a calculadora oficial mente

Toda calculadora de LLM faz a mesma conta: tokens_input × preço_input + tokens_output × preço_output. Os preços, em maio de 2026, estão na tabela oficial da Anthropic: Haiku 4.5 a US$ 1 / US$ 5 por milhão, Sonnet 4.6 a US$ 3 / US$ 15, Opus 4.7 a US$ 5 / US$ 25. A OpenAI publica algo parecido: GPT-5.5 a US$ 5 / US$ 30 e GPT-5.4 a US$ 2,50 / US$ 15 por milhão.

Se você só pega esses números e multiplica pelo seu volume estimado, você está fazendo a conta certa para o item de linha errado.

A fatura real de um agente em produção tem seis baldes, e o do token é só um deles:

1. Inferência (input + output + cache writes + cache reads + retries + fallback).
2. Eval em runtime (LLM-as-judge, regression suite, drift detection).
3. Observability (Langfuse, Helicone ou OTel; storage de spans).
4. Infra de execução (queue, sandbox, vector store, banco).
5. Pessoas (dev de plantão, ML engineer, eval review humano).
6. Outros (CI, rotação de secret, billing alerts, governança).

Cada balde tem dinâmica própria. Cache, por exemplo, é o que separa um agente saudável de um agente que sangra dinheiro: a Anthropic documenta 0,1x do preço base em cache read e 1,25x para escrita de 5 minutos, e times relatam cortes de 59% a 90% no custo de inferência quando o prompt é estruturado direito. Esse não é um detalhe: é a diferença entre US$ 12,5k/mês e US$ 30k/mês para o mesmo agente.

Vamos ao balancete.

Pré-requisitos para acompanhar a planilha

Para mapear seu agente no mesmo formato você precisa de:

• [ ] Acesso a uma API de modelo (Anthropic, OpenAI ou ambas) com billing por organização.
• [ ] Algum tipo de observability instrumentado — Langfuse, Helicone, LangSmith ou OTel cru com GenAI semantic conventions.
• [ ] Tagging de requests por bucket (inference.user, eval.judge, eval.regression, retry.transient). Sem isso, o balancete vira chute.
• [ ] Histórico de pelo menos 90 dias para a curva fazer sentido. Antes disso, o tráfego ainda está aprendendo.

Não importa o framework. O que importa é separar o que é trabalho do agente do que é trabalho sobre o agente.

Mão na massa — o balancete, mês a mês

O agente em questão faz triagem técnica de tickets em um SaaS B2B. Volume cresceu de ~40k tarefas no mês 1 para ~200k no mês 6. Stack: Sonnet 4.6 workhorse, Haiku 4.5 classificador inicial, Opus 4.7 para 10% dos casos que escapam.

Mês 6 — o snapshot que importa

A calculadora oficial, fazendo só tokens × preço, teria cuspido algo entre US$ 14k e US$ 16k. O delta de ~US$ 8k é exatamente o que este post está aberto para destrinchar.

A curva dos seis meses

Repare em duas coisas. Primeiro, inferência cresce quase linear com volume — esperado. Segundo, eval e observability crescem sublinear; pessoas e infra são praticamente fixos no primeiro ano. É essa estrutura que faz o custo unitário cair de US$ 0,24/tarefa no mês 1 para US$ 0,12/tarefa no mês 6. A diluição não vem do modelo. Vem dos outros buckets.

Linha 1 — Inferência (52% do total): cache muda tudo

Aqui mora o item de linha que todo mundo prevê e quase ninguém modela direito. A composição do mês 6:

Três coisas para reparar:

Cache reads vs cache writes. Cache read custa 10% do input base — é o que a Anthropic chama de multiplicador 0,1x. Cache write 5min custa 25% a mais que o base (1,25x). Na planilha acima, 1,6 bilhão de tokens custou US$ 480 em cache read. Se tivessem ido como input fresh, seriam US$ 4.800. Dez vezes mais. Esse é o ponto de virada da economia de um agente.

A arquitetura mínima para isso funcionar é separar prompt em camadas. Tudo que é estático (instruções do agente, definição de ferramentas, exemplos few-shot, documentos de referência) vai numa porção cacheável. O que varia (input do usuário, contexto da sessão) fica fora:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT_GIGANTE,
            "cache_control": {"type": "ephemeral"}
        },
        {
            "type": "text",
            "text": TOOL_DEFINITIONS_E_EXEMPLOS,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": user_input}
    ]
)

Cada bloco com cache_control vira um breakpoint. Tudo até ele é reusado se a próxima call começar igual. Cache de 5 minutos paga o break-even em uma única leitura subsequente; cache de 1 hora paga em duas. Em agente loop, o cache write 1h vira investimento de um turno que rende em todos os outros.

Retry rate. Em produção, 4,8% das chamadas viraram retry. Causas: rate limit transitório, ferramenta interna que voltou erro, validação de schema que falhou, alucinação que o validator pegou. Cada retry é uma nova call paga. Esse número não aparece em nenhum cálculo de "TCO LLM produção" feito antes de operar — e ele é a diferença entre US$ 11,9k e US$ 12,5k todo mês.

Mistura de modelos. Triagem com Haiku 4.5 (US$ 1 / US$ 5 por milhão), resposta com Sonnet 4.6, escalada para Opus 4.7 em ~10% dos casos onde o agente reconhece complexidade. Mandar tudo para Opus dobraria o custo de inferência. Mandar tudo para Haiku derrubaria qualidade. A planilha aqui só fecha porque a régua de roteamento foi calibrada com eval real.

Linha 2 — Eval em runtime (14%): o que ninguém prevê

Este é o item que toda calculadora ignora e que pega 14% do balancete logo de cara. Dado público da Hugging Face e dos relatórios de produção convergem: eval e workloads assíncronos representam 20-40% do gasto de LLM. Aqui ficou em ~14% porque a régua é agressiva mas não exagerada.

A composição:

LLM-as-judge é o vilão mais sutil. Você sampla 10% das respostas do agente, manda para um modelo julgar contra rubricas, e usa isso como sinal de qualidade contínua. Funciona. Mas dobra o custo daquele sample. Se você roda judge em 100% (que é o que algumas equipes fazem em features novas no primeiro mês), você dobra o custo do agente inteiro.

Regression suite é diferente: um conjunto fixo de casos que rodam todo dia. Custa pouco em volume, muito por execução, porque você roda em modelo top para ter precisão de teste. Drift detection é eval barato — só embeddings — mas só se traduz em valor se o vector store estiver dimensionado para isso (vem na linha 4).

Pular eval em runtime é tentador. Não pule. O custo do bug em produção, medido em ticket de suporte e refund, é sempre maior que o custo do eval. A planilha não te dá essa opção — ela só te mostra o que você está pagando.

Linha 3 — Observability (3%): pequeno em dólar, gigante em decisão

US$ 680/mês parece pouco. É. Mas observabilidade é o bucket que decide se os outros cinco vão crescer linearmente ou explodir. Sem traces estruturados você não sabe qual chamada está custando mais, qual prompt está alucinando, qual usuário está abusando.

Comparação rápida das opções (preços maio/2026):

O agente da planilha roda Langfuse self-hosted. A linha cresce porque Langfuse em produção pede PostgreSQL + ClickHouse + Redis + S3. No nosso setup: três nodes ClickHouse (US$ 410), Postgres compartilhado (US$ 90 alocados), bucket de spans (US$ 90), runner do Langfuse (US$ 90). Total US$ 680. Cresce sublinear com volume porque o gargalo é dimensão de ClickHouse, não tráfego.

A regra prática: até 50k requests/dia, Langfuse Cloud Core paga sozinho. Acima, self-hosted começa a fazer sentido — se você tiver alguém que cuida de ClickHouse. Se não tiver, fique no managed.

Linha 4 — Infra de execução (13%): o agente não vive só de modelo

Sandbox costuma ser a surpresa. Se seu agente executa código gerado, você precisa de container isolado, e isso custa por hora. E2B, Modal, Daytona — todos cobram entre US$ 0,02 e US$ 0,05 por container-hora. Em 600h/mês de execução, vira US$ 1.840.

Vector store é o segundo. Qdrant Cloud a 10M vetores fica em ~US$ 65/mês, mas escala não-linear — em 50M, o cluster precisa de mais memória. Pinecone na mesma faixa chega a US$ 700+. Não há almoço grátis aqui: managed cobra por conveniência, self-hosted cobra por Kubernetes-engineer-hour.

Linha 5 — Pessoas (16%): o item de linha que não está no slack do CFO

Esse é o bucket mais polêmico porque varia muito entre empresa. Mas ele existe. Sempre. Agente em produção precisa de alguém que olha o Langfuse de manhã, alguém que ajusta prompt quando a qualidade cai, alguém que faz review humano de amostra para alimentar a regression suite.

Quando o COO pergunta "quanto custa o agente", e você responde só com a fatura da Anthropic, está omitindo essa linha. E ela é 16% do total. Em valor absoluto, é mais que toda a observability + parte da infra.

Linha 6 — Outros (2%)

CI builds para o repo do agente, rotação de secret no Vault, billing alerts no Datadog, governança (revisão de policy, log audit). Soma US$ 500/mês, mas é o bucket que vira pesadelo quando você ignora.

Build vs buy — quando faz sentido construir do zero

Você leu até aqui. Agora a pergunta honesta: vale a pena montar tudo isso, ou vale comprar pronto?

Para 30 desenvolvedores:

A diferença é absurda. Para um caso de uso genérico — assistente de codificação, busca interna, automação de PR — qualquer das duas opções de buy vence pela ordem de magnitude.

Construir só faz sentido em três cenários:

1. Produto diferenciado. O agente é o produto que você vende. Como o atendimento autônomo de uma fintech ou o engine de triagem de um SaaS B2B. Aí o custo de US$ 23k/mês é COGS do seu produto, não overhead.
2. Dado proprietário ou compliance. Você não pode mandar contexto para a nuvem do Cursor. Healthcare regulado, gov, defesa. O custo de construir aqui é tax de compliance.
3. Latência ou loop específico. Você precisa de loop autônomo controlado por você (review automático, refatoração contínua, agente de operações). Aí construir um harness próprio em cima da API é o que destrava o caso.

Se nenhum desses casos te descreve, compre. Se algum te descreve — e neste cenário você precisa entender harness, loop autônomo, observability custom e o trade-off de cada uma das seis linhas acima —, é exatamente o terreno que a gente destrincha ao vivo no Harness Engineering com Claude Code, o workshop do Beer & Code que monta um harness próprio em cima do Claude Code, do loop autônomo ao agente em produção.

Limitações e pontos de atenção

A planilha deste post é o balancete de um agente, em um tipo de operação. Algumas coisas não generalizam:

• Volume. Abaixo de 20k tarefas/mês, a estrutura de custo fica dominada por pessoas e infra, não por inferência. O percentual de eval em runtime pode subir para 30%.
• Modelo. Se você roda só Opus 4.7 ou só GPT-5.5, a fatia de inferência sobe para 65-70% e a planilha muda de cara.
• Sandbox. Agente que não executa código não tem essa linha — corta US$ 1.840/mês. Agente que executa muito código pode dobrá-la.
• Batch API. Se 50% do seu workload é assíncrono e tolerante a latência, a Batch API da Anthropic dá 50% off em input e output. Ignorar isso quando faz sentido é dinheiro na mesa.
• Self-hosted models. Open-source não some com o custo, só move ele. GPU hours, ops, fine-tuning, eval — tudo continua. Tipicamente vira competitivo só acima de US$ 50k/mês de gasto em API fechada.

Esse bloco é o que diferencia uma planilha de TCO real de um pitch. Se você não conhece os limites do seu modelo financeiro, está vendendo certeza que não tem.

FAQ rápido

Posso usar só a Batch API e ignorar todo esse balancete?

Não. Batch API resolve workload assíncrono — você manda em lote, espera até 24h, recebe com 50% off. Funciona para classificação em massa, geração offline de relatório, eval de dataset. Não funciona para agente interativo, que precisa responder em segundos.

Eval em runtime dobra meu custo de inferência. Posso pular?

Pode. Mas o custo do bug em produção tende a ser maior. Comece com judge em 5-10% das respostas. Suba para 100% só em features novas no primeiro mês. Depois calibra.

Self-hosted Langfuse vale a pena?

Acima de 200k spans/dia, sim — se você tem alguém que cuida de ClickHouse. Abaixo, o Cloud Core sai mais barato que sua infra equivalente. A conta vira quando o tempo do dev de plantão custa mais que o managed.

Cursor for Teams ou Claude Code Enterprise?

Para uso individual de devs (auto-complete, chat de código, refactor), Cursor é mais barato e mais maduro de produto. Para harness próprio com loop autônomo, automação de PR, agente custom — Claude Code Enterprise dá o substrato, você constrói em cima. São produtos diferentes para problemas diferentes.

Conclusão

A calculadora oficial te dá o tamanho de uma linha. A planilha real te dá o tamanho da fatura. A diferença, no caso deste agente, é quase 2x: US$ 14k que a calculadora projeta vira US$ 23,8k operados. Quem não modela os outros cinco buckets descobre isso no final do trimestre — sempre tarde, sempre dolorido.

A próxima fase do agente em produção não é "qual modelo escolher". É operação: cache hit rate, retry rate, eval em runtime, observabilidade, custo unitário por tarefa. Quem dominar isso vai construir produto. Quem não dominar vai pagar 2x para chegar no mesmo lugar.

Se você quer ver outro post no mesmo espírito, dá uma olhada em como pensar arquitetura de agente em PHP/Laravel sem reinventar o framework — o lado dev raiz do mesmo problema.