Custo e latência

A situação

O assistente interno passou no piloto com 20 pessoas. A conta do mês veio pequena e ninguém olhou de perto. Na semana em que abriu para a empresa inteira, a fatura do provedor triplicou em quatro dias, e as reclamações de “está lento” chegaram junto.

Quando o time abriu os traces, achou três coisas: um system prompt de 6 mil tokens enviado em toda mensagem, um histórico de conversa que nunca encolhia, e quatro chamadas ao modelo feitas uma depois da outra, sendo que duas não dependiam de nada.

Nenhuma dessas decisões era errada no piloto. Elas só nunca tinham passado por uma conta simples, que cabe numa planilha e devia ser feita antes do primeiro deploy.

O conceito

Toda chamada a um modelo tem duas contas: quanto custa e quanto demora. As duas dependem de quantos tokens entram, quantos saem e quantas chamadas acontecem em fila.

flowchart LR
  P["1. Tokens de entrada"]:::tool --> M(["3. Chamada ao modelo"]):::llm
  H[("2. Histórico e documentos")]:::store --> P
  M --> O["4. Tokens de saída"]:::tool
  O --> C{"5. Custo e latência"}
  C --> T(["6. Total por tarefa"]):::io

1. Entrada é tudo que vai na chamada: system prompt, ferramentas, histórico, documentos e a pergunta.
2. Histórico e documentos costumam ser a maior parte da entrada, e crescem sem ninguém perceber.
3. O modelo escolhido define o preço por token e a velocidade.
4. Saída é o que o modelo escreve, incluindo o raciocínio interno quando ele está ligado.
5. Saída custa várias vezes mais que entrada por token e é gerada um token por vez.
6. O que importa é o total por tarefa concluída, não por chamada.

O piloto esconde o item 6. Vinte pessoas, conversas curtas, uma chamada por pergunta: a fatura parece uma linha. Na empresa inteira, o histórico cresce, as quatro chamadas em fila aparecem, e o “barato por chamada” vira caro por tarefa.

A conta de custo

custo_da_chamada = tokens_entrada × preço_entrada + tokens_saída × preço_saída
custo_da_tarefa  = soma das chamadas da tarefa (incluindo retries e passos de agente)
custo_do_mês     = custo_da_tarefa × tarefas_por_dia × 30

Os preços estão na página do provedor, em dólares por milhão de tokens. Em outubro de 2026, a tabela da Anthropic tinha, por exemplo, Claude Haiku 4.5 a US$ 1 de entrada e US$ 5 de saída, e Claude Opus 5.5 a US$ 4 e US$ 20. Confira sempre a página oficial antes de fazer a sua conta: preço muda.

Uma conta ilustrativa, com o Haiku da tabela acima. System prompt de 6 mil tokens, pergunta de 200, saída de 400. Entrada 6.200 × US$ 1 / milhão, saída 400 × US$ 5 / milhão. Dá frações de centavo por chamada. Multiplique por 5 mil perguntas por dia e o mês deixa de ser fração. Agora acrescente o histórico que, no turno 15, já soma uns 4 mil tokens extra: a mesma pergunta ficou bem mais cara sem ninguém mudar o modelo.

Dois fatores mudam essa conta mais do que qualquer outro:

• Cache de prompt. Quando o começo da chamada se repete (system prompt, ferramentas, documento fixo), o provedor cobra uma fração do preço pelos tokens lidos do cache. Veja Cache de Prompt.
• Número de passos. Um agente que faz dez chamadas reenvia o histórico dez vezes. O custo cresce mais rápido que o número de passos, porque cada volta paga de novo o que já tinha sido enviado.

Retry cego entra na mesma soma. Três tentativas não são três vezes o preço da primeira se o histórico já cresceu, e ainda somam três latências. Classifique o erro antes de repetir.

Checagem +20 XP de primeiraO piloto custava pouco com 20 pessoas. Na abertura, o mesmo prompt de 6 mil tokens foi para milhares de perguntas por dia. Qual leitura da fatura está certa?

O provedor mudou a tabela no fim de semana, porque o prompt não mudou

O custo por chamada era previsível; o que faltou foi multiplicar pelo volume real e pelo histórico que cresce

Saída ficou mais cara, então o time deve cortar max_tokens e ignorar a entrada

A conta de latência

A latência que o usuário sente tem duas partes:

Parte	O que define	Como reduzir
Tempo até o primeiro token	Tamanho da entrada, fila do provedor, modelo	Entrada menor, cache de prompt, modelo menor
Tempo de geração	Número de tokens de saída e velocidade do modelo	Saídas mais curtas, schema enxuto, streaming

Chamadas em sequência somam as latências. Chamadas independentes podem rodar ao mesmo tempo, e aí a latência total é a da mais lenta. Essa é a diferença entre o smell Fila Indiana de Chamadas e o padrão Seccionamento.

Streaming não reduz o tempo total de geração. Ele reduz o tempo até o usuário ver a primeira palavra. Para um JSON que o código consome no fim, streaming não ajuda o backend; um schema curto sim.

As quatro chamadas do assistente interno são o caso de livro. Se duas delas são “resumo do ticket” e “tom da resposta” e não compartilham resultado, elas podem ir em paralelo. As outras duas, se uma precisa da saída da anterior, continuam em fila. O trace mostra a soma. A planilha deveria ter mostrado antes.

Experimente

Este script mede custo e latência de uma chamada real e projeta o mês. Ele usa o contador de tokens da API, que não cobra a geração.

import time

import anthropic

client = anthropic.Anthropic()

MODEL = "claude-haiku-4-5"
PRICE_IN, PRICE_OUT = 1.00, 5.00   # US$ por milhão de tokens; confira a tabela atual
SYSTEM = "Você é o assistente de RH da empresa. " * 200   # simula um prompt grande
QUESTION = "Quantos dias de férias eu tenho por ano?"

counted = client.messages.count_tokens(
    model=MODEL, system=SYSTEM, messages=[{"role": "user", "content": QUESTION}],
)
print("tokens de entrada (contados antes):", counted.input_tokens)

start = time.perf_counter()
reply = client.messages.create(
    model=MODEL, max_tokens=300, system=SYSTEM,
    messages=[{"role": "user", "content": QUESTION}],
)
elapsed = time.perf_counter() - start

u = reply.usage
cost = u.input_tokens / 1e6 * PRICE_IN + u.output_tokens / 1e6 * PRICE_OUT
print(f"entrada {u.input_tokens}, saída {u.output_tokens}, {elapsed:.2f}s")
print(f"custo por chamada: US$ {cost:.5f}")
print(f"5 mil perguntas por dia, 30 dias: US$ {cost * 5000 * 30:.2f}")

Depois reduza o SYSTEM para uma linha e rode de novo. Compare a latência e a projeção do mês. A diferença é o preço de um prompt inchado.

Faça uma terceira corrida com o raciocínio interno ligado, se o modelo oferecer isso. A saída cobrada cresce mesmo quando o usuário vê só a frase final. A planilha precisa da coluna que o trace já tem: tokens de saída reais, não tokens visíveis.

Checagem +20 XP de primeiraO script mostra 0,8s com o prompt grande e 0,4s com o prompt de uma linha, na mesma pergunta. O time quer streaming para 'resolver a lentidão'. O que o número já disse?

Que a lentidão é fila do provedor, então streaming é a correção certa

Que boa parte da espera está na entrada inchada; streaming esconde, dieta no prompt corta

Que 0,8s é aceitável e não vale mexer

O que isso muda

• Faça a conta antes do deploy, por tarefa, com o volume esperado. Uma planilha com tokens por chamada e chamadas por tarefa evita a maior parte das surpresas.
• Toda página de padrão deste catálogo tem a seção “Custo, latência e falhas”. Ela diz quantas chamadas o padrão acrescenta e onde a conta aparece no trace.
• Sem limite de gasto, um loop ou um usuário abusivo esvazia o orçamento. Veja o smell Custo Sem Teto e o padrão Orçamento de Custo.
• Nem toda tarefa precisa do maior modelo. A Cascata de Modelos tenta o barato primeiro.
• Pergunta repetida não precisa ser processada de novo. Veja Pagando Duas Vezes.
• Você só controla o que mede. Registre tokens e custo em cada span do trace, como mostra Observabilidade para IA.

Teste seu entendimento

Checagem +20 XP de primeiraQuatro chamadas de 600 ms cada. Duas são independentes, as outras duas precisam ir em sequência. Qual latência de tarefa você coloca na planilha se paralelizar o que der?

600 ms, porque em paralelo tudo vira a mais lenta

Cerca de 1,8 s: max das independentes mais a soma das dependentes

2,4 s ainda, porque o provedor serializa de qualquer jeito

Checagem +20 XP de primeiraUm agente resolve um ticket em 8 passos na mediana e em 40 no pior caso, sem teto de custo. Qual risco a planilha de 'custo médio por ticket' esconde?

Nenhum, se a mediana está dentro do orçamento do mês

A cauda: o pior caso reenvia histórico 40 vezes, e a média dilui isso até o cartão reclamar

Só a latência, porque 40 passos são lentos mas o cache zera o custo

Checagem +20 XP de primeiraO time quer Opus em todas as perguntas do assistente de RH 'para não errar férias'. O eval mostra Haiku suficiente em 95% dos casos. Qual desenho casa custo com qualidade?

Haiku em tudo, porque 5% de erro em RH é aceitável se a fatura cair

Opus em tudo, porque o eval de 95% pode ser otimista

Cascata: Haiku primeiro, Opus só quando a confiança ou a validação falhar

Checagem +20 XP de primeiraDois usuários perguntam a mesma política de férias no mesmo dia. Não há cache. O que a segunda chamada está pagando?

Quase nada, porque o provedor lembra da primeira resposta

A entrada inteira de novo, inclusive o prompt inchado, e uma geração nova

Só a saída, porque a entrada de política pública deveria ser grátis