Como dividir uma tarefa entre dois modelos de IA: o rápido tria e o forte decide

Tem gente pagando preço de modelo de fronteira pra fazer trabalho que um modelo pequeno resolveria dormindo

E o pior: pagando em tempo também, não só em dólar

O padrão que resolve isso é velho conhecido de quem monta pipeline: uma passada barata filtra o volume, separa o que é óbvio do que é duvidoso, e o modelo forte só abre o olho no que sobrou

É o mesmo raciocínio de triagem de pronto socorro, se liga: o enfermeiro não opera ninguém, ele decide quem passa pro cirurgião

Aqui a gente vai ver as duas partes que quase todo mundo esquece: COMO desenhar o corte (a pergunta que o modelo barato responde) e como auditar essa triagem pra descobrir se ela está jogando coisa boa no lixo

Bora?

O que você precisa antes de começar

Nada de exótico, mas sem essas quatro coisas o roteamento de modelos vira chute:

• Acesso à API Claude ou ao Claude Code, porque o corte pode viver nos dois lugares e o jeito de configurar muda
• Uma tarefa com volume E com decisão binária clara: se é 1 item por dia, esquece, não tem o que otimizar
• A tabela de preços na mão, pra você calcular o corte com número e não com sensação
• Um conjunto de exemplos já rotulados por você, tipo umas 50 amostras onde você já sabe a resposta certa

Esse último item é o mais chato de montar e o mais importante de todos

Ele é o gabarito da triagem

Sem gabarito você não tem como saber se o modelo barato está acertando ou só concordando com tudo

A tabela que define o seu corte:

Essa é a ordem atual, do mais barato ao mais caro e capaz, com o Fable 5 sendo o modelo de fronteira

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Detalhe bom pra quem estava com medo de planilha furada: o preço introdutório do Sonnet 5 virou preço padrão, e o reajuste pra US$ 3 / US$ 15 que estava marcado pra 1 de setembro de 2026 foi cancelado

US$ 2 / US$ 10 é permanente

E antes que você pense que o modelo pequeno é igualzinho ao grande só que mais rápido, a própria documentação da Anthropic mede o buraco: no GPQA Diamond o Haiku 4.5 acertou 63% contra 92% do Opus 5, por cerca de um décimo do custo por questão, e ficou bem mais atrás em tarefas longas de código

Ou seja: o modelo pequeno é ótimo triando, é fraco decidindo

Esse é exatamente o desenho que a gente quer 🙂

Como montar a triagem em dois modelos, passo a passo

1. Escreva o critério de escalonamento como pergunta binária, nunca como nota subjetiva

Não peça "dê uma nota de 0 a 10 pra complexidade desse ticket"

Pergunte algo que só tem duas respostas: "esse item depende de contexto que não está no texto? sim ou não"

O erro comum deste passo: critério vago

Quando você pede nota, o modelo barato inventa uma escala própria e ela muda de item pra item, aí o seu corte em "acima de 7 escala" não significa nada

2. Rode a primeira passada no modelo barato com saída estruturada

Peça JSON, sempre, com o veredito e o motivo separados:

{
  "escala": true,
  "motivo": "o pedido cita um contrato que não veio no texto"
}

O campo motivo não é enfeite

É ele que você vai ler depois pra descobrir se a triagem está errando sempre pelo mesmo padrão

O erro comum deste passo: aceitar texto livre como resposta e ter que fazer parse com regex depois, o que quebra no primeiro item fora do padrão

3. Escolha a arquitetura: executor que escala ou orquestrador que delega

A Anthropic documenta dois padrões de estratégia multi-modelo

No primeiro, um executor toca o trabalho e escala as decisões difíceis pra um advisor mais forte

No segundo, um orquestrador delega o trabalho de volume pra workers de custo menor

A ideia é a mesma nos dois: fazer com que a maior parte dos tokens seja cobrada na faixa barata

Se você já brigou com agentes rodando em paralelo no mesmo arquivo, o modelo de orquestrador com workers vai te soar familiar, é a mesma coordenação, só que agora com preços diferentes em cada ponta

O erro comum deste passo: escolher orquestrador quando a tarefa não tem volume, aí você paga a orquestração inteira pra dividir 3 itens

4. Implemente o escalonamento dentro da própria requisição com a Advisor tool

Existe uma ferramenta oficial em beta que faz isso sem você escrever código de orquestração: o executor emite uma chamada de ferramenta, a Anthropic roda a inferência do advisor, e o executor continua com a orientação na mão

Pra ligar, você manda o beta header advisor-tool-2026-03-01 e declara a ferramenta com type advisor_20260301, um name e um campo model:

{
  "model": "claude-sonnet-5",
  "tools": [
    {
      "type": "advisor_20260301",
      "name": "advisor",
      "model": "claude-opus-5"
    }
  ]
}

Repara na hierarquia: o executor vai no campo model do topo da requisição, o advisor vai no model de dentro da ferramenta

O erro comum deste passo: colocar um advisor mais fraco que o executor

Não rola, o advisor precisa ser pelo menos tão capaz quanto o executor

Tome cuidado também com ONDE você vai rodar isso: hoje a Advisor tool está em beta na Claude API e no Claude Platform on AWS, e NÃO está disponível no AWS Bedrock, no Vertex AI nem no Microsoft Foundry

5. Se o seu fluxo é no Claude Code, o caminho é o subagente com modelo fixo

Subagente do Claude Code é arquivo Markdown com frontmatter YAML, e ele vive em dois lugares: ~/.claude/agents/ (nível de usuário, vale em todos os seus projetos) ou .claude/agents/ (nível de projeto, versionável com o time)

Então o triador fica assim, salvo em .claude/agents/triador.md:

---
description: Primeira passada. Responde só se o item precisa de análise profunda
model: haiku
---

Você recebe um item por vez
Responda APENAS com JSON no formato {"escala": boolean, "motivo": string}
Escale quando o item depender de contexto que não está no texto recebido

E o decisor, em .claude/agents/decisor.md, muda uma linha só:

---
description: Decide os itens que a triagem escalou
model: opus
---

O campo model aceita os aliases sonnet, opus, haiku ou fable, um ID completo como claude-opus-5, ou o valor inherit

E se você omitir? O padrão é inherit, ou seja, o subagente usa o modelo da conversa principal

É aqui que a economia evapora sem ninguém perceber, porque você achou que estava rodando no barato e estava rodando no modelo do chat

Quando o modelo não bate com o que você configurou, a ordem de resolução é essa, de cima pra baixo:

• a variável de ambiente CLAUDE_CODE_SUBAGENT_MODEL
• o parâmetro model da invocação
• o campo model do frontmatter do subagente
• o modelo da conversa principal

Tem uma variável de ambiente esquecida no seu shell? Ela ganha do seu arquivo, beleza?

Pra chamada avulsa, a ferramenta Agent aceita os parâmetros subagent_type, model (sonnet, opus, haiku ou fable) e run_in_background, então dá pra escolher o modelo item a item sem criar arquivo nenhum

O erro comum deste passo: rodar /agents esperando o assistente interativo de criação

A partir da v2.1.198 ele não abre mais o assistente, só imprime um lembrete pra você pedir ao Claude ou editar .claude/agents/ direto

Se você aprendeu o fluxo em tutorial antigo, é aqui que você trava

6. Ajuste o segundo botão: o effort

Modelo não é o único controle

O parâmetro effort controla quantos tokens o Claude gasta na resposta, e a escala básica vai de low a xhigh, passando por medium e por high, que é o padrão da API

No Claude Opus 5 tem um degrau a mais: são cinco níveis, low, medium, high, xhigh e max

Triagem quase nunca precisa de esforço alto, ela precisa de consistência

Decisão é o contrário

O erro comum deste passo: subir o effort do triador achando que ele vai errar menos, e transformar a etapa barata numa etapa cara que ainda por cima demora

7. Corte o resto da conta com batch e cache

Se a triagem pode rodar assíncrona, a Batch API dá 50% de desconto em tokens de entrada e de saída

E se o seu prompt de triagem é o mesmo pra todos os itens (deveria ser!), o prompt caching entra: um cache hit custa 10% do preço padrão de input

O detalhe topzera é que os descontos de prompt caching e de Message Batches se acumulam

O erro comum deste passo: jogar batch em cima de um fluxo que precisa de resposta na hora, e aí o usuário fica esperando o lote fechar

Como saber se a triagem está jogando coisa boa fora

Agora o ponto cego do padrão, que é onde quase todo post sobre isso para de falar

Triagem que erra pra menos não faz barulho

Ela não gera erro, não gera exceção, não aparece no log: ela só devolve "resolvido" pra uma coisa que precisava do modelo forte, e segue a vida

Os sintomas:

• Taxa de escalonamento perto de zero

Se quase nada escala, não comemore, desconfie

• Os itens escalados são sempre do mesmo tipo

Sinal de que o triador achou UM padrão e está ignorando o resto do espaço do problema

• Queda de qualidade que só aparece no fim da esteira

O reclamo chega do usuário final, três etapas depois, e ninguém liga o problema à triagem

A causa:

O modelo barato erra pro lado de "resolvido" porque o critério, do jeito que você escreveu, premia velocidade e decisão

Se a instrução diz "escale só quando for realmente necessário", parabéns, você acabou de ensinar ele a não escalar

A solução: amostragem cega

Pega uma fatia aleatória do que o modelo barato aprovou direto, sem escalar

Manda essa fatia pro modelo forte assim mesmo

Compara os dois vereditos

Cada divergência é um falso negativo da sua triagem, e o padrão que se repete nessas divergências é o conserto do seu prompt de corte

Use o percentual de tráfego escalado como métrica viva, olhando toda semana

Pra ter referência de quanto é "pouco" e quanto é "muito": o RouteLLM, framework aberto de roteamento da LMSYS, atinge 95% da performance do GPT-4 usando apenas 26% de chamadas ao GPT-4 no roteador de matrix factorization

Ou seja: 3 de cada 4 requisições ficaram na faixa barata sem derrubar o resultado

Se a sua taxa está em 2%, tem coisa passando batido

Como prevenir:

Fixe o gabarito ANTES de ligar a cascata

E reexecute a amostragem cega a cada mudança de prompt ou de modelo, porque trocar uma frase da instrução do triador muda o comportamento dele inteiro

Já me ferrei com isso: você "melhora" o prompt, a taxa de escalonamento despenca, e por uma semana parece que você ficou genial em economia 😛

Quando vale dividir e quando não vale

Onde o padrão paga:

• Volume alto e repetitivo com decisão binária: moderação, classificação de chamado, triagem de lead
• Filtragem: separar o que merece leitura profunda do que é ruído
• Primeira leitura de material longo: o modelo barato resume e marca os trechos suspeitos, o forte só lê os trechos marcados

Onde NÃO paga:

• Tarefa única

Se você vai rodar uma vez, o custo de montar e auditar a cascata é maior que a economia, sem discussão

• Tarefa longa de código

A própria Anthropic registra que o Haiku 4.5 fica bem mais atrás nessas tarefas

Aqui o caminho é outro: em vez de baratear o modelo, quebrar a tarefa em entregas menores que o modelo fecha até o fim

• Qualquer fluxo em que o erro do triador é caro demais pra corrigir depois

Se o item descartado errado vira prejuízo, processo ou cliente perdido, não terceirize o corte pro modelo pequeno

E o ganho, existe mesmo?

Existe, e tem base acadêmica, não é papo de thread de LinkedIn

O FrugalGPT (Lingjiao Chen, Matei Zaharia e James Zou, Stanford, 2023, arXiv 2305.05176) mostrou que uma cascata de LLMs pode igualar a performance do melhor modelo individual (GPT-4) com até 98% de redução de custo, ou melhorar a acurácia em 4% pelo mesmo custo

O RouteLLM, lançado pela LMSYS em julho de 2024 com código e datasets públicos, reduziu custo acima de 85% no MT Bench, 45% no MMLU e 35% no GSM8K comparado a usar só GPT-4, mantendo 95% da performance do GPT-4

Os roteadores deles foram treinados com dados de preferência públicos do Chatbot Arena

Repara na variação entre os benchmarks: 85% num, 35% no outro

O tamanho do ganho depende MUITO de quanto do seu tráfego é fácil

O que eu vi rodando a mesma tarefa em dois modelos

Esse assunto de custo escondido não é teórico pra mim

Quando testei dois modelos na mesma tarefa, coloquei os dois no nível máximo de raciocínio, no mesmo projeto, com os mesmos prompts e configurações pareadas, cada um na sua janela, acompanhando as duas execuções ao mesmo tempo

O resultado do relógio: o mais rápido entregou a primeira etapa (uma landing page) em 11 minutos

O concorrente estava com 12 minutos rodando quando fui checar o andamento

E o mais lento passou de 20 minutos sem entregar de fato a etapa

A cota de uma das ferramentas caiu de 100% para 83% na MESMA tarefa

Depois uma das execuções torrou a cota inteira de uma vez só e sobraram 3 resets

No meio do teste eu tive que baixar o nível de raciocínio dos dois pra conseguir terminar a bateria sem esperar horas

E a conclusão prática foi essa: raciocínio máximo custa tempo e cota demais pra uma diferença de qualidade que eu não consigo enxergar em relação a um nível abaixo

No dia a dia eu programo no nível alto e só de vez em quando subo pro extra alto, quando julgo necessário

É exatamente esse o custo que a triagem corta

Quando você manda TUDO pro modelo forte no esforço máximo, você não paga só dólar por token: paga minuto de espera e paga cota, que é o recurso que acaba primeiro e no pior momento possível

São 4 rounds de teste no vídeo, e é logo no primeiro round, o da landing page, que a diferença de tempo aparece escancarada

Próximo passo: escolha uma tarefa e meça o percentual escalado

O objetivo do roteamento de modelos cabe em uma frase: fazer com que a maior parte dos tokens seja cobrada na faixa barata sem que a qualidade final caia

As duas metades importam

Quem só olha a primeira metade economiza lindo e entrega pior, e demora meses pra descobrir

Então o próximo passo é bem concreto:

1. Pegue UMA tarefa repetitiva do seu fluxo, a mais chata que você tiver
2. Escreva o critério de corte como pergunta binária
3. Rode a triagem no Claude Haiku 4.5 por uma semana
4. Registre duas coisas: o percentual escalado e o resultado da amostragem cega

Só DEPOIS desses números você decide se o decisor precisa ser Sonnet 5, Opus 5 ou Fable 5

Porque decidir isso antes de medir é só chute com nome bonito 😀

Até o próximo post!