Por que cache não resolveu a conta de IA do Kilo (e o que isso ensina pra times BR)

TL;DR — A Kilo, agente de código open-source, descobriu na prática que cache não resolve fatura de IA. Mesmo com 80%+ de cache hit, o spend continuou alto porque o volume é alto e cada chamada não-cacheada ainda é cara. A alavanca real foi routing automático: mandar 80-90% das requests pra modelos baratos (tiny/balanced) e só usar frontier (top tier) quando necessário. Resultado: 1/3 do custo por request quando o gateway escolhe o modelo, em vez do usuário escolher.

O que aconteceu na Kilo

A Kilo opera um agente de coding open-source com volume gigante de chamadas LLM por dia. Em 2026, a equipe publicou via ByteByteGo os números do gateway próprio que construíram pra controlar custos.

Achados que importam pra qualquer time que opera IA em produção:

80 a 90% das requests não precisam de frontier model. Renomear variável, classificar intent, resumir arquivo — tudo isso roda em GPT-4o-mini, Claude Haiku, Mistral Small. Pagar Opus pra essas tarefas é como contratar um arquiteto sênior pra trocar uma lâmpada.
Cache ajuda, mas não resolve. Mesmo com cache hit acima de 80% em várias features, o custo total seguiu alto. Razão: o volume é enorme e a parte não cacheada ainda usava frontier model. Cache reduz redundância. Routing reduz o caro.
Roteamento automático cortou 1/3 do custo médio. Quando o gateway decide o tier (em vez do dev escolher manual), a economia é imediata. Por quê? Devs erram pra cima — “se for usar IA, melhor a melhor”. Roteador mede e escolhe certo.
Diferença entre tiers é dramática. Pro mesmo trabalho de coding, tier “balanced” custou 10x menos que tier “top” — sem queda perceptível de qualidade nas tarefas comuns.

E não é só Kilo. Um estudo conhecido de UC Berkeley + Anyscale (RouteLLM) mostrou 50% de corte de custo mantendo 95% da qualidade do frontier.

Por que isso é o “R” do método CARO

Quem acompanha a Veltrix conhece o Método CARO que estruturei pra controlar custos de IA:

C ompress — reduzir tokens redundantes (prompt caching, system prompt enxuto)
A ttribute — saber quem/o que consome (tag por feature, por cliente)
R oute — escolher o modelo certo pra cada task ← este post
O bserve — medir custo+qualidade em tempo real

Os 4 pilares são essenciais, mas Route é o que tem maior alavanca de economia. Por uma razão simples: a maioria do código de produção hoje usa GPT-4o ou Claude Sonnet como default, quando 80% das chamadas podiam rodar em modelos 10x mais baratos.

Onde times brasileiros perdem dinheiro

Acompanho times BR usando IA em produção há ~3 anos. Os 3 padrões mais comuns:

1. “Vamos usar GPT-4 pra tudo, é mais seguro”

Resultado real (cliente recente, B2B SaaS, 1.2M chamadas/mês):

89% das chamadas eram classificação de intent (1-5 palavras output) rodando em GPT-4o
Custo: R$ 47k/mês
Após routing pra GPT-4o-mini nas simples: R$ 13k/mês (-72%)
Queda de qualidade percebida: zero (medido com eval suite)

2. “Cache resolve, vou só botar Redis”

Cache exato pega ~15-30% em volume variado. Cache semântico chega em 30-50% (em FAQ/suporte). Mas mesmo a 50% de hit, a outra metade ainda paga o caro se você não roteia. Cache é necessário, não suficiente.

3. “Roteamento é complicado, deixa o dev escolher por código”

Dev tem viés. Sob pressão, escolhe sempre o “mais inteligente”. Resultado: você paga GPT-4o em 100% das calls quando precisava em 15%.

A solução é roteador automático: heurística simples (tamanho do prompt, max_tokens, keywords detectoras) decide o tier sem o dev pensar. Quando o dev quer override, manda header explícito — funciona como --seed em random: sai do auto quando precisa.

Como o gateway Veltrix faz isso

A Veltrix é compat OpenAI/Anthropic — qualquer SDK funciona como drop-in. Mas adicionamos 3 modos de routing:

# 1) Modelo direto (você escolhe)
client.chat.completions.create(
    model="claude-sonnet-4-5",
    messages=[...]
)

# 2) Tier explícito (você escolhe complexidade, gateway escolhe modelo)
client.chat.completions.create(
    model="tier:balanced",
    messages=[...]
)

# 3) Auto-routing (gateway decide tudo)
client.chat.completions.create(
    model="auto",
    messages=[...]
)

A heurística do auto é simples e rápida (zero latência adicional):

Tiny (Claude Haiku / GPT-4o-mini): prompt < 250 chars + max_tokens <= 150, OU keywords como “classifique”, “extraia”, “sentiment”
Balanced (Claude Sonnet 4.5 / GPT-4o): default — chat, summarization, code review
Top (Claude Opus 4.1 / o1): keywords como “raciocínio”, “plano”, “step by step”, “refatore”, OU prompt > 3000 chars OU max_tokens > 2000

Você pode customizar a heurística (env vars hoje, UI dashboard em breve) e fazer A/B test antes de promover.

E quando o roteador errar?

O artigo da Kilo lembra um trade-off real: roteador errar pra menos = qualidade ruim. Por isso a Veltrix tem 2 redes de segurança:

Fallback automático: se o tier tiny responder com confidence < threshold ou tool error → re-tenta no balanced (cliente nem percebe)
Eval contínuo: sample 1% das requests vai em paralelo no top pra comparar qualidade. Se drop > 5% → alerta no dashboard

Conclusão

A frase chave do artigo da Kilo é cirúrgica:

“Routing is no longer a cost optimization. It’s becoming what makes ambitious agents possible.”

Tradução: se você quer agentes que rodam por horas e fazem milhões de calls, routing automático deixa de ser feature legal e vira sobrevivência financeira.

Se você opera agentes, coding tools internas, ou qualquer fluxo IA com volume > 100k chamadas/mês — mede tier-mix hoje. Provavelmente está pagando 5-10x mais do que precisaria.

A Veltrix faz isso pra você (gateway compat, sem mudar código). Plano Stretch R$ 39/mês, 30 dias grátis no Premium do ebook “O Campo de Batalha dos Tokens”.

Quer entender mais a fundo? O ebook tem 80 páginas detalhando o método CARO com 3 casos reais de empresas BR que cortaram 30-50% da fatura aplicando o framework. Adquire aqui →