Reduzir custo de API de IA: os vazamentos de token mais comuns

A fatura da API veio 4x maior do que você previu. Antes de cortar feature, vamos achar os vazamentos de token.

Esse é o roteiro mais comum de quem botou IA em produção. O protótipo custava centavos. Aí o produto cresceu, o tráfego subiu, e a conta da OpenAI ou da Anthropic explodiu — sem que o número de usuários explodisse junto. Quando isso acontece, a primeira reação quase sempre é errada: desligar funcionalidade, trocar pra um modelo pior, ou aceitar a margem espremida como "custo de fazer IA".

Quase nunca é necessário. Na maioria dos casos dá pra reduzir custo de API de IA sem tocar em nenhuma feature e sem perder qualidade de resposta. O problema raramente é "IA é cara". O problema é que o token está vazando em lugares que você não está olhando. Neste post a gente vai abrir o cano: os cinco vazamentos mais comuns, como cada um aparece na fatura, e o conserto de cada um.

TL;DR

• O que é: diagnóstico dos pontos onde o consumo de token infla a conta de API de LLM em produção, com o conserto de cada um.
• Stack/Modelos: OpenAI (GPT-5.x) e Anthropic (Claude Opus/Sonnet/Haiku). Os conceitos valem pra qualquer provedor cobrado por token.
• Custo/Acesso: as duas maiores alavancas (prompt caching e Batch API) não custam nada a mais pra ligar — caching é automático na OpenAI e corta até 90% do input repetido.
• Link útil: Pricing oficial da Claude API e Pricing da OpenAI.

O token é a unidade de custo — e ele tem preço de tabela

Antes de caçar vazamento, fixa uma ideia: você não paga por "request", paga por token. Input e output, cada um com preço próprio, por milhão de tokens. E a diferença entre modelos é brutal.

Hoje, na Anthropic, o Claude Opus 4.8 custa US$ 5 por milhão de tokens de input e US$ 25 de output. O Sonnet 4.6 fica em US$ 3 / US$ 15. O Haiku 4.5, em US$ 1 / US$ 5 (pricing oficial). Do lado da OpenAI a lógica é a mesma: output custa várias vezes mais que input, e o modelo topo de linha custa um múltiplo do modelo pequeno.

Guarda esses números, porque todo vazamento que vem a seguir é, no fim, uma multiplicação simples: quantidade de token errado × preço do token × número de chamadas por dia. Quando você tem mil requisições por dia, cada 500 tokens de gordura que você corta no prompt viram dinheiro de verdade no fim do mês. (E olha que token é só um item de linha da fatura real de um agente em produção — o balancete completo, com os outros baldes de custo, eu abri neste post de TCO.)

Vazamento 1: contexto inflado

Esse é o campeão. Você monta um chat, ou um agente, e a cada nova mensagem reenvia todo o histórico da conversa. Mais documentos colados "por garantia". Mais o resultado das últimas chamadas de ferramenta. A cada turno o prompt cresce, e você paga input por tudo de novo, do zero.

O detalhe perverso: o custo não é linear, é quadrático na prática. Numa conversa de 20 turnos, o turno 20 carrega os 19 anteriores. Some isso e você pagou pelo turno 1 vinte vezes.

O conserto tem três camadas:

• Corta o que não é usado. Não jogue um PDF de 30 páginas no prompt se a resposta usa um parágrafo. Recupere o trecho relevante com RAG, quando ele faz sentido, e mande só ele.
• Resuma o histórico antigo. Em vez de reenviar 19 turnos crus, compacte os mais antigos num resumo curto e mantenha só os últimos turnos na íntegra.
• Cacheia o que é estável. Se o system prompt e os documentos de base não mudam entre chamadas, eles não deveriam ser cobrados como input novo toda vez. (Mais sobre isso na seção de caching.)

Vazamento 2: prompt gordo

Diferente do contexto inflado, esse aqui é gordura que você escreveu de propósito e esqueceu de revisar. System prompt de 2 mil tokens com instrução repetida três vezes. Quinze exemplos de few-shot quando três resolviam. Aquele bloco de "regras importantes" que cresceu a cada bug e nunca foi podado.

Cada token desse vai junto em toda chamada. Um system prompt de 1.500 tokens, em 50 mil chamadas no mês, é 75 milhões de tokens de input só de instrução — antes de o usuário digitar qualquer coisa.

O conserto é chato e funciona: trate o prompt como código. Revise, corte redundância, meça. Tire um exemplo de few-shot e veja se a qualidade cai — muitas vezes não cai. Prompt enxuto não é só mais barato, costuma ser mais preciso, porque o modelo tem menos ruído pra desfocar.

Vazamento 3: modelo errado pra tarefa

Esse é o que mais dói quando você percebe. Você plugou o modelo mais forte em tudo — porque "é o melhor" — e está pagando preço de Opus pra fazer trabalho de Haiku.

Faz a conta com os números de cima: Opus 4.8 a US$ 5 / US$ 25, Haiku 4.5 a US$ 1 / US$ 5. É 5x no input e 5x no output. Se a sua tarefa é classificar um ticket, extrair um campo de um texto, decidir um roteamento ou resumir um parágrafo, o modelo pequeno entrega — e você acabou de cortar 80% do custo daquela etapa trocando uma linha de config.

A regra prática: o modelo grande é pra raciocínio difícil, código, decisão com nuance. O modelo pequeno é pra classificação, extração, formatação, roteamento. A maioria dos pipelines de produção tem muito mais tarefa de modelo pequeno do que o time imagina. Mapeie cada chamada de LLM do seu sistema e pergunte, uma por uma: isso aqui precisa mesmo do modelo caro? Esse roteamento por tarefa é, sozinho, a maior economia estrutural disponível pra quem acha a API da OpenAI cara ou a conta da Anthropic salgada.

Vazamento 4: retry e loop de agente sem teto

Produção tem erro: rate limit, timeout, resposta malformada. Aí você põe retry. Saudável — até virar vazamento. Um retry com backoff que reenvia o prompt gordo inteiro paga o input de novo, a cada tentativa. Três retries num prompt de 8 mil tokens são 32 mil tokens pagos pra obter uma resposta.

Pior ainda é o loop de agente sem limite. O agente chama uma ferramenta, recebe o resultado, decide chamar de novo, e a cada passo o contexto acumulado vai junto. Sem um teto de iterações, um agente confuso roda dez passos onde dois bastavam — e cada passo é uma chamada de LLM com o histórico inteiro.

Conserto:

• Teto de iterações em todo loop de agente. Sempre. Se bateu o limite, para e devolve o que tem.
• Retry inteligente: só re-tente o que falhou, com backoff exponencial, e não em cima de erro que retry não resolve (um 400 de prompt inválido não melhora na segunda).
• Observabilidade de tokens. Logue tokens por chamada e por sessão. Um loop descontrolado aparece como um pico óbvio — se você estiver olhando.

Vazamento 5: output sem rédea

O input você controla. O output, muita gente esquece — e output é o token mais caro da tabela, tipicamente 4 a 5 vezes o preço do input.

Os sintomas: não setar max_tokens e deixar o modelo escrever um ensaio quando você queria um sim/não. Pedir um JSON e receber o JSON embrulhado em três parágrafos de explicação. Mandar o modelo "repetir o texto corrigido inteiro" quando bastava devolver as diferenças.

Conserto direto: defina max_tokens de acordo com o que a tarefa realmente precisa. Peça o formato mais curto que serve — saída estruturada em vez de prosa. E nunca peça pro modelo te devolver de volta um conteúdo grande que você já tem; peça só o delta.

As duas alavancas que cortam mais: caching e batch

Os cinco vazamentos acima são higiene. Estas duas alavancas são onde a conta cai de degrau — e as duas são quase de graça pra ligar.

Prompt caching. Se você reenvia o mesmo prefixo estável (system prompt, instruções, documentos de base) em muitas chamadas, está pagando input cheio por algo que não mudou. O caching resolve. Na Anthropic, ler do cache custa 0,1x o preço de input — um desconto de 90% — enquanto escrever no cache custa 1,25x no modo de 5 minutos. Ou seja: o caching já se paga na primeira leitura (docs oficiais). Na OpenAI é ainda mais fácil: o caching é automático, sem mudança de código, pra qualquer prompt com 1.024 tokens ou mais, e corta até 90% do custo do input repetido (docs da OpenAI). Tem gente relatando conta caindo de US$ 720 pra US$ 72 por mês só ligando isso (relato).

Um detalhe que muda o desenho do prompt: o cache casa por prefixo. Então coloque o que é estável no começo (system, documentos, exemplos) e o que muda no fim (a pergunta do usuário). Inverteu a ordem, quebrou o cache.

Batch API. Se a tarefa não precisa de resposta em tempo real — classificar um backlog, gerar embeddings de um dataset, processar relatórios noturnos — não pague preço de tempo real. A Batch API da OpenAI dá 50% de desconto em input e output, com entrega em até 24 horas (docs da Batch API). E o melhor: batch empilha com caching. Uma requisição em batch e cacheada pode chegar a custar uma fração do preço de uma chamada síncrona sem cache.

FAQ rápido

Trocar pra um modelo mais barato não vai derrubar a qualidade? Depende da tarefa. Pra raciocínio difícil, sim, o modelo grande importa. Pra classificar, extrair e formatar, o modelo pequeno costuma empatar. A forma certa de decidir não é no chute: monte um conjunto de 30–50 casos reais, rode nos dois modelos e compare. Quase sempre dá pra rebaixar parte do pipeline sem o usuário perceber.

Prompt caching tem custo escondido? Escrever no cache custa um pouco mais que o input normal (1,25x na Anthropic no modo de 5 min), então ele só compensa se aquele prefixo for lido de novo dentro da janela. Pra prefixo estável e tráfego frequente, compensa quase sempre. Pra um prompt único que nunca repete, não cacheie.

Como eu sei qual vazamento é o meu sem chutar? Instrumentação. Logue tokens de input e output por chamada, por endpoint e por modelo. Sem isso você está otimizando no escuro. Com isso, o vazamento dominante aparece sozinho no topo do gráfico — e você ataca o que paga, não o que parece.

Batch serve pra chatbot ao vivo? Não. Batch é assíncrono, com janela de até 24h. É pra trabalho que pode esperar: processamento em massa, geração de embeddings, jobs noturnos. Pro fluxo em tempo real, suas alavancas são caching, prompt enxuto e o modelo certo.

Como reduzir o custo de API de IA sem cortar feature

Recapitulando os cinco vazamentos: contexto inflado, prompt gordo, modelo errado pra tarefa, retry/loop sem teto e output sem rédea. Some a isso as duas alavancas estruturais — caching e batch — e dá pra cortar metade de uma conta de API de LLM sem encostar em nenhuma feature. A ordem de ataque é simples: meça primeiro, ataque o vazamento dominante, repita.

O ponto mais importante não é nenhum truque isolado. É que economizar token em produção é decisão de arquitetura, não de prompt bonito. Onde entra cache, qual modelo serve cada etapa, onde cabe batch, como o agente decide parar — isso se desenha antes de escrever a primeira linha, e é exatamente o tipo de decisão que a gente coloca na mesa no Workshop Arquitetando Soluções de IA, montando soluções com agents do jeito que aguentam conta e carga de verdade.

Conta de IA cara quase nunca é problema de preço de tabela. É vazamento. Agora você sabe onde olhar.