Dos três bots que eu mantenho, só um usa LLM

"Bot moderno" virou sinônimo de bot que entende frase solta, e não ter isso parece atraso técnico. A parte justa do argumento é real: escrever o que você quer, do jeito que sair, é mais confortável que decorar o comando exato. Só que dos três bots pessoais que eu mantenho no Telegram, um usa LLM em cada mensagem, outro não usa nenhum, e o terceiro nem chega a receber mensagem. O que separa os três não é o ano em que foram escritos.

O Simon passa quase toda mensagem por um Haiku, e isso se paga

O Simon é meu assistente de propósito amplo. Todo texto que não é comando explícito e não contém URL vai para o claude-haiku-4-5-20251001 (intent_parser.py:152) com max_tokens=256 (intent_parser.py:153), e o que volta não é uma resposta em prosa: é a intenção estruturada que decide qual ação disparar.

O prompt do sistema carrega contexto vivo — as tarefas e os projetos do momento entram ali antes de cada chamada (intent_parser.py:116-134). Isso muda a natureza do bot. Ele não classifica texto no vácuo; ele interpreta o pedido sabendo o que está aberto na minha mesa naquele instante.

Aqui o LLM se justifica pelo formato do uso. São vários pedidos por dia, de assuntos que mudam, sem vocabulário estável. Nenhuma lista de palavras-chave sobreviveria a uma semana disso sem crescer para um tamanho que ninguém consegue lembrar.

O HealthJournal não usa modelo nenhum, e essa é a decisão certa

O HealthJournal registra refeição por foto e leitura de pressão arterial. A leitura de comando é feita por funções puras em parsers.py, com nomes que dizem o que fazem: parse_command, parse_amount, parse_bp_args, infer_meal_type. Nenhuma chamada de API, nenhum token gasto, nenhum modelo no meio.

A ausência de LLM ali não é limitação. É a decisão certa.

Um registro de saúde tem vocabulário pequeno e fixo: algumas palavras-chave, um número, uma foto. Colocar interpretação de linguagem natural em cima disso resolveria um problema que não existe e traria junto uma fonte de erro nova, que falha de formas que um if não falha. O bot já entende tudo que eu tento dizer para ele.

O Equity_Tracker nem pergunta faz, então a dúvida nem aparece

O terceiro caso resolve a questão de um jeito mais direto: não existe bot interativo. O Equity_Tracker manda alerta via requests.post puro contra a API do Telegram, sem python-telegram-bot, sem handlers, sem nada esperando resposta do outro lado.

A pergunta "qual LLM usar aqui" nunca se coloca quando o canal só empurra informação. Boa parte dos bots que as pessoas planejam cai nesse caso e ninguém percebe a tempo: não precisa receber mensagem nenhuma, e descobrir isso cedo apaga o desenho inteiro de comandos da lista de trabalho.

O critério é volume de mensagens vezes o quanto a ergonomia importa

Os três projetos divergem em quase tudo: granularidade de autorização, modelo de interação, presença de supervisor, reinício periódico, agendamento, corte de mensagem longa, persistência. Cada dimensão tem um valor diferente em cada bot, e nenhuma dessas diferenças veio de acidente ou de época de escrita.

O critério que explica as três decisões é o mesmo. Quantas mensagens variadas o bot recebe, multiplicado pelo quanto a liberdade de escrever importa naquele contexto. O Simon pontua alto nos dois fatores. O HealthJournal pontua baixo no segundo, porque o vocabulário é fechado. O Equity_Tracker zera o primeiro, porque não recebe nada.

O que não entra na conta é o que a maioria usa como argumento: qual abordagem parece mais avançada de fora.

Colocar o LLM no bot cobra por mensagem e obriga a desconfiar da saída

Recomendo o LLM quando o domínio é amplo e o texto que chega é imprevisível — e junto com a recomendação vem a conta. Cada mensagem custa uma chamada de API, e a saída do modelo não é confiável por padrão. Essa foi a lição 2 do Simon, de 9 de março de 2026: o formato da resposta não é garantido, mesmo pedindo JSON.

Na prática isso vira código defensivo permanente. A resposta passa por remoção de blocos de markdown antes de qualquer leitura (intent_parser.py:159-161), e a falha tem caminho explícito: erro de JSON, erro da API ou índice fora do lugar caem todos em uma ação unknown (intent_parser.py:170-172). Tem ainda um atalho que pula o modelo inteiro quando a mensagem contém URL (bot.py:338-341), porque nesse caso o LLM só teria como contribuir uma chance de errar.

Um parser de palavra-chave não tem nada disso. Falha de forma óbvia, no mesmo lugar, sempre.

O teste que eu uso antes de escolher

A pergunta útil não é "esse bot devia ter IA". É se você consegue listar, de cabeça, todos os jeitos razoáveis de pedir a mesma coisa para ele. Se a lista sai e para de crescer, palavra-chave resolve. Se ela cresce toda semana com pedidos que você não tinha previsto, o LLM começa a compensar o custo por mensagem.

Eu mudo de ideia sobre o HealthJournal no dia em que o número de comandos distintos passar do que essas quatro funções conseguem ler sem virar um emaranhado de condicionais. Esse dia não chegou, e a lista de comandos está do mesmo tamanho desde maio.