Abri o Cursor para corrigir copy de botão. Ainda estava selecionado o Claude Opus 5 (Opus 5). Funciona. Também funciona pedir a um Staff Engineer para trocar esse texto: você pagou capacidade de um nível que a tarefa não pedia.
O problema não é falta de inteligência. É alocação de capacidade. E a hora de alocar certo não é quando a fatura chega.
Se você programa no Brasil, muita assinatura de agente cobra em dólar. A fatura vem em USD. No bolso, pesa em real. Não vou inventar câmbio nem colar valor da minha conta: o ponto é que trocar de modelo depois que o agente já queimou tokens de frontier é tarde. A decisão era antes de rodar o plano ou a tarefa.
Antes de executar, você precisa saber o que cada LLM sabe fazer, onde ele tropeça, e se o custo-benefício fecha para aquele trabalho. Capacidade, limitação e preço entram juntos. Model routing não é remorso no fim do mês. É escolha no primeiro prompt.
Quando a empresa banca o modelo (assinatura, crédito, invoice corporativa), essa escolha deixa de ser gosto e vira linha numa conta compartilhada. O painel de uso ou a fatura mostram quem gastou quanto em qual modelo. Isso não prova sozinho quem escolheu bem. Custo-benefício exige tipo de tarefa, retries e se a tarefa terminou certa. Esses campos só existem se o harness registra. Não afirmo que a maioria das empresas já ranqueia dev por escolha de LLM: não tenho pesquisa de mercado que prove isso. Com log completo e volume, dá para ver quem entrega tarefa bem-sucedida com menos desperdício. A telemetria habilita essa leitura. Usar ou não para gestão de time fica com cada empresa.
A conta fica bem mais cara quando o harness deixa o agente abrir subagentes e você não orquestrou o plano antes de executar. Um agente solo em Opus 5 já dói quando a tarefa era copy de botão. Subagentes multiplicam: cada filho pode herdar ou escolher modelo, abrir contexto, errar, retentar e chamar mais filhos. A conta deixa de ser um modelo e vira uma árvore. Se você não definiu antes quais passos, qual camada de modelo e onde parar, você paga o fan-out sem política.
Orquestrar antes da run é a mesma decisão que trocar de modelo antes da run. Descer tier ou rotear subagentes só ajuda se a regra existia antes do spawn da Task. Depois que a árvore disparou, você negocia com a fatura.
Agora pense numa empresa inteira: processos, ferramentas, documentos, banco, regras, histórico, sistemas, pessoas. Isso se aproxima do que chamamos de sistema de IA. O LLM é uma parte. É o profissional absurdamente rápido que você contrata para uma atividade. Tem gente barata e rápida. Tem especialista. Tem quem lê mais contexto antes de decidir. E tem quem custa dez vezes mais para resolver quase igual.
LLM ≠ sistema de IA. Escolher o campeão de ranking no dropdown e deixar fixo é confundir contratação com operação.
Na prática eu faço model routing: o LLM certo para a tarefa, dentro do harness (Cursor, Claude Code, Codex, Kiro), começando pelo mais barato que aguenta o trabalho e subindo só quando falta raciocínio ou quando errar custa caro. Abaixo: preços de lista na UI, mix 80/15/5, benchmarks públicos, escada de três camadas, política em YAML, custo por tarefa bem-sucedida e por que a fonte definitiva é a telemetria do seu fluxo.
Neste artigo
- A pergunta útil e as tarefas A, B e C
- Preços na UI do Cursor e mix 80/15/5
- Motor, harness e carro
- Escada FAST / BALANCED / FRONTIER
- Quando fazer switch (e quando não subir modelo)
- Model routing como política de engenharia
- Cursor: mapa rápido (preços na §2)
- Routing por harness: Claude Code, Codex, Kiro
- Cost per successful task
- Hora do engenheiro versus centavos de token
- Router automático e Harness Engineering
- Minha regra hoje
- Benchmark sem hype
- Pareto, tabela de fontes e matriz
- Bookmarks que eu deixo abertos
- YouTube e comunidade: shortlist, não veredito
- Telemetria: fonte definitiva (exemplo ilustrativo)
1. A pergunta útil e as tarefas A, B e C
Dev sênior não deveria escolher um único LLM. Deveria saber quando trocar.
Você não precisa do melhor LLM. Precisa do LLM certo para cada trabalho. A armadilha é abrir Cursor, Claude Code, Codex ou Kiro, pegar o modelo mais forte e deixar ali para tudo. Typo? Opus. Teste unitário? Opus. Dez repositórios e uma race condition? Opus também. Funciona. Só que você está pagando raciocínio de frontier onde um modelo barato bastava.
A pergunta errada é: qual é o melhor modelo?
A pergunta útil:
Qual é o modelo mais barato que executa esta tarefa com segurança e qualidade suficientes?
Três tarefas fixam a escala na cabeça.
Tarefa A: criar testes de um componente seguindo o padrão existente. Contexto pequeno, critério objetivo. Provavelmente não precisa do mais caro.
Tarefa B: feature com API, front, migrations e testes. Vários arquivos, decisões no meio. Vale subir um degrau.
Tarefa C: fluxo que duplica cobrança sob concorrência. Investigação, vários serviços, hipóteses, impacto financeiro. Pagar por mais capacidade pode ser barato perto do custo de errar.
Isso é model switching. O resto do texto é como eu operacionalizo isso por harness e por preço.
2. Preços na UI do Cursor e mix 80/15/5
A pergunta que me fez montar a política foi banal: qual modelo na lista do Cursor dá melhor custo-benefício para programação no dia a dia?
Preços de lista na UI do Cursor (data em que anotei; não é fatura nem telemetria de time). Daqui para frente eu remeto a tabela de preços em vez de repetir número.
| Modelo (UI Cursor) | Input / Output por 1M | Papel |
|---|---|---|
| Composer 2.5 | $0,50 / $2,50 | barato, agente Cursor |
| Gemini 3.8 Flash High | $0,75 / $3,50 | meu default (contexto até 1M) |
| Muse Spark 1.3 High | $1,25 / $4,25 | alternativa barata |
| Grok 4.7 normal High | $2 / $6 | balanced / tarefa difícil |
| Grok 4.7 High Fast | $4 / $12 | mesmo tier, 2× preço (velocidade) |
| GPT-5.6 Sol Medium | $4 / $20 | frontier / raciocínio |
| Claude Opus 5.5 Medium | $4 / $20 | frontier / agêntico |
| Claude Fable 5.1 High | $10 / $50 | extremo |
Mix que uso em repo real (refactor, bug, testes, agent loop). Daqui para frente: mix da §2.
| Share | Modelo | Quando |
|---|---|---|
| 80% | Gemini 3.8 Flash High | CRUD, testes, refactor local, PR, doc, feature pequena |
| 15% | Grok 4.7 High sem Fast | vários arquivos, debug chato, arquitetura, migração, agent long-running |
| 5% | Opus 5.5 / GPT-5.6 Sol | barato já deu 2–3 voltas e não resolve |
Benchmark público (não medição minha): Google cita Gemini 3.8 Flash com 73,7% DeepSWE, GPT-5.6 Sol 72,7%, Claude Opus 5 74,0%, com Flash bem mais barato na tabela.
Default único: Gemini Flash + Grok (sem Fast) como segundo degrau. Objetivo: crédito dura mais sem queda proporcional de qualidade.
3. Motor, harness e carro
O modelo é o motor de raciocínio. O sistema ao redor define contexto, ferramentas, arquivos que pode alterar, comandos, regras, tempo, orçamento e como validar o trabalho.
Cursor, Claude Code, Codex e Kiro não são só chat. São harnesses: camadas que transformam capacidade bruta em trabalho de engenharia.
LLM
↓
Harness
├── contexto do repositório
├── busca de arquivos
├── terminal
├── Git
├── MCP
├── skills
├── regras
├── memória/estado
├── ferramentas
├── testes
└── feedback da execução
O mesmo LLM em dois harnesses pode divergir muito. Programação com agentes não depende só de inteligência do modelo. Depende de algo mais próximo de:
resultado =
modelo
× contexto
× ferramentas
× orchestration
× feedback
× validação
Por isso comparar modelos só por benchmark genérico fica insuficiente. Mais adiante separo benchmark de motor versus carro inteiro (agent/harness).
4. Escada FAST / BALANCED / FRONTIER
Começo em cheap, só subo com motivo. Preços e mix: §2. Aqui é capacidade versus risco (escalation policy).
| Camada | Perfil | Exemplos de tarefa | Cursor (§2) |
|---|---|---|---|
| FAST / cheap | localizada, verificável, baixo risco | testes, mocks, lint, DTO, CRUD, migration simples | Composer, Gemini Flash |
| BALANCED | vários arquivos, ambiguidade, debug, planning | feature inteira, bug, refactor módulo, integração, migração API | Grok 4.7 sem Fast |
| FRONTIER | cognitivamente caro, alto risco | race condition, distribuído, segurança, incidente, code review crítico | Opus 5.5, GPT-5.6 Sol; Fable se extremo |
Agente que lê milhares de arquivos no mês multiplica qualquer linha da tabela de preços. Frontier não significa "cinco vezes melhor": o custo marginal precisa fazer sentido para o problema.
5. Quando fazer switch (e quando não subir modelo)
O segredo não é escolher. É saber quando fazer o switch.
Comece barato.
↓
O modelo resolveu?
SIM → valide e termine.
NÃO
↓
Ele está errando execução
ou errando raciocínio?
Execução → melhore contexto/tooling.
Raciocínio → aumente o modelo.
↓
Ainda falhou?
Suba novamente.
Muita equipe faz modelo falhou → modelo maior quando o problema era contexto: arquivo errado, regra de negócio fora do prompt, teste inacessível, harness que perdeu estado.
Nenhum modelo resolve contexto que nunca recebeu. Antes de subir de camada, eu olho rules, indexação, testes disponíveis e se o code review humano está no loop certo.
6. Model routing como política de engenharia
Em time maduro, routing vira política por tarefa, não gosto individual:
tasks:
simple_change:
model: cheap
unit_tests:
model: cheap
feature:
model: balanced
debugging:
model: balanced
architecture:
model: frontier
security_review:
model: frontier
financial_rule_review:
model: frontier
Você deixa de perguntar "qual modelo o João gosta?" e passa a perguntar "qual capacidade esta tarefa exige?"
7. Cursor: mapa rápido (preços na §2)
Cursor expõe multi-provedor, modelos próprios e Auto; modelo muda o orçamento. Não repito valores: tabela de preços e mix 80/15/5 na §2; camadas na §4.
| Situação no repo | Camada (§4) | Onde na §2 |
|---|---|---|
| pequenas alterações | cheap | Composer / Gemini Flash |
| feature normal | balanced | Grok standard (sem linha Fast) |
| problema complexo | frontier | GPT-5.6 Sol / Opus 5.5 |
| extremo | frontier+ | Fable ou reasoning maior |
Fast: compare as duas linhas Grok na tabela de preços. Velocidade também é decisão econômica.
8. Routing por harness: Claude Code, Codex, Kiro
Mesma escada da §4; muda o catálogo. Nomes envelhecem em seis meses; o padrão cheap → balanced → frontier permanece.
| Harness | Cheap → balanced → frontier | Notas |
|---|---|---|
| Claude Code | eficiente → Sonnet → Opus | ecossistema Claude; menos troca de fornecedor por prompt |
| Codex | eficiente → GPT-5.6 Sol (equilíbrio doc OpenAI) → frontier | investigação difícil sobe tier |
| Kiro | open-weight / barato → Sonnet → Opus | créditos: Pro ~1.000/mês (lista), extra US$ 0,04; Opus em tudo quebra franquia |
Não compre raciocínio que a tarefa não precisa. Em empresa, isso vira política compartilhada, não gosto individual.
9. Cost per successful task
Modelo barato ≠ execução barata.
Modelo A: $1, oito tentativas. Modelo B: $5, resolve de primeira. B pode ser mais barato no total.
Em vez de só $/1M tokens, meça:
Custo real =
tokens
+ número de tentativas
+ tempo do desenvolvedor
+ tempo de execução
+ retrabalho
+ risco
Esse é o eixo cost per successful task que LiveBench e benchmarks de agente expõem publicamente.
10. Hora do engenheiro versus centavos de token
Exemplo de mesa: engenheiro a R$ 150/h, 30 minutos empurrando modelo barato = R$ 75 de tempo humano. Economizar US$ 0,30 em tokens deixa de ser otimização.
Escalar pelas camadas da §4 (Flash → Grok → Opus no Cursor) pode reduzir custo total da tarefa, não aumentar.
11. Router automático e Harness Engineering
Hoje:
developer → escolhe modelo → harness
Próximo estágio:
developer → tarefa → router → cheap | balanced | frontier → agent
O router pode olhar complexidade, risco, contexto, latência, custo, tipo de alteração, histórico de sucesso.
O Cursor Auto já roteia buscando equilíbrio entre custo, inteligência e confiabilidade. O dev administra políticas de execução, não só dropdown.
Se o seu foco é contexto persistente para agentes, eu escrevi sobre isso em Harness Engineer: knowledge base RAG centralizado. Neste texto o foco é routing.
12. Minha regra hoje
Use o menor modelo capaz de resolver o problema.
Suba de modelo quando faltar raciocínio.
Melhore o harness quando faltar contexto.
Use o modelo mais caro apenas quando o custo de errar for maior que o custo de pensar.
LLM deixa de ser "assinatura de IA" e vira infraestrutura de engenharia.
13. Benchmark sem hype
Não escolha modelo por hype: use benchmark, custo e contexto.
Cruzo três sinais: benchmark de coding; custo por token ou por tarefa; desempenho dentro de um harness real. Um modelo pode brilhar em resposta curta e falhar com agente rodando minutos no repo.
SWE-bench
Issues reais de GitHub; patch que resolve. Leaderboard mede % de instâncias resolvidas. Pergunta: capacidade de engenharia perto do mundo real.
LMArena Coding
Comparação humana entre respostas. Responde: "qual resposta de programação as pessoas preferiram?" Não responde sozinha: "qual agente alterou o repo corretamente por 20 minutos?"
Artificial Analysis
Eixo qualidade × latência × throughput × preço. Coding Index com frontiers próximos: pagar muito mais nem sempre dá ganho proporcional.
Harness e HarnessTax
LMArena também avalia agentes com custo por tarefa e discute HarnessTax: quanto do resultado é modelo versus ambiente.
Benchmark de modelo mede o motor. Benchmark de agente mede o carro inteiro.
Model Benchmark → "Esse modelo sabe programar?"
Agent/Harness Benchmark → "Esse modelo consegue trabalhar?"
LiveBench separa Coding de Agentic Coding e mostra cost per successful task (benchmark público, não telemetria minha).
14. Pareto, tabela de fontes e matriz
| Fonte | O que eu olho | Para que serve |
|---|---|---|
| SWE-bench | Issues reais resolvidas | capacidade de engenharia |
| LMArena Coding | preferência humana em coding | qualidade percebida |
| Artificial Analysis | inteligência, velocidade e preço | custo-benefício |
| Harness/Agent Benchmarks | tarefa completa + custo | agentic coding |
| Pricing oficial provider/harness | $/token ou créditos | decisão econômica |
Nunca escolheria modelo só por estar em primeiro lugar. Busco Pareto: qualidade suficiente pelo menor custo e latência na classe de tarefa.
COMPLEXIDADE DA TAREFA
↑
Frontier │ Opus / GPT frontier
Balanced │ Grok / Sonnet
Efficient │ §4 cheap (Flash / Composer)
└────────────────────────────→
CUSTO / LATÊNCIA
Não procure o ponto mais alto. Procure a fronteira de Pareto.
Exemplo ilustrativo (números redondos para raciocínio, não dados de produção):
- Modelo A: qualidade 95, custo $10
- Modelo B: qualidade 93, custo $1
Em tarefa de baixo risco, B pode ser melhor economicamente. Em pagamento, segurança, concorrência, arquitetura crítica, dois pontos percentuais podem justificar frontier.
15. Bookmarks que eu deixo abertos
- SWE-bench: issues reais de software
- LMArena Coding: preferência humana em programação
- LMArena Agent Leaderboard: agentes, harnesses, custo por tarefa
- Artificial Analysis: qualidade, preço, velocidade
- LiveBench: coding vs agentic coding, cost per successful task
Benchmark não escolhe modelo por você. Ele reduz achismo.
A métrica de engenharia continua sendo: quanto custa entregar uma tarefa correta em produção?
Benchmarks: SWE-bench · LiveBench · Artificial Analysis · LMArena · OpenSOTA
Uso real / comunidade: Limite Semanal · IndyDevDan · Sam Witteveen · GosuCoder · Armin Ronacher · Fireship
Fonte definitiva: sua própria telemetria de execução.
16. YouTube e comunidade: shortlist, não veredito
Benchmark não conta a história inteira. Para limite de assinatura, contexto longo, agente rodando horas, diferenças entre Cursor, Claude Code e Codex, eu também olho quem usa isso todo dia.
Em português: Limite Semanal (consumo, limites, escolha de ferramentas). Canal é comunidade, não veredito.
Em inglês:
- IndyDevDan: Claude Code, multi-agent, orchestration, context engineering
- Sam Witteveen: LLM engineering, agentes, experimentos técnicos
- GosuCoder: comparações entre coding agents e modelos
- Armin Ronacher: agentic coding e desenvolvimento orientado a agentes
- Fireship: novidades de ferramentas e SDKs (menos profundo em routing)
Benchmark me ajuda a montar a shortlist.
Uso real me ajuda a escolher o modelo.
Telemetria do meu harness me diz se eu estava certo.
17. Telemetria: fonte definitiva (exemplo ilustrativo)
Depois de benchmarks e comunidade, a melhor fonte deveria ser a própria empresa (ou o seu fluxo solo instrumentado).
Campos que eu registraria por execução:
modelo
tipo da tarefa
tokens consumidos
tempo até conclusão
número de retries
testes executados
resultado dos testes
intervenções humanas
custo
Depois de centenas de execuções com log de tarefa, retries e sucesso, você responde: "qual modelo funciona no nosso software engineering system?" Só o extrato de tokens por modelo não fecha essa conta.
Exemplo ilustrativo (didático, não medição minha em produção):
Testes unitários / Gemini Flash → 91% sucesso → $0.08/tarefa
Feature pequena / Grok → 88% sucesso → $0.42/tarefa
Debug distribuído / Opus → 84% sucesso → $2.31/tarefa
Use como formato de relatório, não como promessa. Só telemetria real do seu harness fecha o loop.
Isso não é mais um "ranking dos melhores LLMs de 2026". É política: evidência pública para shortlist, harness para contexto, routing para custo total, code review humano onde o risco manda.
Pergunta para você: no Cursor (ou outro harness), qual tarefa ainda está no modelo mais caro só porque ninguém escreveu a regra de descer de camada? Descreve o tipo de tarefa e o split que você usaria hoje.
Por isso estou construindo o downshift. Ele surgiu para auxiliar o desenvolvedor nessa escolha de modelo de forma antecipada, principalmente quando trabalhamos com subagentes e várias tarefas (multitarefa, fan-out). O foco não é o chat único do dia a dia: no desenho do projeto, a sessão principal continua com o modelo que você escolheu; o router atua no spawn do subagente, classificando a tarefa e encaixando tier antes do filho começar (hooks no Claude Code, Cursor e Codex). É o complemento prático deste texto: política na delegação, não remorso na fatura.
A segunda decisão, depois do tier, é calibrar o effort da tarefa — o par deste texto é O effort da tarefa: quando pensar demais vira stage 3 na fatura do agente.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.