Este é o meu guia prático de roteamento de modelos: qual IA eu escolho para cada tipo de tarefa no desenvolvimento do Posseidom e nas minhas automações. A regra que uso é inteligência proporcional ao problema — modelo caro em tarefa simples é desperdício, e modelo leve em tarefa complexa é prejuízo.
Codex 5.5 (Luna ou Luna Leve) — o canivete suíço
- Uso: C#, Python, interfaces WebForms em ASPX, e praticamente qualquer tipo de tarefa.
- Por quê: É meu modelo de uso geral no dia a dia. Se entende bem o codebase legado e não trava em nenhum tipo de trabalho. Entre a versão completa (Luna) e a leve, escolho pelo peso da tarefa.
- Veredito: verdadeiro canivete suíço — serve de tudo.
Google Gemini 3.8 Flash — desenvolvimento de apps
- Uso: complexidade média, especialmente desenvolvimento de aplicativos em Flutter ou Angular.
- Por quê: excelente custo-benefício para frontend e apps mobile — framework moderno, código repetitivo e padrões conhecidos.
Grok 4.5 — complexidade alta e raciocínio novo
- Uso: tarefas de complexidade alta, principalmente as que exigem um jeito diferenciado de consulta e raciocínio — quando nada que existe já resolveu aquele problema.
- Por quê: é o modelo que aciono quando o problema não tem solução pronta e preciso de raciocínio de verdade, não de padrão repetido.
Composer — rápido e barato
- Uso: tarefas de complexidade média para baixo.
- Por quê: rápido e muito barato. Para o volume grande de tarefas rotineiras, é o melhor custo-benefício da categoria.
Claude Haiku 4.5 — o leve universal
- Uso: quase tudo que é de complexidade média para baixo.
- Por quê: muito barato e resolve a maioria das tarefas do dia a dia sem precisar de um modelo pesado.
Copilot — autocomplete no VS Code / Visual Studio
- Uso: exclusivamente para auto-completar código, no VS Code ou Visual Studio. Time do Luiz Webley.
- Por quê: para autocomplete inline, ele cumpre bem o papel; não uso para tarefas agênticas.
GLM 5.3 Flash — o motor do Hermes
- Uso: modelo padrão do meu Hermes Agent (agente que orquestra outros agentes, com memória e skills).
- Por quê: melhor custo-benefício para uso contínuo em agente: rápido, eficiente e barato. Em agente que roda o dia todo, custo por token importa mais do que pico de inteligência.
Outros modelos que uso
- Kimi K2.6
- GLM 5.3
- MiniMax M3
Tabela Provedor × Densidade
Quanto maior a densidade de raciocínio, maior tende a ser o consumo de tokens internos, especialmente em tarefas agentivas longas. Os multiplicadores abaixo são faixas ilustrativas de planejamento, não valores oficiais fixos dos provedores.
| Provedor | Densidade | Consumo de reasoning tokens | Impacto na cota | Uso recomendado |
|---|---|---|---|---|
| Cursor | Low | 🟢 Baixo | 1× referência | Alterações simples, código repetitivo e tarefas previsíveis. |
| Cursor | Medium | 🟡 Médio | ~2–4× | Desenvolvimento normal e trabalho agêntico diário. |
| Cursor | High | 🟠 Alto | ~4–10× | Debug difícil, refatorações complexas e análise profunda. |
| Cursor | Extra High / Max | 🔴 Muito alto | ~8–20×+ | Problemas excepcionais. |
| ChatGPT / OpenAI | Low | 🟢 Baixo | 1× referência | Código simples, ferramentas e tarefas mecânicas. |
| ChatGPT / OpenAI | Medium | 🟡 Médio | ~2–4× | Padrão recomendado para desenvolvimento diário. |
| ChatGPT / OpenAI | High | 🟠 Alto | ~4–10× | Arquitetura, debugging complexo e análise profunda. |
| ChatGPT / OpenAI | XHigh / Max | 🔴 Muito alto | ~8–20×+ | Problemas extremamente difíceis e casos excepcionais. |
| Claude | Low | 🟢 Baixo | 1× referência | Trabalho mecânico e rápido. |
| Claude | Medium | 🟡 Médio | ~2–4× | Programação diária e análise normal. |
| Claude | High | 🟠 Alto | ~4–10× | Código complexo, agentes e problemas difíceis. |
| Claude | XHigh / Maximum | 🔴 Muito alto | ~8–20×+ | Arquitetura crítica e problemas excepcionais. |
Regra operacional recomendada
| Densidade | Uso sugerido | Orientação |
|---|---|---|
| 🟢 Low | ~20% | Tarefas mecânicas, previsíveis e repetitivas. |
| 🟡 Medium | ~70% | Configuração padrão para o desenvolvimento diário. |
| 🟠 High | ~9% | Quando Medium não for suficiente ou o problema realmente exigir raciocínio profundo. |
| 🔴 XHigh / Max | ~1% | Reservar para exceções, decisões críticas e problemas muito difíceis. |
Como interpretar o consumo
Input + contexto + reasoning + resposta + ciclos de ferramentas/agente = consumo total. Em um fluxo agentivo, uma única tarefa pode envolver várias rodadas de raciocínio, leitura de arquivos, chamadas de ferramentas, execução, análise do resultado e correção. Por isso, uma tarefa em High ou XHigh pode consumir muito mais que uma tarefa aparentemente semelhante em Medium.
Nota: não existe regra oficial fixa do tipo “High sempre consome 7× Medium” — as faixas desta página servem para planejamento e controle operacional.
Como a densidade de pensamento afeta o custo — exemplo ilustrativo
Exemplo com o mesmo resultado visível (2.000 tokens de saída), variando apenas o raciocínio interno:
| Densidade | Pensamento interno | Saída visível | Total consumido |
|---|---|---|---|
| 🟢 Low | 1.000 | 2.000 | 3.000 |
| 🟡 Medium | 5.000 | 2.000 | 7.000 |
| 🟠 High | 20.000 | 2.000 | 22.000 |
Leitura: o usuário vê sempre os mesmos 2.000 tokens — mas em High o consumo total é ~7× maior que em Low (22.000 vs 3.000). O custo invisível da densidade está no raciocínio interno, não na resposta.
Este é o meu stack atual de modelos — atualizo conforme os modelos evoluem. O critério é sempre o mesmo: qualidade suficiente para a tarefa, pelo menor custo e latência razoáveis.