GrokBot rendeu 78 PRs em uma semana, mas o custo e a falta de confiabilidade fizeram o autor abandonar a ferramenta

O autor, que escreve no blog da Builder.io, usou o GrokBot para orquestrar agentes rodando no T3 Code, app desktop que executa threads de Claude Code e Codex lado a lado. Montou 16 bots (Inbox, GitHub, Bugs, Blog, Research, Config, Vault e outros) e fechou a semana com 78 pull requests mergeados, contra um recorde anterior de 35. Um script simples no PC, sem IA, avisava um webhook do GrokBot quando uma thread de código terminava, falhava ou pedia atenção.

O problema veio do desenho. Segundo o texto, todo wakeup (usuário, rotina, webhook, outro bot, trabalho em background) passa por um roteador e vira um turno de modelo, e silêncio também custa inferência. Um filtro em código convencional, que cortaria cerca de 80% do tráfego, foi construído mas nunca ligado, e eventos de código acordavam um bot de 500 a 750 vezes por dia. Resultado: US$ 100 num fim de semana, mesmo no plano de US$ 200. Num dia de exemplo, 24 threads terminaram, 17 foram avisadas no prazo, 3 atrasadas e 4 nunca chegaram ao autor. Um pedido para segurar merges não chegou às threads, e um PR passou por um check falho 46 minutos depois.

A proposta do autor: follow-ups como registros com prazo, eventos no lugar de cron, modelos pequenos para decisões estreitas (ele cita o Jev, da TypeSafe, com respostas abaixo de 200 milissegundos), workers em silêncio por padrão e uma instância nova por job. Ele também defende estado em apps com MCP, caso do Agent-Native, framework open source da própria Builder, o que o texto admite como viés.

Para quem monta agentes sempre ativos, a leitura é que roteamento, fila, deadline e estado durável são código determinístico, não tarefa para o modelo. Antes de escalar o número de bots, vale medir quanto custa cada wakeup que não gera mensagem. E como o texto também promove o framework da casa, convém separar o diagnóstico arquitetural, que vale para qualquer stack, da recomendação de produto.