Por que seu agente de IA está queimando dinheiro (e como parar)
Por que ser um programador de verdade ainda importa (e o DeepSeek prova isso)
por Gustavo
Todo mundo está usando IA agora. Você cola um prompt, recebe código, copia, roda. Funciona. Até o dia em que para de funcionar, e você não sabe por quê.
Esse texto é sobre o que acontece quando você para de só usar e começa a investigar.
O desconto que ninguém estava recebendo
Alguns meses atrás, eu estava rodando um agente de código com DeepSeek, um modelo de linguagem chinês, open-source, dramaticamente mais barato que GPT-4 ou Claude. A página de preços dizia claramente: tokens de entrada cacheados custam 10% do preço normal. Um desconto de 90%.
Minha fatura não refletia nada disso.
Eu poderia ter ignorado. A maioria das pessoas ignora. Mas eu fui investigar.
O cache do DeepSeek funciona por prefixo de bytes. Se a requisição começa com exatamente os mesmos bytes da requisição anterior, o modelo reutiliza computações e você paga menos. Simples. O problema é que o framework que eu usava, como quase todos os frameworks de agentes disponíveis, reconstruía o prompt a cada turno. Injetava timestamps. Reordenava o histórico. Reserializava esquemas com espaçamento ligeiramente diferente. O prefixo nunca era idêntico. O cache nunca disparava.
Eu estava pagando preço cheio por tokens que o modelo já havia processado. Em cada turno. Em cada sessão.
Esse é o tipo de coisa que só aparece quando você para para medir. E só faz sentido quando você entende como o sistema funciona por baixo.
O que os papers ensinam que a documentação não conta
A DeepSeek publica papers técnicos detalhados sobre seus modelos. Não é comum no setor, OpenAI e Anthropic protegem esses detalhes cuidadosamente. Mas a DeepSeek descreve a arquitetura, os algoritmos de treinamento, os trade-offs de design.
Quando você lê esses papers, percebe que o desconto de cache não é acidental. O modelo usa uma técnica chamada atenção esparsa que reduz o custo computacional de processar contextos longos. A arquitetura foi projetada para reutilizar prefixos estáveis, primeiro com o V3.2, que introduziu o DeepSeek Sparse Attention, e depois com o V4, que adicionou compressão hierárquica de contexto, reduzindo o cache de memória para 10% do tamanho original. O desconto de preço é o reflexo direto dessa eficiência: a DeepSeek repassa parte da economia para quem aprende a usar o modelo do jeito que ele foi projetado para ser usado.
Um programador que só usa a API sem entender isso vai pagar muito mais do que precisa. Um programador que leu os papers vai estruturar suas requisições de forma completamente diferente, e vai pagar uma fração do preço pelo mesmo trabalho.
Esse é o retorno de investimento de entender o que você está usando.
O projeto que nasceu da investigação
A partir dessa mesma descoberta, um desenvolvedor criou o Reasonix, um framework de agentes de código específico para DeepSeek. Não genérico. Não compatível com outros modelos. Deliberadamente limitado a um único provedor.
Essa escolha parece estranha até você ver o que ele construiu. O Reasonix não se contentou em resolver o cache. Ele identificou três características do DeepSeek que frameworks genéricos ignoram sistematicamente.
Primeiro, o cache. O framework divide o contexto em três regiões: um prefixo imutável (que inclui as regras do projeto e os esquemas de ferramentas), um histórico que só cresce em modo append, e uma área de rascunho volátil que nunca é enviada ao modelo. Essa única disciplina estrutural eleva a taxa de acerto de cache para 85-95%.
Segundo, o raciocínio. O DeepSeek gera centenas de tokens de pensamento interno antes de responder, um mecanismo chamado "thinking". A documentação oficial recomenda descartar esse conteúdo, porque reenviá-lo prejudica a qualidade. Mas o Reasonix percebeu que esse raciocínio contém o plano de ação do modelo: sub-objetivos, hipóteses, incertezas, caminhos rejeitados. Em vez de jogar fora, o framework extrai esse plano usando uma chamada barata ao próprio modelo e o exibe estruturado no terminal. É literalmente o modelo pensando alto, e frameworks genéricos simplesmente descartam essa informação.
Terceiro, a correção de erros. O DeepSeek tem particularidades conhecidas: às vezes omite argumentos de funções complexas, esconde chamadas de ferramenta dentro do raciocínio, produz JSON truncado, ou entra em loop chamando a mesma ferramenta repetidamente. O Reasonix implementa quatro correções automáticas que rodam em todo turno, sem intervenção humana.
Com esses três pilares, os números são inequívocos:
- Cache hit rate de 85 a 95% em sessões reais
- Economia de 93 a 96% comparado ao Claude Sonnet
Para ser concreto: uma sessão onde o agente gerou mais de 1.400 linhas de código, um jogo completo estilo DOOM rodando no navegador, com motor de raycasting, física, inteligência artificial de inimigos com detecção de linha de visão, áudio sintético e interface completa, custou aproximadamente $0,06. Seis centavos de dólar.
No meu próprio uso ao longo de um mês, processei mais de 84 milhões de tokens. O custo total foi de 4,56. Isso inclui sessões reais de desenvolvimento: uma interface gráfica completa com testes e documentação por 0,33, dezenas de experimentos, até um artigo científico de 55 páginas analisado e resumido. Tudo somado, menos de cinco dólares.
Isso não é possível se você está usando um framework genérico que desperdiça o cache, descarta o raciocínio, e deixa os erros de ferramenta se acumularem.
O que acontece quando você leva a sério a ideia de "entender"
O criador do Reasonix publicou dois artigos detalhando as decisões de design da ferramenta. Não são posts de blog promocionais, são documentos de arquitetura que explicam o que foi construído, o que foi descartado e por quê.
Lendo esses artigos, você entende decisões que pareceriam arbitrárias de fora. Por que o sistema de hooks usa comandos shell em vez de plugins TypeScript? Porque hooks são preocupação de sysadmin, não de desenvolvedor, o usuário que quer rodar prettier após cada edição já tem o executável no PATH. Por que os hooks usam regex ancorada em vez de substring para selecionar ferramentas? Porque substring disparou em tool_called_edit_text quando o usuário queria apenas edit. Por que o formato de saída é exit code em vez de JSON? Porque test -f .git/MERGE_HEAD && exit 2 se escreve em 30 segundos.
Essa transparência é rara. E é exatamente o tipo de coisa que permite a outro programador aprender, adaptar, e eventualmente contribuir, ou construir algo melhor.
Eu quase construí minha própria versão dessa ferramenta. Cheguei a esboçar a arquitetura, planejar os módulos, separar o que cada componente precisava fazer. Desisti quando encontrei o Reasonix, não porque ele era perfeito, mas porque o criador já havia resolvido os problemas que eu estava começando a entender. O formato XML de chamadas de ferramenta do V4, por exemplo, ainda não é suportado nativamente. Se eu fosse implementar algo hoje, começaria por aí.
Por que investigar é uma habilidade técnica
Existe uma distinção importante entre usar uma ferramenta e entender uma ferramenta.
Usar é suficiente para a maioria das tarefas do dia a dia. Mas quando algo não funciona como esperado, quando o desconto não aparece na fatura, quando o agente fica em loop, quando o custo sobe sem explicação, só entender resolve.
E "entender" aqui não significa decorar documentação. Significa ter a disposição de ir até a fonte: ler o paper, abrir o código, medir o que realmente acontece, comparar com o que deveria acontecer.
Foi isso que me levou do desconforto com uma fatura até a leitura de dois papers acadêmicos, dois artigos de arquitetura de software, dezenas de logs de sessão, e finalmente a este texto. Não porque eu queria escrever um artigo, mas porque eu não conseguia aceitar que a ferramenta estava "funcionando" sem entender o que exatamente estava acontecendo embaixo dos panos.
Isso é ciência da computação aplicada. Não como disciplina acadêmica, mas como postura profissional: a recusa de aceitar "funciona" como resposta suficiente quando a pergunta real é "por quê?"
Os melhores programadores que eu conheço têm esse instinto. Quando algo os surpreende, eles não seguem em frente. Eles param. Investigam. Entendem. E depois constroem algo melhor com o que aprenderam.
Esse instinto é o que separa quem usa IA de quem faz IA funcionar de verdade.
O que você pode fazer hoje
Você não precisa publicar um framework open-source para aplicar esse princípio.
Na próxima vez que uma ferramenta de IA não se comportar como você espera, tente uma coisa: não reinicie o processo nem troque de ferramenta imediatamente. Pare e pergunte: por que isso aconteceu? Abra a documentação. Procure o repositório. Se existir, leia o paper.
Você vai se surpreender com o que encontra, e com o quanto isso muda a qualidade do trabalho que você é capaz de fazer.
Gustavo é cientista da computação e escreve sobre arquitetura de sistemas, IA aplicada e engenharia de software no seu blog pessoal.