Pitch: Do "Dev Raiz" ao uso de IA via CLI: Como criei um Token Monitor local para gerenciar custos de LLMs
Há cerca de dois anos venho em uma jornada de transição e aprendizado em desenvolvimento de software. O movimento começou pela necessidade de ir além das análises de dados tradicionais e começar a construir produtos de dados reais para o dia a dia corporativo.
No início, cometi o erro clássico de tentar ser um "Dev Raiz puritano": zero uso de Inteligência Artificial. Eu me cobrava a digitação de cada linha de código do zero. A chave virou quando percebi que desenvolvedores experientes não sofrem por preciosismo; eles focam no valor da entrega e na resolução eficiente de problemas (mantendo, claro, a qualidade do código e boas práticas).
Foi aí que passei a integrar IA no meu fluxo de trabalho. Minha evolução foi:
- Validação de trechos de código via interfaces web tradicionais.
- Migração para extensões na IDE que questionavam e refinavam minhas decisões arquiteturais.
- Fluxo atual: Codificação assistida diretamente pelo terminal, utilizando IA via CLI.
O Problema: "Não existe almoço grátis" (O custo invisível dos Tokens)
Embora a IA não durma e aumente a produtividade exponencialmente, as chamadas de API cobram seu preço através do consumo de tokens. Conforme eu avançava em múltiplos projetos locais, perguntas críticas de governança e custo começaram a surgir:
- Quanto, de fato, está custando o desenvolvimento de cada microsserviço ou projeto em paralelo?
- Qual LLM está consumindo mais recursos no meu fluxo?
- Como mapear o consumo histórico para prever gastos antes de escalar uma solução para produção?
A Solução: Token Monitor
Para resolver esse problema e consolidar meus aprendizados, desenvolvi o Token Monitor. Trata-se de uma aplicação que roda de forma local e centraliza a telemetria desse consumo.
Funcionalidades principais implementadas:
- Varredura Local: O sistema aponta para os diretórios locais onde os projetos estão centralizados e faz o parsing/leitura dos logs ou metadados de consumo de tokens.
- Visão Temporal: Série temporal demonstrando os picos de consumo de tokens por dia/semana.
- Granularidade por Modelo: Distribuição exata de tokens consumidos por modelo (ex: Gemini, GPT-4o, Claude, etc.).
- Filtros Avançados: Cruzamento de dados cruzando filtros por
Projeto x Modelo. - Precificação Dinâmica: Uma camada de configuração onde posso embutir o custo por milhão de tokens (Input/Output) de cada player para refletir o custo financeiro real em uma dashboard.
Stack Técnico e Ambiente de Desenvolvimento:
- Ambiente: Ambiente Linux emulado via WSL (Windows Subsystem for Linux).
- Pair Programming: Utilização massiva do Gemini integrado ao fluxo de trabalho e suporte da extensão SuperPowers.
A ferramenta foi construída 100% utilizando assistência de IA e se provou tão útil para organizar meus custos de laboratório que decidi disponibilizá-la em um repositório público no GitHub. Sei que existem diversas soluções corporativas de APM e observabilidade no mercado, mas a proposta aqui é um monitor leve, local e focado na esteira de desenvolvimento do dev individual.
Próximos Passos e Aprendizados
Esse projeto não apenas resolveu um problema prático de controle de custos, mas abriu meus olhos para como acoplar LLMs em regras de negócio complexas. Para as próximas iterações do projeto e da minha trilha de estudos, os objetivos são claros:
- Migrar parte da lógica para Agentes Autônomos.
- Implementar uma esteira de CI/CD automatizada para o deploy do monitor.
- Refatorar o core da aplicação aplicando princípios de SOLID de forma mais rigorosa.
- Continuar a evolução de lógica complexa através de desafios no LeetCode.
O código está aberto para quem quiser analisar a estrutura, criticar a arquitetura ou contribuir com melhorias.
[https://github.com/abnerfc01/token-monitor](https://github.com/abnerfc01/token-monitor)
O que acham dessa abordagem de monitoramento local de custos de IA durante o desenvolvimento? Alguém aqui utiliza alguma estratégia parecida para não estourar o orçamento das APIs?