Lowfat e um filtro CLI plugavel escrito em Rust. Ele senta entre o comando e o modelo de linguagem: recebe o stdout bruto, descarta ruido repetitivo (cabecalhos redundantes, linhas em branco, colunas que voce nao pediu, timestamps, IDs sem contexto) e entrega ao LLM um output ja enxuto. Em workloads reais, o autor reportou 91,8% menos tokens ingeridos pelo modelo para as mesmas respostas uteis. Em junho de 2026, o Lowfat apareceu no Show HN com esse numero absurdo - e um binario Rust que voce enfia no pipe entre kubectl get pods -A e llm "explique esse output".
O que e e por que importa agora
O padrao de uso de LLM em 2026 nao e mais "abrir o ChatGPT e digitar uma pergunta". E "rodar um comando no terminal, copiar o output, colar no prompt e pedir para o modelo resumir, classificar ou agir". Esse fluxo parece simples, mas tem um problema escondido: a maioria dos outputs de CLI e verbosa demais para o que o LLM precisa.
Exemplos do dia a dia: kubectl get pods -A retorna 40 linhas para uma duvida sobre 1 pod, aws s3 ls lista 5.000 objetos quando voce quer so a contagem, psql -c "SELECT * FROM orders" devolve 200 colunas sendo que a pergunta era "quantos pedidos por status", e git log --all cospe 3.000 commits quando o usuario quer entender o que mudou na ultima tag.
Cada token desses vai para a janela de contexto, conta no bill da OpenAI, Anthropic, Google ou open-source self-hosted, e ainda rouba espaco que poderia ir para a pergunta real. E o pior: o modelo fica pior, nao melhor, quando recebe muito lixo. Ele se confunde, inventa, pede para repetir.
O Lowfat ataca exatamente esse gargalo. Em vez de limpar o output manualmente (ou escrever wrapper de sed/awk para cada comando), o filtro aplica heuristicas genericas: remove duplicatas consecutivas, colapsa secoes repetidas, trunca diffs, mascara IDs longos. O LLM recebe resumo estruturado, nao dump.
Como funciona (sem jargao)
O Lowfat e um binario que voce instala e usa como filtro entre dois comandos. O fluxo mais simples:
kubectl get pods -A | lowfat | llm "tem algum pod em CrashLoopBackOff?"
O pipe faz o seguinte:
- Recebe o stdout bruto do comando da esquerda
- Aplica o pipeline de transformacao: dedup, colapso, truncamento, mascara
- Entrega ao comando da direita um texto ja compactado
Por baixo, o Lowfat tem tres camadas:
Plugar de comandos: detecta o tipo de saida. Output de kubectl, aws, git, docker, psql e uns 30 outros ja tem handlers especificos. Para saidas que ele nao reconhece, aplica filtro generico (dedup + colapso + limite de linhas).
Configuracao por arquivo TOML: presets por comando. Exemplo: para kubectl, "jogue fora tudo que nao for STATUS diferente de Running, mantenha o NAME inteiro, limite a 50 linhas". Vive em ~/.config/lowfat/config.toml.
Plugins: interface publica para escrever handler customizado em Rust. Para a maioria dos casos, o filtro generico resolve.
O autor do projeto compartilha benchmarks no README: para workloads tipicos de DevOps (kubectl, docker, terraform output), a economia ficou entre 78% e 95% dos tokens. Os 91,8% do titulo vieram de um workload especifico, nao e media. Mas mesmo no pior caso (output de cat em arquivo de log), a economia ficou acima de 60%.
Comparativo rapido: antes vs agora
Para fixar, um exemplo: voce precisa saber se ha pods em erro em um cluster de 12 namespaces.
Antes (sem Lowfat):
kubectl get pods -A -o wide
# 247 linhas, 8.300 tokens estimados
# copia, cola no LLM, pergunta
# custo por chamada: ~$0.025 (gpt-4o-mini) ou ~$0.12 (gpt-4.1)
# resposta do modelo: confusa, menciona 3 pods que nao estao em erro
Depois (com Lowfat):
kubectl get pods -A | lowfat | llm "liste pods com status diferente de Running"
# 14 linhas, 720 tokens estimados
# custo por chamada: ~$0.002 (gpt-4o-mini) ou ~$0.011 (gpt-4.1)
# resposta do modelo: direta, sem invencao
Em volume: 50 chamadas por dia, 250 dias uteis por ano, o gargalo de R$ 1,20/mes com gpt-4o-mini cai para R$ 0,10/mes. Em gpt-4.1, a economia anual sai de R$ 1.500 para R$ 137. E o ganho de qualidade vem de graca.
O que isso muda para o seu negocio
Para PMEs brasileiras que ja estao usando LLM em fluxo de trabalho (atendimento no WhatsApp, analise de vendas, suporte tecnico), tres consequencias praticas:
Custo por consulta cai. Se voce paga API por token, qualquer ferramenta que reduza 70-90% da entrada e 70-90% do custo. Para quem usa self-hosted (Ollama, vLLM), a economia vem em tempo de GPU, e portanto em conta de cloud.
LLM responde melhor. Modelos performam pior com input sujo. Quanto mais lixo, mais chance de alucinacao. Lowfat nao "melhora" o modelo - tira do caminho o que atrapalha. Resultado pratico: respostas mais curtas, mais certeiras, menos invencoes.
Ferramenta nova, dependencia minima. Lowfat e binario Rust estatico, sem runtime, sem Python, sem rede. Roda em Linux, Mac, Windows. Cabe em 6 MB. Para time pequeno que nao quer mexer em stack, e instalar e sair usando.
Onde nao faz sentido: se voce ja usa RAG ou pipeline estruturado onde o output ja e preprocessado antes de chegar no LLM, o Lowfat vira camada redundante. Tambem nao ajuda se a chamada para o LLM e texto puro do usuario (chat, email, ticket) - nao ha "output verboso" para filtrar.
Referencia natural Agendai
A Agendai usa esse mesmo principio nos agentes de IA que implementa para varejo: o output de qualquer integracao com ERP, CRM ou planilha passa por um filtro antes de virar contexto do modelo. Em um caso de uma loja de cosmeticos com 8 mil clientes, o filtro cortou 84% do volume de tokens gastos em mensagens automaticas de follow-up - e a qualidade das mensagens melhorou, porque o modelo parou de se perder em serializacao de JSON inteira do pedido. A Agendai entrega isso pronto em ~2 semanas, com a primeira semana de graca para validar antes de comprometer budget.
Para entender a mecanica por tras, vale ler o paper de Princeton/Georgia Tech sobre GEO e testar o Lowfat no GitHub em workload proprio.
Perguntas frequentes
O que e um LLM, em uma frase?
LLM (Large Language Model) e um modelo de inteligencia artificial treinado em grandes volumes de texto que gera respostas, resumos, classificacoes e codigo a partir de um prompt em linguagem natural. Exemplos em 2026: GPT-4.1, Claude Sonnet 4.5, Gemini 2.5, Llama 4.
Lowfat funciona com qualquer LLM?
Sim. Lowfat e um filtro de stdout, nao um cliente de API. Ele so enxuga o texto que vai entrar no prompt. O LLM que recebe o texto enxuto pode ser OpenAI, Anthropic, Google, Ollama local, ou qualquer outro - a escolha acontece no comando seguinte do pipe.
Quanto custa implementar Lowfat no meu fluxo?
Custo zero de software - o repositorio e open source sob licenca MIT. O investimento e mapear quais comandos do seu dia geram output verboso (normalmente kubectl, aws, git, docker, psql) e adicionar o | lowfat no meio. Para um time de 5 pessoas, meio dia de trabalho.
Quais os riscos de usar um filtro de output antes do LLM?
O risco principal e o filtro jogar fora informacao que o LLM precisava. Por isso o Lowfat e configuravel - voce pode liberar ou bloquear regras por comando. Em caso de duvida, a primeira semana e rodar com logs: comparar o output bruto com o output filtrado, e ajustar o TOML ate o equilibrio certo. Outro risco menor: dependencia de manutencao. O projeto e ativo (282 estrelas em junho de 2026), mas se o autor parar, a comunidade Rust costuma manter forks.
LLM substitui funcionarios quando o custo cai tanto?
Nao. O Lowfat reduz o custo por consulta, nao muda o que o LLM faz. Um agente de IA continua executando tarefa repetitiva (follow-up, FAQ, alerta) - o funcionario continua responsavel por decisao, relacionamento e caso atipico. O que muda com a reducao de custo e a viabilidade: tarefas que eram caras demais para automatizar agora ficam faceis. Para aprofundar, vale ler o post sobre agentes de IA vs chatbot.
Recomendamos tambem: Como aparecer nas respostas do ChatGPT (GEO) e RAG para atendimento: o que e e quando vale a pena.
Quer ver um agente de IA rodando no seu negocio sem inflar a conta de API? A Agendai implementa em ~2 semanas - primeira semana de graca. Fale com a gente.