A maioria das equipes paga demais por chamadas de API de AI. Não porque escolheram o modelo errado, mas porque estão ignorando três otimizações que exigem mudanças mínimas no código: prompt caching, roteamento inteligente de modelos e processamento em lote (batch processing).
Aqui está uma análise de cada técnica com números reais.
Se você ainda está decidindo se o seu mix atual de provedores é o problema, leia primeiro a comparação de preços. Se a sua maior dor são as retry storms ou o throttling dos provedores, em vez do gasto bruto, combine esta página com o guia de rate limiting.
1. Prompt Caching: A maior vitória
Se a sua aplicação envia o mesmo prompt de sistema em cada requisição, você está pagando o preço total por tokens que o provedor já processou.
Como funciona
A OpenAI faz o cache de prompts automaticamente para inputs acima de 1.024 tokens. Tokens em cache custam 50% do preço padrão de input. Você não precisa mudar nada no seu código.
A Anthropic usa caching explícito via breakpoints de cache_control. O custo de escrita é 25% maior que o input padrão, mas as leituras custam 90% menos. O TTL do cache é de 5 minutos, estendido a cada hit.
Na precificação mais recente da OpenAI, o desconto prático pode ser melhor do que as equipes esperam. O input em cache do GPT-4.1 tem o preço de um quarto do input padrão, o que significa que prefixos consistentes geram economias muito maiores do que a antiga ideia de “bom ter” sugeria.
Os cálculos
Considere um bot de suporte ao cliente típico:
- Prompt de sistema: 2.000 tokens
- Mensagem do usuário: média de 200 tokens
- 5.000 requisições/dia usando Claude Sonnet 4.6
Sem caching:
Custo diário de input = 5.000 × 2.200 tokens × $3.00/1M = $33.00
Com prompt caching da Anthropic (assumindo uma taxa de cache hit de 95%):
Escritas de cache: 250 × 2.200 × $3.75/1M = $2.06
Leituras de cache: 4.750 × 2.200 × $0.30/1M = $3.14
Tokens do usuário: 5.000 × 200 × $3.00/1M = $3.00
Total diário = $8.20 (75% de economia nos custos de input)
Implementação
from anthropic import Anthropic
client = Anthropic(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc"
)
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=[
{
"type": "text",
"text": "You are a customer support agent for Acme Corp...",
"cache_control": {"type": "ephemeral"} # This enables caching
}
],
messages=[{"role": "user", "content": user_message}]
)
# Check cache performance in response headers
# cache_creation_input_tokens vs cache_read_input_tokens
Para modelos da OpenAI, o caching é automático. Apenas certifique-se de que seus prompts excedam 1.024 tokens e mantenha o prefixo estático consistente entre as requisições.
Onde as equipes erram:
- colocar timestamps ou IDs de requisição no topo de cada prompt
- reordenar as instruções do sistema em cada chamada
- embutir contexto variável do usuário antes do prefixo estável
Se o prefixo mudar todas as vezes, o cache nunca ajudará. Trate o formato do prompt como uma primitiva de custo, não apenas um detalhe de prompt engineering.
2. Roteamento inteligente de modelos: Use o modelo certo para cada tarefa
Nem toda requisição precisa do seu modelo mais caro. Uma tarefa de classificação que o GPT-4.1 processa por $2,00/1M de tokens de input funciona tão bem com o GPT-4.1-mini a $0,40/1M, uma redução de custo de 5x.
A estratégia de roteamento
| Tipo de tarefa | Modelo recomendado | Custo de input/1M |
|---|---|---|
| Raciocínio complexo | Claude Opus 4.6 / GPT-4.1 | $5.00 / $2.00 |
| Chat geral | Claude Sonnet 4.6 / GPT-4.1 | $3.00 / $2.00 |
| Classificação, extração | GPT-4.1-mini / Claude Haiku 4.5 | $0.40 / $1.00 |
| Embeddings | text-embedding-3-small | $0.02 |
| Formatação simples | DeepSeek V3 | $0.28 |
Implementação
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
def route_request(task_type: str, messages: list) -> str:
"""Pick the cheapest model that handles this task well."""
model_map = {
"classification": "gpt-4.1-mini",
"extraction": "gpt-4.1-mini",
"summarization": "gpt-4.1-mini",
"complex_reasoning": "gpt-4.1",
"creative_writing": "claude-sonnet-4-6",
"code_generation": "claude-sonnet-4-6",
}
model = model_map.get(task_type, "gpt-4.1-mini")
response = client.chat.completions.create(
model=model,
messages=messages
)
return response.choices[0].message.content
Economia real
Um assistente de programação que roteia 60% das requisições (linting, formatação, completamentos simples) para o GPT-4.1-mini e 40% (arquitetura, debugging) para o Claude Sonnet 4.6:
Antes (tudo no Claude Sonnet 4.6):
1.000 req/dia × 3K input × $3.00/1M = $9.00/dia
Depois (divisão 60/40):
600 req × 3K × $0.40/1M = $0.72/dia (mini)
400 req × 3K × $3.00/1M = $3.60/day (sonnet)
Total = $4.32/dia (52% de economia)
3. Processamento em lote (Batch Processing): Preços mais baixos para trabalho não urgente
A OpenAI oferece uma Batch API com 50% de desconto em tokens de input e output. O trade-off: os resultados são entregues em até 24 horas em vez de tempo real.
A Anthropic também oferece descontos de 50% em batch para modelos suportados. Se a sua carga de trabalho for noturna, assíncrona ou orientada a revisão, raramente há um bom motivo para pagar preços de tempo real.
Bons candidatos para batching:
- Geração de conteúdo noturna
- Classificação de documentos em massa
- Rotulagem de datasets
- Geração de relatórios agendados
# Create a batch file (JSONL format)
import json
requests = []
for i, doc in enumerate(documents):
requests.append({
"custom_id": f"doc-{i}",
"method": "POST",
"url": "/v1/chat/completions",
"body": {
"model": "gpt-4.1-mini",
"messages": [
{"role": "system", "content": "Classify this document..."},
{"role": "user", "content": doc}
]
}
})
# Write JSONL file
with open("batch_input.jsonl", "w") as f:
for req in requests:
f.write(json.dumps(req) + "\n")
# Submit batch
batch_file = client.files.create(file=open("batch_input.jsonl", "rb"), purpose="batch")
batch = client.batches.create(input_file_id=batch_file.id, endpoint="/v1/chat/completions", completion_window="24h")
Bons candidatos para batching dentro de um produto real:
- jobs de atualização de conteúdo noturnos
- sumarização de tickets de suporte
- preenchimento retroativo (backfills) de embeddings
- revisões de grandes bases de código ou documentos
- notificações de usuário de baixa prioridade
Candidatos ruins:
- respostas de chat
- assistência de código interativa
- fluxos de trabalho onde a próxima ação do usuário depende da resposta imediatamente
4. Bônus: Reduza a contagem de tokens
Antes de otimizar no nível da API, verifique se você está enviando mais tokens do que o necessário.
Desperdício comum:
- Prompts de sistema prolixos que repetem instruções que o modelo já segue
- Incluir o histórico completo da conversa quando apenas as últimas 3-5 interações importam
- Enviar HTML/markdown bruto quando texto simples funcionaria
- Não usar
max_tokenspara limitar o tamanho do output
Uma redução de 30% no tamanho do prompt traduz-se diretamente em custos de input 30% menores.
A maneira mais fácil de encontrar desperdício é registrar o tamanho do prompt por rota ou funcionalidade. A maioria das equipes não tem um problema de preço de modelo. Elas têm um problema de “o mesmo prompt inchado é enviado 100.000 vezes por dia”.
5. Adicione visibilidade de custos antes de otimizar às cegas
A otimização de custos falha quando as equipes otimizam por intuição.
Antes de mudar as regras de roteamento, registre:
- nome da rota ou funcionalidade
- modelo
- tokens de input
- tokens de output
- hit ou miss de cache
- contagem de retentativas
- latência visível para o usuário
Isso permite que você responda às perguntas que importam:
- Qual rota é cara porque é genuinamente útil?
- Qual rota é cara porque o prompt é um desperdício?
- Qual rota deve mudar para batch?
- Qual rota deve mudar para um nível de modelo mais barato?
Se você não puder responder a essas quatro perguntas, sua “otimização de custos” apenas deslocará o custo de lugar.
6. Uma ordem real de otimização
A ordem mais eficaz geralmente é:
- Remova o desperdício óbvio de tokens.
- Ative ou corrija o caching.
- Separe tarefas baratas de tarefas caras.
- Coloque em batch qualquer coisa não urgente.
- Só então renegocie o mix de provedores.
Essa ordem importa porque as maiores economias geralmente vêm antes da troca de provedor. Se você trocar de fornecedor sem corrigir o formato do prompt, continuará pagando pela mesma ineficiência.
7. Um rollout concreto de antes e depois
Considere um fluxo de trabalho de suporte que atualmente faz isso em cada requisição:
- envia um prompt de sistema de 2.000 tokens
- chama um modelo premium para todas as requisições
- tenta novamente o mesmo formato de requisição em falhas temporárias
- executa resumos noturnos de forma síncrona em vez de em batch
A primeira versão muitas vezes parece “simples” porque tem apenas um caminho de código. Financeiramente, ela está fazendo quatro coisas caras ao mesmo tempo.
Um rollout mais eficiente se parece com isto:
- Mova o texto de política estável para a frente do prompt para que o caching possa realmente funcionar.
- Roteie classificação, extração e resumos curtos para um nível de modelo mais barato.
- Reserve o modelo premium para escalonamento, raciocínio complicado ou síntese da resposta final.
- Envie resumos noturnos e backfills para batch.
- Revise os logs semanalmente em busca de rotas cujo formato do prompt desviou e acabou com a eficiência do cache.
Esse tipo de rollout não exige uma reescrita. Exige uma semana de instrumentação e a disposição de tratar prompts e roteamento como superfícies de produção.
8. O que não fazer
A maneira mais rápida de desperdiçar um esforço de otimização de custos é otimizar a coisa errada.
Evite estas armadilhas:
- trocar de provedores antes de medir o desperdício de prompt
- rotear tarefas baratas para modelos baratos sem validar a qualidade do output
- habilitar caching em prompts cujos prefixos mudam a cada requisição
- colocar em batch trabalho voltado para o usuário que realmente precisa de respostas em tempo real
- olhar apenas para o preço do token e ignorar o overhead de retentativas, latência e fallback
O trabalho de custo é bem-sucedido quando o produto ainda se comporta bem após a economia ser implementada. Se a UX piorar, a vitória na planilha é falsa.
Juntando tudo
| Técnica | Esforço | Economia típica |
|---|---|---|
| Prompt caching | Baixo (adicione cache_control) | 40-75% no input |
| Roteamento de modelos | Médio (classifique tarefas) | 30-50% no geral |
| Processamento em lote | Médio (fluxo assíncrono) | 50% em jobs de batch |
| Redução de tokens | Baixo (ajuste prompts) | 10-30% no input |
Essas técnicas se somam. Uma equipe que implementa as quatro pode realisticamente reduzir sua conta mensal de API de $3.000 para menos de $1.000 sem qualquer degradação na qualidade do output.
O insight principal: a otimização de custos em APIs de AI não se trata de encontrar provedores mais baratos. Trata-se de usar o modelo certo, no nível de preço certo, com a estratégia de caching certa, para cada tarefa específica.
Se você já usa vários provedores, o lado operacional também importa. O guia de migração e a comparação do OpenRouter ajudam a decidir quando é hora de centralizar o roteamento em vez de continuar corrigindo integrações separadas.
Comece a otimizar hoje: o LemonData oferece acesso a mais de 300 modelos através de uma única chave de API, com suporte a prompt caching para as famílias de modelos OpenAI e Anthropic e um lugar único para comparar o uso entre eles.
