Troquei o modelo caro pelo barato em duas rotinas. As duas reprovaram.

Por Fernando Sugiyama · 6 de outubro de 2026· 6 min de leitura

A conta parece óbvia. O modelo pequeno custa uma fração do grande. Se ele dá conta, troca e pronto.

Eu testei isso em sistemas meus, com a mesma entrada nos dois modelos e uma régua escrita antes. Em duas rotinas, o barato reprovou. Em uma delas, nem economizou.

Este texto conta o que medi e onde o modelo barato de fato encaixa.

O ponto de partida: ninguém tinha medido nada

Eu opero minhas empresas com um sistema de agentes de IA. Em quatro semanas, ele rodou 88 subagentes. Nenhum em Haiku, o modelo pequeno da Anthropic. E nenhuma rotina declarava qual modelo queria usar.

Ou seja: tudo rodava no padrão, sem decisão. Eu aprovei trocar, mas com uma condição: só se comprovadamente melhorar. “Parece bom” não conta.

Teste 1: o resumo da manhã

Toda manhã o sistema me entrega um resumo curto do que importa no dia. Rodei o mesmo resumo, com os mesmos dados, no modelo grande (Opus) e no pequeno (Haiku).

O custo: US$ 0,16 no pequeno contra US$ 0,84 no grande. Cinco vezes menos.

Agora o resto da conta. O pequeno:

• errou a atribuição de um número;
• errou uma data;
• estourou o limite de cinco linhas;
• deixou a seção “Hoje” vazia;
• ignorou uma regra de priorização.

Reprovado. Um resumo com regras cheias de nuance não é tarefa mecânica. E a perda de qualidade apareceu justamente nas regras que eu uso para decidir o que fazer no dia. Um resumo barato com a data errada é pior que nenhum.

Teste 2: a rotina noturna, onde o barato saiu mais caro

Toda noite o sistema coleta números e executa uma fila de tarefas sem ninguém esperando. Parecia o lugar perfeito para o modelo mais barato do meio, o Sonnet.

Reprovou duas vezes.

Primeiro, na qualidade. Ele omitiu do relatório uma proposta que continuava aberta. Só listou as novas. Quem lê o relatório acha que a pendência sumiu.

Segundo, no custo, e aqui está o que mais me surpreendeu. Medi somando o consumo real registrado nas conversas do sistema:

Cache, em linguagem simples, é o contexto que o modelo guarda para não reler tudo do zero. Mas cada passo ainda lê esse contexto de novo. Um modelo que dá mais passos, reabrindo o contexto a cada um, lê mais. O barato, sozinho, em 95 mensagens, leu mais cache do que o caro delegando para ajudantes.

Preço por token menor não significa conta menor. Quem define a conta é quantas vezes o contexto é relido.

O mesmo erro, de outro jeito

Antes desses testes, eu tinha cometido o erro na forma mais pura. Eu uso um classificador pequeno, que roda numa API à parte, para decidir coisas pontuais: para onde vai um pedido, se algo passou ou não. No começo, eu chamava esse classificador como ferramenta, no meio da conversa com o modelo grande.

Medi em 22 de setembro de 2026. Cada chamada obrigava o modelo grande a reler o contexto inteiro só para ler uma resposta de uma linha. A mediana era de 150 mil tokens relidos por chamada. Saía cerca de 20 vezes mais caro do que deixar o modelo grande decidir sozinho.

O classificador não era o problema. O lugar dele era.

Onde o modelo barato encaixa de verdade

Hoje o classificador pequeno entra fora da conversa. Roda antes do modelo grande: lê o pedido, escolhe a rota e entrega pronto. Roda em rotinas automáticas sem ninguém esperando. E, quando a tarefa é julgar uma lista grande, ele julga a lista inteira numa chamada só, em vez de item por item.

Um exemplo medido: mapear um site de 147 páginas. O classificador fez em 18 segundos, por US$ 0,024. Contra o modelo grande, na mesma tarefa, foi 77 vezes mais barato e 3,9 vezes mais rápido. Deu a mesma decisão em 73% das páginas.

Leia esse último número com cuidado. Em 27% das páginas, a decisão foi diferente. Funciona porque a decisão final é tomada em código, com pergunta objetiva. Quando fiz perguntas abertas (“qual ação tomar?”), o classificador respondeu “otimizar” para quase tudo: 141 das 147 páginas. Pergunta aberta não discrimina. Pergunta objetiva, sim. Também notei falso positivo em “conteúdo desatualizado”: um post de cinco meses era marcado como velho. Por isso um sinal do código confere antes de agir.

O padrão que sobrou:

• Lote: lista grande, uma chamada, nunca item por item.
• Rotina sem ninguém esperando: o tempo de resposta não importa, o custo sim.
• Classificação e roteamento: escolher entre poucas opções, com critério objetivo.

E o que fica no modelo grande: tarefa com regra de prioridade, nuance e data certa. Resumo de decisão, ata, qualquer coisa em que o erro pequeno vira decisão errada.

Não é só comigo

A LangChain publicou em 1º de outubro de 2026 um roteador de modelos no agente de código dela. Segundo o post, o roteador cortou 64% do custo mediano por tarefa. E o desenho tem o mesmo princípio que aprendi na prática: o roteador escolhe o modelo uma vez, no início da conversa, e não é chamado de novo no meio. A fonte está no fim do texto.

Como decidir sem se enganar

Três regras que uso agora.

Meça com a mesma entrada. Rode os dois modelos no mesmo caso e compare contra a especificação da tarefa, não contra a impressão de que “ficou bom”. Um dos meus testes ficou inconclusivo porque o modelo testado leu a decisão do dia e contaminou o resultado. Para repetir, uso uma pauta antiga, já decidida.

Meça o consumo total, não o preço do token. Some o que o modelo lê e escreve de verdade, em todos os passos. O log da ferramenta, no meu caso, não trazia custo. Tive que somar o uso registrado nas conversas.

Teste em produção tem data para acabar. Se o experimento depende de alguém lembrar de reverter, ele não acaba.

O que você pode fazer na sua empresa

Se você usa IA em alguma rotina, escolha uma tarefa só. Rode o modelo atual e um mais barato com a mesma entrada, escreva antes o que conta como certo e compare qualidade e consumo total. Comece pelas rotinas que rodam sem ninguém esperando e pelos lotes. Deixe o resumo que alimenta decisão por último.

Se quiser ajuda para medir isso no seu caso, veja como eu trabalho em /contratar/.

Fontes: LangChain, “How to build a model router in the harness”, 1º/10/2026: https://www.langchain.com/blog/how-to-build-a-model-router-in-the-harness

Fernando Sugiyama é empresário desde 2010 (Leox e Hutz) e desenvolve soluções com IA em produção para empresas: agentes de atendimento, automação com aprovação humana e software sob medida. Tudo o que escreve aqui roda primeiro nas próprias empresas.