Roteamento de modelos: qual tarefa vai para qual tamanho de IA

O que exige capacidade de topo é outra coisa: decidir o modelo de dados, escolher o contrato da API, revisar o diff inteiro procurando o que ninguém pediu, e auditar controle de acesso pensando como quem quer burlar.

Quando você joga o projeto inteiro no modelo mais caro, você paga preço de decisão para comprar digitação. E quando você joga o projeto inteiro no modelo mais barato, você compra digitação boa e decisão ruim, que é o defeito que só aparece três semanas depois.

A régua de roteamento existe para separar essas duas coisas dentro da mesma missão. Não é escolher um modelo para o projeto. É escolher um modelo por tarefa.

Sobre dinheiro, uma frase e seguimos: a distância de preço entre a camada de topo e a camada econômica é de ordem de grandeza, não de porcentagem. A economia é consequência da régua, nunca o assunto dela. O assunto é acertar o tamanho.

Camada forte. O topo disponível para trabalho agêntico complexo. Hoje, o padrão dessa camada é o Claude Opus 5, com o Claude Fable 5 reservado para quando você precisa da maior capacidade que existe. É a camada que decide.

Camada intermediária. Modelos capazes, muitas vezes de peso aberto, que executam bem tarefa complexa com escopo já fechado. GLM 5.2, Kimi K3 e Grok 4.5 vivem aqui. É a camada que constrói.

Camada econômica. Modelos rápidos e baratos para trabalho mecânico e volumoso. DeepSeek v4-pro é um exemplo. É a camada que digita.

Você não precisa de três camadas em todo projeto. Precisa de pelo menos duas, e da disciplina de não deixar a forte fazer o trabalho das outras.

Repare no eixo escondido da tabela. Não é dificuldade. É quem toma a decisão. Quando a decisão já foi tomada por outra pessoa ou por outro ticket, a tarefa desce de camada. Quando a tarefa exige decidir, ela sobe.

1. Essa tarefa decide algo que os próximos passos vão ter que obedecer?
Nome de tabela, formato de resposta, política de permissão, escolha de biblioteca. Decisão que vira restrição para os outros é camada forte, mesmo quando o código sai em dez linhas.

2. O erro aqui é caro de desfazer?
Renomear variável é reversível. Migration que já rodou em produção com dado dentro, não. Custo de desfazer é o melhor previsor de camada que existe.

3. Existe um teste automático que quebra se o modelo errar?
Se existe, você pode descer de camada com tranquilidade, porque o erro aparece sozinho. Se não existe, o erro vai ficar mudo, e erro mudo pede a camada forte. É por isso que segurança nunca desce: o teste feliz passa com o buraco aberto.

4. Alguém vai atacar isso de propósito?
Autenticação, autorização, escopo de acesso, cobrança, dado pessoal. Onde existe adversário, existe camada forte, e a revisão é feita por quem não escreveu.

Duas regras de bolso fecham o critério.

Se a tarefa exige decidir alguma coisa que não está escrita no briefing, ela não é simples. Ou você sobe a tarefa de camada, ou você desce a ambiguidade escrevendo mais briefing. As duas saídas valem, escolher nenhuma é o que dá errado.

E a regra das duas rodadas: se um ticket volta reprovado duas vezes na mesma camada, promova ele para a camada de cima em vez de insistir. Insistência em modelo pequeno com tarefa grande é o jeito mais caro de economizar, porque você paga a tentativa, a revisão e o retrabalho.

Você é o arquiteto e orquestrador deste time de agentes neste workspace.
Leia o briefing no fim, monte o modelo de dados, quebre a implementação em
tickets e distribua cada ticket para o agente certo, seguindo a régua de
roteamento abaixo.

Você NÃO escreve o código das tarefas. Você planeja, roteia e, no fim, revisa.

RÉGUA DE ROTEAMENTO
  Planejamento e modelagem de dados ............ <modelo forte>
  Decisão de arquitetura e de contrato ......... <modelo forte>
  Implementação de regra de negócio fechada .... <modelo intermediário>
  Query, escopo de acesso, integração .......... <modelo intermediário>
  Scaffolding, boilerplate e CRUD .............. <modelo econômico>
  Testes a partir de spec verificável .......... <modelo econômico>
  Refactor mecânico e documentação ............. <modelo econômico>
  Code review do diff final .................... <modelo forte>
  Auditoria de segurança e controle de acesso .. <modelo forte>

REGRAS DE ROTEAMENTO
- Antes de despachar cada ticket, declare: objetivo, arquivos que ele pode
  tocar, critério de aceitação verificável, modelo escolhido e uma linha
  justificando a escolha pela régua.
- Se um ticket exigir decidir algo que não está no briefing, não despache:
  suba o ticket de camada ou me pergunte.
- Se um ticket voltar reprovado duas vezes na mesma camada, promova ele para
  a camada de cima e registre a promoção.
- Nenhum ticket é dado como concluído sem o critério de aceitação atendido,
  com a saída real do comando colada na resposta.
- A auditoria de segurança não pode ser pulada, adiada nem marcada como
  opcional. Se o modelo dela falhar, use o fallback declarado no briefing.

Duas linhas fazem o trabalho pesado aí dentro.

A primeira é "você NÃO escreve o código das tarefas". Sem ela, o modelo forte resolve tudo sozinho porque é mais rápido para ele resolver do que explicar, e a régua deixa de existir na prática enquanto continua bonita no papel.

A segunda é a exigência de declarar o modelo escolhido com justificativa. Isso transforma o roteamento em algo que você consegue auditar depois, ticket por ticket, em vez de acreditar.

Escreva cada caso de uso como regra verificável, de preferência na forma negativa, e nomeie os caminhos de fuga um por um.

Implemente esta estrutura inteira neste projeto, do começo ao fim:
modelagem, migrations, regras de negócio, testes e segurança.

ENTIDADES
  Users    [nome, plano]
  Cursos   [titulo]
  Trilhas  [nome, restrita]
  Modulos  [titulo]

CASOS DE USO
  1. Um usuário do plano básico não pode ser vinculado a uma trilha restrita.
  2. Um usuário não pode visualizar, nem por busca, nem por filtro, nem por
     paginação, uma trilha à qual não está vinculado.
  3. Um curso de gestão financeira deve ser encontrado tanto em gestão quanto
     em finanças (um curso pertence a várias trilhas).
  4. Um curso de copy para anúncio deve estar na trilha marketing e no módulo
     anúncios.
  5. Um curso cujas trilhas o usuário não acessa não pode aparecer para ele em
     endpoint nenhum, nem na busca, nem em "cursos relacionados".

O caso 5 é o modelo de como se escreve isso. "Não pode aparecer" sozinho é desejo. "Não pode aparecer em endpoint nenhum, nem na busca, nem em relacionados" é regra, porque fecha as três portas por onde o vazamento costuma sair.

Agora as regras técnicas e os gates. Este bloco é reaproveitável quase inteiro entre projetos.

REGRAS TÉCNICAS (valem para todos os tickets)
- Testes automatizados com cobertura mínima de 90%, medida por ferramenta.
- Linter sem nenhuma ofensa.
- Banco de dados em container, subindo com um comando só.
- Chave primária UUID em todas as tabelas.
- Índices e foreign keys no banco. Integridade no banco de dados, não só
  validação no model.
- Identificação do usuário atual por header, o suficiente para testar o
  escopo de acesso.
- Documentação interativa da API gerada a partir dos testes de request, não
  escrita à mão.
- O servidor declarado na documentação aponta para o ambiente local. Nenhum
  placeholder de domínio de exemplo.
- CORS configurado e testado a partir da própria documentação interativa.
- Autenticação: descreva aqui, com todas as letras, o que deve existir e o
  que fica de fora. O que não estiver escrito não vai ser entregue.

A linha da foreign key merece atenção. Ela está escrita de forma redundante de propósito. Modelo de qualquer camada tende a resolver integridade só na aplicação e deixar o banco sem restrição, porque é mais rápido e passa nos testes. Sempre que existir um atalho que a IA costuma tomar, escreva a regra fechando o atalho, com a palavra "não" no meio. Vale para foreign key, para paginação, para soft delete e para qualquer regra que o teste feliz não pega.

Ele fica na camada forte, e é a única peça cara que roda o tempo todo. Isso não contradiz a régua, é a régua: você paga topo para decidir, e paga barato para executar.

Três regras que fazem esse papel funcionar.

Ele não escreve código de ticket. Se ele escrever, você tem um modelo caro fazendo o projeto inteiro com passos extras. A proibição precisa estar no prompt, porque a tendência natural dele é resolver.

Ele recebe o bug, não o executor. Quando algo quebra, você cola o erro e o log no orquestrador, não no modelo que escreveu a linha. Ele diagnostica com a missão inteira na cabeça e re-roteia a correção para a camada certa. Esse loop é o que separa um time de agentes de um monte de janelas abertas.

Ele revisa no fim, com o diff completo. Revisão de código feita pelo mesmo modelo que escreveu o código é conferência do pedido, não revisão. Quem revisa procura o que não foi pedido: a query sem índice, a rota sem escopo, o campo que voltou no JSON e não deveria.

Funciona por meia hora. Depois o custo de coordenação come a economia inteira, e o pior é que ele não aparece em lugar nenhum, porque quem paga é você, em tempo e em atenção. Fora que a cada colagem você reconstrói o contexto na mão e perde pedaço, então o modelo barato erra por falta de informação e leva a culpa por ser barato.

O que muda quando a orquestração vira sistema é a unidade de trabalho. Ela deixa de ser "uma conversa" e passa a ser o ticket: objetivo, arquivos que pode tocar, critério de aceitação e modelo atribuído. Ticket é o formato que torna o roteamento possível, porque só se pode mandar para a camada de baixo aquilo que já está fechado. Se você não consegue escrever o critério de aceitação do ticket, ele ainda não desceu de camada.

E o segundo ganho é o workspace compartilhado: mesmo sistema de arquivos, mesmos artefatos, mesmo histórico para todos os agentes. Trocar de modelo no meio da missão deixa de custar uma reconstrução de contexto e passa a custar uma linha de configuração. Sem isso, a régua é teoria.

No Claude Code isso já é nativo, e o padrão da casa é este: o orquestrador não escreve código, cada tarefa vai para um subagente com contexto próprio e descartável, e todo spawn leva o modelo explícito. Subagente aberto sem declarar modelo herda o modelo da sessão, que costuma ser o mais forte. É assim que a régua morre em silêncio: ninguém desobedeceu, só ninguém declarou.

Se a sua régua mistura modelos de fornecedores diferentes, vale plugar tudo em um gateway único (OpenRouter é o mais comum) por dois motivos práticos: trocar de modelo vira trocar um identificador em texto, e todo o consumo cai num extrato só, que é onde você vai conferir gasto de verdade no Bloco 11.

A régua tem um modo de falha característico, e ele aparece sempre nos mesmos três lugares.

Primeiro: o que não foi pedido não é entregue. Um sistema inteiro pode sair funcionando, com regra de negócio correta, teste passando, e sem nenhuma autenticação, porque o briefing dizia "só o suficiente para testar o escopo, sem auth completa". O modelo forte tende a entregar mais que o pedido e a avisar o que faltou. A camada de baixo entrega o pedido, exatamente, e cala. Quanto mais você desce a régua, mais o briefing precisa dizer o óbvio.

Segundo: a borda do sistema quebra em silêncio. CORS mal configurado, URL de servidor apontando para um domínio de exemplo, variável de ambiente faltando, header não propagado. Nada disso aparece em teste unitário, e por isso nada disso aparece no relatório de gates. Só aparece quando alguém chama o sistema de fora. Teste de borda é obrigatório e é humano.

Terceiro: a auditoria de segurança é a primeira coisa a ser sacrificada. Quando a etapa de auditoria trava, existe sempre um botão de "seguir sem auditoria dedicada", e ele é muito tentador porque o resto está verde. Um sistema que entregou sem autenticação e sem auditoria não é o mesmo sistema mais barato. É um sistema menor.

Daí a regra que não se negocia:

Roteie para baixo à vontade em scaffolding, teste, refactor, documentação e CRUD. Não roteie para baixo a decisão de quem pode ver o quê. E nunca compare dois caminhos como equivalentes sem antes conferir que os dois entregaram o mesmo escopo. Comparação entre entregas de escopo diferente é o jeito mais fácil de a versão barata parecer melhor do que é.

Modelos de topo têm filtro de conteúdo mais rígido. Pedir auditoria de "controle de acesso a conteúdo restrito por idade" pode disparar recusa, mesmo quando não existe conteúdo nenhum no sistema, só uma flag booleana numa tabela. E aí você fixou a etapa mais importante da missão em um único modelo, e ele diz não.

Isso não é anedota, é ponto único de falha, e ele está exatamente na etapa de segurança.

Duas defesas, e as duas são baratas.

Reescreva o pedido em termos de autorização, não de conteúdo. Em vez de descrever o material restrito, descreva o comportamento: quais identidades podem ler quais registros, e prove que as demais recebem recusa ou lista vazia. É a mesma auditoria, sem o gatilho.

E declare o fallback antes de começar, dentro da própria régua:

FALLBACK DA AUDITORIA
Se <modelo forte A> recusar ou falhar na auditoria de segurança, refaça o
pedido em termos de autorização (quais identidades podem ler quais registros).
Se ainda assim falhar, execute a auditoria com <modelo forte B>.
A etapa nunca é pulada. Seguir sem auditoria não é uma opção disponível.

É comum receber uma tabela caprichada de "gates técnicos" dizendo cobertura acima da meta, linter com zero ofensas e suíte toda verde, e o sistema chegar sem autenticação e com a borda quebrada. A tabela não é mentira deliberada, é autorrelato, e autorrelato de agente é otimista por construção. Vale para código, vale para consumo: se você quiser saber quanto gastou, o número sai do extrato do provedor, nunca do relatório que o modelo escreveu sobre si mesmo.

A regra é simples de aplicar: prova é a saída do comando, não a afirmação sobre o comando.

Coloque isto no prompt, como critério de aceitação:

CRITÉRIO DE ACEITAÇÃO
Nenhuma entrega é dada como pronta sem estas provas, e prova é a saída real
do comando, colada na resposta:

1. Saída completa da suíte de testes, com total de exemplos e de falhas.
2. Saída do relatório de cobertura, com o percentual final.
3. Saída do linter, com a contagem de ofensas.
4. Saída do scanner de segurança da stack.
5. Para cada regra de acesso do briefing, um teste negativo que executa a
   ação com a identidade errada e prova a recusa ou a lista vazia.
6. Um comando único que sobe o ambiente do zero, mais uma chamada externa
   que retorna 200 e outra que retorna 401.

Não escreva "suíte verde" nem "gates atendidos" sem colar a saída do comando
que produziu o resultado. Relatório sem saída de comando é reprovado.

E peça o relatório que interessa, que é o de roteamento:

Ao terminar, gere ROTEAMENTO.md na raiz, com uma linha por ticket:
identificador, título, camada da régua aplicada, modelo usado, número de
rodadas até passar no critério de aceitação, e se houve promoção de camada.
Não estime custo nem consumo: esse número sai do extrato do provedor.

Depois disso, o trabalho humano. É curto e não dá para pular.

O item mais barato dessa tabela é o mais valioso: rodar o comando você mesmo. Ele custa dois minutos e é a diferença entre roteamento e torcida.

1. 1A missão está quebrada em tickets com objetivo, arquivos e critério de aceitação.
2. 2Cada ticket tem camada declarada e uma linha justificando a escolha.
3. 3O orquestrador está proibido, por escrito, de escrever código de ticket.
4. 4O briefing escreve o óbvio, principalmente autenticação e o que não deve existir.
5. 5Toda regra de acesso está escrita na forma negativa, com os caminhos de fuga nomeados.
6. 6Segurança, autorização, dado pessoal e dinheiro estão na camada forte, sem exceção.
7. 7A auditoria tem fallback declarado e não pode ser pulada.
8. 8O critério de aceitação exige saída de comando, não afirmação.
9. 9Você rodou a suíte, o linter e os testes negativos com as suas próprias mãos.
10. 10Você comparou o escopo entregue contra o briefing antes de chamar de equivalente.

Feito isso, a régua trabalha para você. O modelo forte decide, revisa e audita. O resto do projeto sai na camada que dá conta. E a economia aparece sozinha, como consequência de ter acertado o tamanho, que é o único assunto desta aula.