Gateway de API para IA: como um prejuízo de R$ 30 mil me levou ao controle total de cada token

Todo mundo que trabalha com IA de verdade, no dia a dia, uma hora esbarra no mesmo problema chato: você não usa um modelo só. Usa a OpenAI para uma coisa, o Gemini para outra, o Claude para outra, e mais uma penca de modelos menores para tarefas específicas. Cada um com sua chave, seu formato de requisição, sua conta, seu jeito de cobrar. Vira uma bagunça de controlar. E o caminho fácil para arrumar essa bagunça é usar um gateway de terceiro, tipo OpenRouter — que resolve o embolado, mas cobra uma taxa por cima de tudo que passa.

Eu não quis pagar essa taxa. Então fiz o meu. No começo era só isso: um roteador de API próprio, simples, para reunir dezenas — depois centenas — de modelos atrás de uma rota só. Uma porta de entrada, um formato, uma conta minha para olhar. Um facilitador.

Este texto é sobre o que esse facilitador virou. Porque, poucos dias depois de montar a coisa, eu tomei uma pedrada que mudou o projeto inteiro — e me empurrou de "quero organizar" para "quero controle total, saber cada token que entra e sai, cada centavo, e nunca mais ser pego de surpresa". Hoje isso não é mais um gateway. É o que eu chamo de Prompthen Intelligence: um sistema que identifica o que entra e o que sai, limpa, reorganiza cada requisição para proteger o cache do provedor, mede tudo, e joga fora o ruído antes que ele me custe dinheiro.

Por ser proprietário, o que eu abro aqui são os resultados, a arquitetura e o mecanismo — não o passo a passo de implementação, o molho secreto. Mas por ser um estudo de caso, e não um artigo de vitrine, eu vou mais fundo no técnico do que num post comum: explico o quê, o como em nível de mecanismo, e principalmente de onde vem cada número. Inclusive os feios. Sobretudo os feios — e o primeiro deles custou trinta mil reais.

A catástrofe que mudou tudo: R$ 30 mil em vídeos que ninguém pediu

Quando você configura muitas APIs de uma vez, precisa saber quais estão de pé e quais caíram. Para isso existe uma verificação de vida — um liveness check — que bate em cada API de tempos em tempos e pergunta, na prática, "você está viva?". Eu deixei essa verificação ligada. E aqui veio o erro que me ensinou tudo.

Por um problema de configuração — que veio de uma peça pronta, o LiteLLM, que eu usava na base do roteador —, a verificação disparou a cada 30 segundos, contra todas as APIs configuradas. E eram muitas. O detalhe cruel é como esse check verifica se a API está viva: ele manda a API produzir alguma coisa. Numa API de texto, isso é um "hello" inofensivo, custa frações de centavo. Mas eu tinha API de imagem configurada. E, pior de tudo, tinha API de vídeo — a Veo3, do Google.

Então, a cada 30 segundos, dia e noite, o meu sistema mandava o Veo3 gerar um vídeo só para conferir se ele respondia. Vídeos sem sentido, que ninguém pediu, que ninguém assistiu, um atrás do outro, sem parar.

Eu não vi. E não vi por um motivo específico, que é o coração desta história: o Google, à época, não atualizava o gasto em tempo real — havia um atraso de cerca de 24 horas entre a conta rodar e o valor aparecer. Então o rombo cresceu invisível por um dia inteiro. Quando finalmente apareceu, eu já tinha gastado mais de R$ 30 mil gerando vídeo para ninguém. E, quando percebi, ainda havia atividade rodando — os R$ 30 mil poderiam facilmente ter virado 60, 100 mil, ou mais, se eu demorasse mais para olhar.

Um bug bobo de configuração, disparando uma verificação de vida a cada 30 segundos contra uma API de vídeo, me custou mais de R$ 30 mil em vídeos que ninguém pediu — e ficou invisível por 24 horas por causa de um atraso na cobrança. A origem de todo o meu sistema de controle de API foi um prejuízo, não uma boa ideia.

Desliguei tudo. Contatei o Google. No primeiro momento reportei como se fosse um problema do lado deles, mas fui investigar antes de acusar — e descobri que era um bug besta, meu, de configuração daquele liveness check herdado do LiteLLM. A culpa era minha.

E aqui eu preciso ser justo, porque o desfecho foi justo. Passei ao Google relatórios claros de tudo que rodou, cada requisição, cada vídeo gerado à toa. O Google reconheceu que aquilo era uma anomalia — um comportamento fora de qualquer padrão de uso real — e me deu um bom desconto. Eu paguei a minha parte, porque o bug era meu; o Google descontou a parte dele, porque havia uma corresponsabilidade honesta no meio. Se a cobrança fosse em tempo real, e se existisse um gatilho simples de "não gastar mais que X por dia", a própria API teria travado sozinha antes do estrago. E tem mais: naquela mesma semana, o Google mudou o cálculo de cobrança de um atraso de ~24 horas para poucos minutos. Não sei se o meu caso teve algo a ver com isso, e não vou me dar esse crédito. Mas registro o ponto.

Isso não é um ataque ao Google — pelo contrário. Eles entenderam, descontaram e melhoraram, e eu credito isso abertamente. É uma reflexão. Um atraso de 24 horas numa conta aberta, sem teto, é perigoso de um jeito que a maioria não percebe até levar a pancada. No meu caso deu R$ 30 mil e eu aguentei. Mas imagine um iniciante, alguém que está começando a mexer com IA agora, com um bug rodando invisível por um dia numa conta que não tem trava. Isso não estoura um orçamento — isso pode falir uma pessoa ou uma empresa pequena antes que ela sequer entenda o que aconteceu.

Foi essa pedrada na cara que me empurrou para a única conclusão possível: eu precisava de controle total. Saber cada token que entra e cada token que sai. Cada centavo. Poder definir bloqueios e limites por provedor e por modelo. Nunca mais um R$ 30 mil invisível — ou pior.

A virada: de facilitador a controle total

O roteador simples morreu ali. No lugar dele começou a nascer um sistema com uma obsessão só: visibilidade.

Eu queria que nada passasse por aquela rota sem eu saber exatamente o que era. Quanto custava. Para qual provedor ia. Quantos tokens tinha na entrada e quantos na saída. Queria poder olhar e dizer "isto aqui está gastando demais, trava" — antes da conta chegar, não depois. A diferença entre as duas coisas, eu tinha acabado de aprender, era de trinta mil reais.

E, quando você começa a medir cada token de verdade, você descobre coisas. A primeira delas veio de um lugar inesperado: dos limites da Anthropic.

Quem usava o Opus em 2025 lembra. No começo, os planos MAX rendiam muito — com um MAX você fazia o dia inteiro no Opus, nem precisava recorrer ao Sonnet para economizar. Com o tempo, os limites foram apertando. E apertando. Eu, que rodo IA em escala o dia todo, senti na pele: precisei de uma segunda conta, depois de uma terceira, de uma quarta. E quando quatro contas ainda não davam conta do meu volume, eu parei e pensei: em vez de só somar contas, por que eu não olho cada token que estou queimando, pelo gateway, e entendo o que de fato está acontecendo ali dentro?

Porque uma coisa eu desconfiava: nem tudo que eu estava pagando era trabalho útil. E foi aí, cavando cada requisição que passava pela minha rota, que eu bati na descoberta que mudou o projeto de vez — a verdade sobre o cache.

A verdade sobre o cache das CLIs que quase ninguém te conta

Deixa eu desarmar um mal-entendido que vejo o tempo todo, porque ele é a base de tudo que vem a seguir.

As pessoas pegam uma CLI de IA — o Claude Code, por exemplo —, olham o quanto ela gasta de token e comparam com o preço da API bruta, aquele preço de tabela por milhão de tokens. Fazem a conta e chegam a números absurdos, escandalosos. "Isso é um roubo, olha quanto custaria." E o cálculo está errado. Não errado por pouco — errado na premissa.

Porque a grande vantagem de uma CLI, a razão de ela existir e fazer sentido econômico, é a gestão eficiente de cache. Quando existe uma aplicação intermediando as suas mensagens, o cálculo correto não é com a API bruta. É com o cache. Um token que vem do cache custa por volta de 10% de um token normal. Dez por cento. Se a sua aplicação gerencia bem o cache, aquele número escandaloso da API bruta simplesmente não é o número que você paga.

E aí está o pulo do gato, a pergunta que quase ninguém faz:

A grande vantagem de uma CLI de IA é a gestão de cache — um token vindo do cache custa cerca de 10% de um token normal. Mas ninguém te diz qual é a taxa de cache hit da sua CLI. Sem essa taxa alta, você compara com o preço da API bruta e acha que é um roubo; com ela, o custo real é uma fração disso. É obrigação da aplicação te dar mais de 90% de cache hit — ou o seu dinheiro derrete.

Qual é a taxa de cache hit da sua CLI? Ninguém te diz. Não vem no relatório, não aparece na tela, não está na documentação. É um dado que eu fui atrás por conta própria, do meu lado, justamente para não jogar token e dinheiro fora. E virou a minha régua: a meta do gateway passou a ser, sempre, mais de 90% de cache hit. Abaixo disso, alguma coisa está errada e o dinheiro está saindo pelo ralo. Guardem esse número — 90% — porque ele é o eixo de tudo.

O bug do cache — e como engenhei em volta seguindo o manual da Anthropic

Foi perseguindo esse >90% que eu encontrei o problema.

Vou ser factual e sóbrio aqui, porque é assim que a coisa merece ser contada. Ao mapear input e output do meu Claude Code requisição por requisição, encontrei um comportamento de quebra de cache — em certas condições, o cache que deveria ser reaproveitado era invalidado, e uma mensagem que deveria custar 10% voltava a custar 100%. À época, isso não estava resolvido. Não vou chamar de "cheio de bugs" nem transformar isso em manchete de ataque, porque não é o ponto e não seria justo: o cache é a vantagem real de uma CLI, é o que faz ela valer a pena. O ponto é que, naquele momento, ele não estava se comportando como deveria, e eu dependia dele.

Como não estava resolvido do lado de lá, eu resolvi do meu lado. E não inventei nada exótico para isso — eu segui o próprio manual técnico da API da Anthropic. As regras de cache estão documentadas, são claras: a primeira mensagem de uma sessão paga o preço normal para escrever o cache; da segunda em diante, todo bloco que não mudou — o system prompt, as mensagens antigas, tudo que permanece intacto na sessão — pode ser lido do cache e paga aquela fração. O que quebra o cache é a mudança onde não deveria haver mudança. Um bloco que era para ficar parado, e não fica.

Então eu passei a montar, do meu lado, os pedaços que vão para a Anthropic. O gateway garante que os blocos que precisam ficar intactos fiquem de fato intactos, na ordem certa, no lugar certo do cache. Funcionou. A taxa de cache hit subiu e ficou onde eu queria. E, uma vez que funcionou para a Anthropic, eu estendi a mesma lógica para todas as APIs, qualquer modelo — porque o princípio de proteger o cache é o mesmo em toda parte.

Mas foi montando esses pedaços, olhando cada bloco que entrava e saía, que eu topei com algo pior que a quebra de cache. Um desperdício estrutural. Ruído.

O ruído: por que a sua janela de contexto está cheia de lixo

Quando você finalmente enxerga a estrutura inteira de uma requisição — não a versão bonita da tela, mas o que de fato é empacotado e mandado para o modelo —, você vê coisas que não deveriam estar ali. Dados, tokens, conteúdo que é puro ruído. Lixo. Informação que não precisava ser enviada, e repetição que não precisava se repetir.

Deixa eu dar os três exemplos concretos que mais me marcaram, porque eles explicam de onde o dinheiro estava vazando.

O primeiro: as skills. Digamos que você tenha 20 skills num projeto. Quando você não está usando nenhuma, só um pedacinho de cada vai para a janela — o resumo, o nome, o gatilho. Tudo bem. O problema é o como. O correto seria esses pedaços entrarem uma vez, logo depois do system prompt, e ficarem ali intactos — gasta uma vez, e daí em diante é cache. Mas não é o que acontece. As skills são reinjetadas a cada mensagem. Você manda um simples "oi", e junto vão de novo os pedaços de todas as skills. Manda outra mensagem, vão de novo. E de novo. Se são 20 skills a uns 2 mil tokens de resumo, são milhares de tokens repetidos a cada turno da conversa — e cada repetição, além de custar, quebra o cache do bloco.

O segundo: o MCP e os lembretes de sistema. Mesma doença. As instruções de MCP, os system-reminders, os ecos de configuração — repetidos, mensagem após mensagem, empilhando dentro da janela. Só a deduplicação de MCP, no meu sistema, tira da ordem de 120 KB por requisição em conversas longas. Cento e vinte kilobytes de repetição, por requisição, que não precisavam existir. O bloco de ambiente, diretório e git, que chegava a uns 80 mil bytes, eu enxuguei para cerca de 13 mil.

O terceiro, o pior de todos: os sub-agentes. Aqui a coisa era realmente absurda. Quando você aciona um sub-agente para uma tarefa atômica — um testador, um designer, um agente que faz só uma coisa —, o system prompt dele deveria conter só o que é relacionado àquela tarefa. Só isso. Mas o que eu encontrei foi o sub-agente herdando tudo: o system padrão, mais o CLAUDE.md global, mais o CLAUDE.md do projeto, mais o system do próprio sub-agente, tudo colado um embaixo do outro.

Encontrei sub-agentes de IA que já começavam saturados: em vez de carregar só a instrução da sua tarefa atômica, herdavam a pilha inteira — system padrão, memória global, memória de projeto e o próprio system — colada de uma vez. Um testador não precisa das regras do projeto inteiro para rodar um teste. Ele começava cansado, com regras que nem deveria ter.

Eu limpei isso. Identifiquei onde cada pedaço era montado e reorganizei: o sub-agente agora carrega o system padrão mais o seu próprio system, e nada além disso. Leve. Só o essencial da tarefa. E aqui é útil dizer como o gateway faz a limpeza, porque é o mecanismo que sustenta os números que vêm a seguir: ele relocaliza o que é estável na sessão — o catálogo de skills, a autoridade do CLAUDE.md — para fora do fluxo de mensagens que muda a cada turno, e coloca isso no bloco do prefixo que fica estável no cache. Depois, tira do fluxo de mensagens toda a duplicata daquilo. Duas coisas de uma vez: economiza token e impede o prefixo cacheável de ficar mudando à toa. Limpa e reorganiza.

Agora, o número que resume esse desperdício — e eu vou ter o mesmo cuidado que tive com o "80%" do NTC, porque é fácil exagerar aqui e eu não vou:

Nos meus testes e estudos, numa janela de contexto longa — do tipo 1 milhão de tokens ocupada em 70% —, algo em torno de 80% do conteúdo é ruído: informação desnecessária somada a repetição que não precisava acontecer. Mas atenção: esse "~80%" vale para o contexto longo e profundo, nunca como média de tudo. Na média de todo o tráfego, o desperdício é bem menor. O ruído cresce com a profundidade da janela.

Guardem essa ressalva. Ela é a diferença entre um número honesto e um número inflado, e mais adiante eu mostro exatamente onde os 80% aparecem e onde não aparecem.

Os números, e de onde cada um veio

Chega de história. Agora os dados. Tudo abaixo foi apurado em modo somente-leitura, direto do sistema em produção. Vou separar com cuidado o que é uma coisa do que é outra, porque tem três mecanismos diferentes aqui — o cache de custo, a redução de tokens, e o cache interno — e misturá-los seria vender fumaça.

O cache de custo: 82,3% mais barato, US$ 45.808 em 16 dias

Este é o número de manchete, o "dinheiro que parou de sair pelo ralo". Sobre uma janela de 16 dias e 48.132 registros, a taxa de cache hit ficou em 93,4% no geral e 94,5% no Claude Code. Esse é o cache de prompt da Anthropic — e já aviso, para não confundir mais adiante: ele não é a mesma coisa que o cache interno de 63,2% que eu descrevo lá embaixo. São dois mecanismos distintos.

O efeito no custo: se cada requisição fosse cobrada sem cache, o preço de tabela cheio, daria US$ 55.650. Com o cache funcionando como configurei, o custo real foi de US$ 9.842. A diferença — US$ 45.808 economizados em 16 dias — é uma redução de 82,3% no total, chegando a 82,5% no recorte do Claude Code.

Repare que essa economia não vem de comprimir nada nem de trocar de modelo. Vem só de garantir que o cache do provedor seja de fato reaproveitado, do jeito que o manual dele manda — os tais blocos intactos, no lugar certo, com mais de 90% de cache hit.

A redução de tokens: 43,4% na média, até ~84% no fundo da janela

Aqui é onde eu preciso ser mais rigoroso de todos, porque é onde mora o "80%" — e onde seria facílimo mentir por omissão.

A limpeza e reorganização que descrevi (tirar o ruído, relocar o que é estável) foi medida com um tokenizador, o cl100k, sobre 600 pares reais de requisição antes e depois. Na agregação de todo o tráfego, a redução de tokens foi de 43,4%. Esse é o número honesto da média. Não é 80%. É quarenta e três.

Mas a média esconde a história de verdade, que é: o desperdício cresce com a profundidade do contexto. Quebrando por tamanho de janela, fica assim:

• Abaixo de 10 mil tokens: redução de ~0,1%. Praticamente nada — janela pequena quase não tem ruído acumulado.
• De 10 a 50 mil: ~1,3%.
• De 50 a 100 mil: ~20,9%.
• De 100 a 200 mil: ~25%.
• Acima de 200 mil: ~52,9%.
• E nos contextos mais profundos, de 1,5 a 2,7 milhões de tokens: entre 79,7% e 83,9%. O caso extremo: uma requisição de 2,67 milhões de tokens caiu para 431 mil — 83,9% de redução.

A redução de tokens do gateway é de 43,4% na média de todo o tráfego — mas dispara para quase 84% nos contextos mais profundos. É por isso que o "~80% de ruído" só é verdade na janela longa: quanto mais fundo o contexto, mais repetição de skill, MCP e lembretes se acumulou ali dentro. Numa janela rasa, quase não há o que limpar. Numa de dois milhões de tokens, quatro quintos podem ser lixo.

Este é o ponto que eu não abro mão de deixar claro: os 43,4% e os ~84% são a mesma medição, olhada de dois ângulos. Um é a média de tudo; o outro é o pico no fundo do poço. Citar o 84% como se fosse a média seria desonesto. Citar só o 43% escondendo o pico seria esconder a descoberta. Os dois juntos, com o rótulo certo, são a verdade.

Uma nota de método, porque ela importa: quando a limpeza remove ruído do fluxo de mensagens, a seção de sistema até cresce — porque é ali que o gateway injeta, de propósito, a autoridade consolidada e o catálogo de skills, no bloco estável do cache. A economia líquida vem de tirar as repetições do fluxo volátil, não de encolher o system. Cerca de 56,5% do que se remove é inchaço do fluxo de mensagens: lembretes duplicados, ecos de CLAUDE.md, catálogo de skills reinjetado a cada turno, barulho de ambiente e git.

O cache interno com NTC: um mecanismo à parte

Além do cache do provedor, o gateway tem um cache interno — e este usa o NTC, a engenharia de prompt proprietária que criei, a mesma dos dois primeiros estudos de caso desta série. A ideia: pegar os blocos verbosos que se repetem, comprimi-los uma vez e reaproveitar a versão densa dali em diante.

Os números desse cache interno: 47 blocos verbosos foram comprimidos uma única vez (por um modelo pequeno, o Haiku) e, cumulativamente, reusados 1,52 milhão de vezes — uma amortização da ordem de 32 mil vezes por bloco. A compressão média por bloco foi de 63,6%, e a taxa de acerto desse cache interno é de 63,2%.

E aqui vai o alerta para não confundir, que eu repito de propósito: esses 63,2% do cache interno não são os 93,4% do cache de prompt da Anthropic. Um comprime blocos repetidos com NTC; o outro reaproveita o prefixo intacto no provedor. Mecanismos diferentes, números diferentes, propósitos diferentes. Somar os dois, ou trocar um pelo outro, seria erro.

A prevenção de quebra de cache: 99,5% preservados — mas não zero

O gateway também migra os pontos de controle de cache quando reorganiza os blocos. O resultado medido: 99,5% dos breakpoints preservados (596 de 599), com a escrita de cache respondendo por apenas 4,73% do input e a leitura de cache por 94,5% — algo como 20 vezes de reúso para cada escrita.

E aqui a honestidade obriga uma ressalva: eu não digo "zero quebras". A taxa residual de quebra é de 1,55% das transições. É baixa, é o que faz o cache render, mas não é zero — e prometer zero seria a mesma mentira de qualquer número redondo bonito demais.

A escala: 250 mil requisições, 99,63% de sucesso

Para dar dimensão do que passa por essa rota: 250.000 requisições, com 99,63% de sucesso (respostas 2xx), 97,9% delas usando ferramentas, distribuídas por 7 a 8 backends e 42 modelos. A latência mediana é de 11,3 segundos, com o percentil 95 em 58,1 segundos; o caminho dominante, a Anthropic com cerca de 90% do tráfego, é o mais rápido, com mediana de 10,6 segundos. O motor por baixo tem cerca de 91 mil linhas de código e 680 arquivos de teste com 23.398 funções de teste.

A consequência maior não foi economia. Foi eficiência.

Se você leu só para saber quanto eu economizei, chegou na parte que eu economizei. Mas ela não é a parte mais importante — e isso conversa direto com os dois estudos de caso anteriores, então preciso contar.

Antes de eu limpar o ruído, acontecia uma coisa curiosa no meu dia a dia. O agente, trabalhando numa janela de 1 milhão de tokens, começava a reclamar por volta dos 40% de uso. Ele recomendava — usando a memória permanente do Exocortex — que eu salvasse e abrisse uma sessão nova, porque a janela estava "ficando cheia". Eu achava exagero. Quarenta por cento não é cheio.

Depois que limpei o ruído, ele parou de reclamar nesse ponto. E aí a ficha caiu: ele estava certo antes, e certo agora, pela mesma razão. Antes, aos 40% de janela, a maior parte daquilo era lixo — repetição de skill, MCP duplicado, lembrete ecoado, sub-agente saturado. Não eram 40% de conteúdo; eram 40% de janela dos quais talvez 15% fossem conteúdo real e o resto, ruído. O agente sentia o peso e reagia certo. Depois da limpeza, 40% de janela passaram a ser 40% de conteúdo de verdade — e aí não havia motivo para reclamar.

Na prática, coisas que enchiam 70% a 80% de contexto em poucas horas passaram a ficar em torno de 20%. A diferença foi brutal.

A limpeza do ruído não me deu só economia — me deu eficiência. Trabalhos que enchiam 70% a 80% da janela de contexto em poucas horas passaram a ocupar cerca de 20%, porque o que enchia antes era, em boa parte, repetição desnecessária. Uma janela mais limpa não é só mais barata: ela cabe mais trabalho de verdade no mesmo espaço.

É a mesma tese que sustenta o NTC e o Exocortex, agora aplicada na camada da API. O NTC mostrou que o inimigo da compreensão da IA não é a densidade, é a bagunça. O Exocortex mostrou que o inimigo da continuidade não é a quantidade de história, é o ruído dela. E o gateway mostra a terceira face da mesma moeda: o inimigo do custo e da janela de contexto não é o tamanho do trabalho — é o lixo que se acumula junto com ele. Sinal sem ruído, os três dizem a mesma coisa em camadas diferentes.

As limitações (porque candura é credibilidade)

Um estudo de caso que só tem boa notícia é panfleto. Então, com o mesmo cuidado dos números bons, os buracos — e aqui tem armadilha de sobra para quem quer exagerar.

Byte não é token, e eu meço os dois. A reorganização foi medida tanto em bytes quanto em tokens. Os números de token que eu cito usam o cl100k — um tokenizador de referência que uso como aproximação offline do tokenizador real da Anthropic. A proporção é robusta, mas o número absoluto de token é uma estimativa por proxy, e eu rotulo assim de propósito. Não vou fingir que medi com o tokenizador exato do provedor quando usei um substituto confiável.

Os dois "80%" são coisas diferentes — e não podem ser somados. O "80% de custo" do cache é uma coisa: é economia de dinheiro por reaproveitar o prefixo intacto. O "~80% de token" no contexto profundo é outra: é remoção de repetição na janela longa. São mecanismos distintos, medidos de formas distintas. Juntar os dois num "olha, 80% de economia" seria exatamente o tipo de fumaça que eu não vendo. Um corta 82,3% do custo via cache; o outro remove até ~84% dos tokens só no fundo da janela.

A quebra de cache não é zero. Já disse acima, repito aqui porque é limitação: 1,55% de quebra residual. Baixo, não nulo.

O batch é um desconto configurado, e o dólar é só do corpus em disco. Sobre o batch (que explico a seguir), os US$ 259,75 economizados são reais — mas são o que eu consigo cravar sobre as 23.338 completions que estão medidas no corpus em disco. O desconto de 50% é uma taxa configurada, aplicada às contagens reais de token pelos preços de tabela. Eu não consultei os totais históricos ao vivo no Postgres — isso exigiria abrir credenciais do banco, o que evitei de propósito. Então o número é firme para o corpus medido, e eu não o extrapolo para "o total de sempre" que não fui buscar.

Os 43,4% são a média, não o teto — e nem o piso. Repito porque é o erro mais fácil de cometer lendo este post: a redução típica é 43,4%; o ~84% só existe no contexto mais profundo; e abaixo de 10 mil tokens a redução é quase nada, porque não há ruído a remover. O número depende inteiramente da profundidade da janela.

Por que virou "Prompthen Intelligence" — e o batch que veio junto

A essa altura você já entende por que eu parei de chamar aquilo de gateway.

Um gateway roteia. Ele pega a requisição de um lado e entrega do outro. O que eu tenho hoje faz muito mais do que rotear: ele identifica o que entra e o que sai, limpa o ruído, reorganiza cada requisição para proteger o cache do provedor seguindo as regras dele, mantém um cache interno com NTC para o que se repete, roteia por mais de 100 modelos, e roda comparativos — para cada requisição, ele me mostra quanto custaria se fosse bruta, sem cache hit, sem o cache NTC adicional, sem a reorganização. Com travas e alertas por cima de tudo, para eu extrair o melhor de cada API sem nunca mais ser pego de surpresa. Isso não é um portão. É inteligência aplicada ao tráfego. Daí o nome.

E tem uma peça que fecha o sistema para trabalho em escala: o batch. Batch é mandar requisições para o provedor em lote, sem pressa — não é tempo real, pode levar até 24 horas para voltar —, e em troca você paga cerca de 50% menos. Trabalho de alta escala, meu e de clientes, do tipo 60 a 80 mil requisições de uma vez, eu não faço mais direto pela API em tempo real. Faço via batch: junto tudo, organizo os dados num banco em lote, mando, coleto, reorganizo os tokens recebidos e redistribuo. Controlando cada token, com cache, pagando metade — e ainda com cache hit nos provedores que aceitam.

Quanto isso rende, medido de verdade: US$ 259,75 economizados sobre 23.338 completions reais de batch (do Gemini), aplicando o desconto de 50% às contagens reais de token pelos preços publicados. É o número do corpus que está em disco — sólido para esse recorte, e eu não invento o total histórico que não consultei.

Uma última coisa, sobre a casa ser minha. Hoje eu uso, via gateway, qualquer modelo que eu queira dentro do meu Claude Code — porque a rota unificada me deixa apontar o CLI para o backend que fizer mais sentido para a tarefa. Foi para isso que o sistema nasceu: controle. Da pedrada de R$ 30 mil eu tirei a visibilidade; dos limites que apertaram eu tirei a obsessão por medir cada token; do cache eu tirei a economia; do ruído, a eficiência. Cada camada veio de um tropeço, e cada tropeço virou controle.

Isso fecha com a ideia que guia tudo o que faço no método Prompthen, que também criei: a complexidade deve ser opcional, nunca uma barreira. Você não precisa entender como um gateway reorganiza blocos de cache para colher o resultado de uma IA que custa menos e trabalha melhor. A porta está aberta para quem quiser abrir o capô — este texto é essa porta —, mas ninguém é obrigado.

E, para ser transparente sobre o sustento de quem escreve: o método e o conteúdo são gratuitos. O que se cobra, quando se cobra, é o serviço de aplicar isso na dor específica de alguém — consultoria, treinamento, projeto. Menciono uma vez só, para você saber de onde vem o pão, e sigo. O conhecimento fica aberto.

No fim, este gateway não é sobre roteamento esperto. É sobre uma teimosia que nasceu de um susto de trinta mil reais: a de que você não deveria pagar por um único token que não faz trabalho. Veja cada token que entra e sai, jogue fora o ruído, proteja o cache — e o mesmo modelo, no mesmo trabalho, passa a custar uma fração e a render muito mais. Eu aprendi isso da pior forma. Você pode aprender por este texto.