No início desta semana tentei fazer um projeto divertido usando Claude Code e a quantidade de tokens queimados me fez perceber duas coisas – não posso continuar gastando tanto em IA e Claude é ridiculamente caro. Os melhores modelos modernos, esteja você executando o Opus 4.8 ou o Fable 5, são fantásticos e podem fazer as coisas, mas não foram feitos para durar. Esses são tokens, e se você quer apenas mexer, construir e quebrar coisas, esses não são os modelos que você deveria usar. Percebi isso bem tarde, mas quando o fiz, substituí Claude por um grupo de pequenos LLMs locais especializados. Isso me deu a liberdade de construir o que eu quisesse, sem me preocupar constantemente em ficar sem tokens.
Claude estava fazendo muitas coisas ao mesmo tempo
E isso afetou o desempenho geral
Quando comecei a observar para onde estavam indo todos esses chips, percebi que a maioria dos trabalhos não exige um modelo tão capaz quanto Claude. Claude Code usou o mesmo modelo de limite para entender o que eu queria construir, inspecionar os arquivos, pesquisar a base de código, gerar erros básicos, corrigir erros básicos, executar testes, ler a saída e decidir o que fazer a seguir. Alguns desses trabalhos exigem raciocínio adequado, mas muitos são dolorosamente simples.
Você não precisa do Fable 5 para encontrar o arquivo responsável pelo botão quebrado. Também não é necessário ler o log de erros, atualizar uma dependência, gerar um teste básico ou verificar se um teste foi aprovado. Um modelo muito menor pode lidar com a maioria dessas tarefas, especialmente se receber instruções claras e acessar apenas as ferramentas necessárias. Porém, se você normalmente usa o Claude Code, cada pequeno trabalho é entregue ao mesmo modelo caro.
O problema piora à medida que a sessão aumenta. Cada arquivo que Claude lê, cada comando que ele executa e cada erro que encontra adicionam mais informações à conversa. O modelo deve então continuar a funcionar num contexto cada vez mais confuso, mesmo que muita dessa informação já não seja relevante. Se o projeto der alguns passos errados, você também estará pagando a Claude para ler os erros do passado na tentativa de corrigi-los.
A arquitetura é muito mais simples do que parece
E muito mais fácil de configurar também
Construí toda a configuração em torno de n8n e Ollama porque queria ver cada etapa em vez de esconder tudo atrás de outra estrutura de agente. Eu uso n8n para lidar com o fluxo de trabalho e Ollama para descobrir os padrões usando a API nativa.
O primeiro modelo desenvolvido foi o Qwen 3.5 2B, que ocupava cerca de 2,7 GB e funcionava apenas como roteador. Dei a ele uma grande janela de contexto, configurei a temperatura para zero e forcei-o a retornar um JSON contendo o tipo de tarefa, entradas necessárias, ferramentas, especialista e critérios de sucesso. Não resolveu a tarefa em si. Se eu pedisse ao sistema para consertar o aplicativo, por exemplo, o roteador retornava o código como uma rota, listava os arquivos relevantes e definia a aprovação nos testes existentes como uma condição de sucesso.
Eu construí o Qwen 2.5 Coder 7B para lidar com tarefas de codificação. É um modelo Q4 de 4,7 GB especialmente treinado para geração, raciocínio e depuração de código. Dei a ele uma janela de contexto ainda maior, uma temperatura de 0,1 e acesso apenas ao diretório do projeto, ferramentas de edição de arquivos e um terminal sandbox. Ele poderia inspecionar e modificar o código, mas não poderia navegar na web, acessar pastas não relacionadas ou decidir que precisava de outro agente.
Todo o resto foi feito por meio da equipe individual do Qwen 3.5 9B. Esses funcionários usavam o mesmo modelo de 6,6 GB, mas tinham prompts e ferramentas diferentes. O pesquisador recebeu ferramentas de pesquisa e busca de páginas da web, o trabalhador de dados poderia gerar Python ou SQL que n8n executaria individualmente e o trabalhador de automação poderia chamar uma pequena lista de ações n8n aprovadas. Mantive a temperatura em 0,2 e o contexto igual ao Qwen 2,5. Isso evitou que o agente de exploração tocasse nos arquivos e evitou que o agente de automação inventasse comandos shell se um nó n8n validado não existisse.
O último teste foi feito pelo Qwen 3.5 4B. Recebeu critérios iniciais de sucesso, resultados de funcionários e resultados reais da ferramenta. O código teve que passar por testes, a pesquisa teve que ter fontes adequadas e o trabalho dos dados foi verificado com saída gerada por Python ou SQL. Uma falha na verificação do roteador retornou um erro exato e o fluxo de trabalho foi limitado a duas tentativas.
Os modelos menores foram piores, mas o sistema teve melhor desempenho
Parei de usar o Border Intelligence para trabalhos que não exigiam isso
Nenhum dos modelos locais em minha configuração poderia se igualar a Claude. No entanto, essas falhas estavam contidas em uma parte do fluxo de trabalho, o que as tornava muito mais fáceis de serem corrigidas. Se o modelo de codificação produzisse uma alteração quebrada, n8n executava os testes e passava a saída de erro para o verificador. O verificador retornou a verificação com falha, o arquivo afetado e o motivo da rejeição como JSON, após o qual apenas o codificador executou a nova tentativa. O roteador não precisou recriar o plano e os demais modelos não precisaram ler o projeto uma segunda vez. Também limitei cada tarefa a duas tentativas, para que um modelo confuso não conseguisse prender todo o sistema em um loop caro.
A mesma abordagem funcionou fora da codificação. O especialista em pesquisa tinha que retornar a fonte junto com cada afirmação, enquanto o especialista em dados gerava Python ou SQL e deixava o cálculo real para essas ferramentas. O trabalhador de automação só poderia usar ações n8n aprovadas por mim. Estes modelos tinham menos liberdade do que Claude Cod, mas também tinham menos oportunidades de causar estragos. Mais importante ainda, pude abrir o log de execução do n8n e ver exatamente qual modelo recebeu a tarefa, o que ela retornou, qual ferramenta funcionou e onde o fluxo de trabalho falhou.
Eu ainda preciso de Claude às vezes
Claude ainda fica significativamente melhor quando faço um pedido vago e espero que ele mesmo planeje todo o projeto. Eu não uso mais assim. Para recursos pequenos e projetos aleatórios que podem não levar a lugar nenhum, a equipe local se tornou minha equipe padrão.
