💰 Modelos e Custos: estrategia inteligente

Um dos erros mais caros em sistemas multiagentes e usar o mesmo modelo para todos os agentes. O orquestrador precisa de raciocinio sofisticado para decompor tarefas, avaliar resultados e tomar decisoes estrategicas — isso exige um modelo poderoso como Claude Opus ou GPT-5.3. Mas o agente que apenas formata documentacao ou faz buscas simples nao precisa dessa potencia. Usar Opus para formatar Markdown e como contratar um neurocirurgiao para colocar um band-aid.

A estrategia inteligente e mapear o nivel de complexidade cognitiva de cada papel no swarm e atribuir modelos proporcionais. Tarefas que exigem raciocinio multi-etapa, planejamento e avaliacao critica recebem modelos premium. Tarefas mecanicas, repetitivas ou de baixa ambiguidade podem usar modelos leves ou ate gratuitos. O resultado e um swarm que mantém qualidade maxima nas decisoes criticas enquanto reduz custos drasticamente nas tarefas operacionais.

Alem de escolher o modelo certo por nivel de complexidade, ha uma razao estrategica para usar modelos de providers diferentes no mesmo swarm: eliminar pontos cegos. Cada LLM foi treinado em datasets diferentes, com tecnicas diferentes, e portanto tem vieses e fraquezas diferentes. Quando o mesmo modelo que escreveu o codigo tambem o revisa, ele tende a "concordar consigo mesmo" — os mesmos padroes que geraram o bug tambem impedem o modelo de detecta-lo.

A tecnica anti-blindspot usa deliberadamente modelos de providers distintos para Coder e Reviewer. Se o Coder usa Claude (Anthropic), o Reviewer usa GPT (OpenAI), ou vice-versa. Como os modelos foram treinados em dados diferentes e tem vieses diferentes, o Reviewer e mais propenso a detectar erros que o Coder teria ignorado. Este principio — semelhante a "segunda opiniao medica" — e uma das decisoes de design documentadas no opencode-swarm e demonstrou reducao significativa de bugs que passavam despercebidos.

Uma das vantagens pouco exploradas do ecossistema atual e a disponibilidade de modelos gratuitos de qualidade surpreendente. O OpenCode oferece acesso a modelos como Big Pickle, minimax e outros atraves do seu modo Zen, que permite uso sem custo para o usuario. Esses modelos nao sao brinquedos — muitos deles competem com modelos pagos de geracoes anteriores em tarefas especificas.

A chave e saber quando um modelo gratuito e suficiente e quando investir em um modelo pago faz diferenca. Para tarefas de exploracao (ler codebase, buscar padroes, listar arquivos), formatacao (converter Markdown, organizar dados) e rascunhos preliminares (primeira versao que sera refinada), modelos gratuitos sao perfeitamente adequados. O resultado sera verificado e refinado por agentes mais poderosos na cadeia — portanto, a qualidade do rascunho inicial nao precisa ser perfeita.

Vamos colocar a teoria em pratica com um mapeamento concreto agente → modelo baseado nos sistemas reais oh-my-openagent e opencode-swarm. A ideia e simples: cada agente no swarm tem um nivel de responsabilidade diferente, e o custo do modelo deve ser proporcional ao impacto das decisoes que esse agente toma. O orquestrador decide o rumo de todo o projeto — merece o melhor modelo. O explorador apenas le e reporta — pode usar o mais barato.

No oh-my-openagent, o Sisyphus (orquestrador incansavel) e o Prometheus (planejador) exigem raciocinio de altissimo nivel — Claude Opus e a escolha natural. O Hephaestus (executor, deus da forja) precisa de excelente capacidade de codigo — Codex 5.3 ou Claude Sonnet atendem bem. Ja o Explorer e o Librarian (pesquisadores) podem usar modelos gratuitos sem problema, pois seus resultados serao processados e refinados pelos agentes superiores.

Swarms consomem tokens em velocidade muito superior a um agente unico — afinal, multiplos agentes estao fazendo chamadas de API simultaneamente. Cada provider de LLM impoe rate limits (limites de taxa) que restringem quantos tokens voce pode processar por minuto, quantas requisicoes pode fazer por hora e quanto pode gastar por dia. Quando um swarm atinge esses limites, agentes comecam a receber erros e o fluxo inteiro pode travar.

A solucao passa por tres estrategias complementares: planejamento de consumo (estimar quantos tokens cada agente usara e distribuir dentro dos limites), fallback automatico (se o provider principal atingir o limite, trocar para um provider alternativo automaticamente) e provider switching (distribuir chamadas entre multiplos providers para evitar atingir o limite de qualquer um deles). A combinacao dessas tres estrategias garante que o swarm nunca pare por falta de tokens.

O OpenCode se destaca no ecossistema de ferramentas para agentes por ser genuinamente provider-agnostico. Enquanto muitas ferramentas sao otimizadas para um unico provider (Claude Code para Anthropic, Copilot para OpenAI), o OpenCode permite configurar cada agente do swarm com um provider e modelo diferente — tudo no mesmo fluxo de trabalho, sem necessidade de adaptadores ou middlewares.

Na pratica, isso significa que voce pode ter o orquestrador usando Claude Opus (Anthropic), o coder usando Codex 5.3 (OpenAI), o explorer usando um modelo gratuito do ecossistema Zen, e o reviewer usando Gemini (Google) — tudo coordenado pelo mesmo sistema. Essa flexibilidade elimina o lock-in de ecossistema, permite otimizar custo por agente e habilita a estrategia anti-blindspot com modelos de providers diferentes sem nenhuma complexidade adicional.