Quinto episódio de Economizando com IA. Os episódios 1 a 3 (Headroom: o editor entre você e o modelo, Uma ferramenta para gastar menos com IA aumentou a minha conta, A Morte dos Tokens) testaram uma ferramenta que enviava menos tokens e deixou a conta mais pesada; o episódio 4, O Time Barato, passou a gerir modelos e mediu a economia. Este é sobre como escolher.
O episódio 4 terminou com uma planilha ainda aberta na minha tela, e ela continuou aberta por um motivo que só entendi alguns dias depois. A medição tinha nos dito, centavo por centavo, quanto gastamos a mais deixando o modelo mais caro fazer tudo; o que ela não sabia dizer era como escolher certo da próxima vez que um pedido chegasse, e da vez seguinte, sem precisar abrir a planilha de novo. Uma fatura é um veredito sobre o passado, enquanto o que um gestor de TI precisa na segunda-feira de manhã é uma regra para o futuro.
Por isso este episódio é diferente dos quatro anteriores, e prefiro dizer logo no começo a deixá-lo emprestar a autoridade deles: é um guia, não uma medição. Os fatos sobre os modelos vêm da própria documentação da Anthropic, os poucos números sobre o nosso trabalho são os que o episódio 4 já publicou, e o resto é o critério que fomos construindo enquanto pagávamos pelos nossos erros. Use-o como ponto de partida para conferir contra o seu próprio trabalho, como a própria documentação recomenda.
Preço vezes quantidade
Toda conta é preço vezes quantidade, e a conta de IA não foge à regra, embora costumemos imaginar a escolha de um modelo como uma decisão só, do barato e fraco ao caro e forte, levada até onde o orçamento deixa; são dois fatores, e a maior parte da eficiência mora no jeito como eles se multiplicam.
O primeiro fator é o modelo, que define o preço, a tarifa cobrada por cada unidade de trabalho, e junto com ela o quanto o trabalhador é capaz. O Claude vem em quatro tamanhos que importam para software: o Haiku, o menor e mais rápido; o Sonnet, o burro de carga do dia a dia; o Opus, o sênior; e o Fable, o modelo mais capaz que a Anthropic vende de forma ampla. Os preços de tabela são mais distantes do que a maioria imagina, porque, pela mesma quantidade de texto lido ou escrito, o Opus cobra quarenta vezes o que o Haiku cobra, e o Fable cobra duas vezes e meia o que o Opus cobra, o que coloca um fator de cem entre o trabalhador mais barato e o mais caro do mesmo time.
O segundo fator é o esforço, que define a quantidade: quanto tempo o trabalhador pensa antes de agir e quantos passos ele se permite pelo caminho. Ele tem cinco níveis, que o produto chama de low, medium, high, xhigh e max, e vale para tudo o que o modelo produz: o raciocínio, as ações que ele executa nos seus sistemas e a explicação que escreve no fim. Com esforço baixo o modelo vai direto ao ponto; no topo ele explora, confere duas vezes e explica. Esforço é um sinal, não um orçamento, insiste a documentação: mesmo no nível mais baixo o modelo ainda pensa quando o problema é de fato difícil, só que pensa menos.
Multiplique um pelo outro e aparece uma possibilidade que contraria a intuição. Como o Haiku custa quarenta vezes menos por palavra que o Opus, um Haiku com tempo para pensar bastante ainda pode custar uma fração de um Opus pensando pouco, e num trabalho que está ao seu alcance vai entregar o mesmo resultado. O modelo barato com espaço para pensar é, muitas vezes, a escolha eficiente. Há só uma pegadinha, e ela molda toda a segunda metade deste artigo: o Haiku mantém esse preço apenas enquanto a conversa que recebe continua curta, abaixo de uns cem mil tokens, a unidade em que o provedor conta o texto, ou mais ou menos um livro de trezentas páginas; passando disso, o preço sobe cinco vezes e ele fica só oito vezes mais barato que o Opus. O Haiku é o trabalhador certo para um serviço pequeno e bem definido, entregue inteiro, e o errado para uma sessão longa que não para de crescer.
O preço do trabalho pronto, não do pedido
Uma ideia muda a maneira de ler a matriz de seis pedidos que vem a seguir. O jeito natural de comparar modelos é pelo custo de um único pedido, e essa é quase sempre a comparação errada, porque uma tentativa barata que precisa ser refeita não é barata, e uma cara que acerta de primeira muitas vezes é a pechincha. O que importa é o custo do trabalho pronto, contadas todas as tentativas e todas as horas de atenção.
É por isso que a eficiência escapa pelos dois lados da medida certa. Acima dela, você está pagando a mais, comprando um critério de que o trabalho não precisava e recebendo de volta só uma conta maior. Abaixo dela, o modelo está fraco demais, o que parece economia até o retrabalho chegar, e retrabalho é a linha mais cara de qualquer conta, porque paga as duas tentativas e quem precisou perceber o erro. Os testes de programação da própria Anthropic mostram um caminho do meio sensato quando existe um jeito confiável de separar sucesso de fracasso, como testes automatizados: rode tudo com esforço baixo e refaça só as falhas com um esforço maior, o que nos testes deles manteve a qualidade de rodar tudo no alto por pouco mais da metade do custo.
Seis pedidos
A seguir vêm seis pedidos típicos que um time de software entrega a um agente de IA toda semana. São exemplos compostos, não relatos de coisas que aconteceram conosco, e cada um é contado como o pedido chegando e a escolha que ele merece.
O primeiro é um endpoint: um novo endereço no sistema que devolve, digamos, os pedidos em aberto de um cliente, com uma regra de negócio simples sobre quais pedidos contam como abertos. A regra está escrita, o padrão já existe em uma dúzia de endpoints vizinhos, e o trabalho é sobretudo repetição fiel, então a medida certa é o Haiku com esforço high, que a documentação recomenda para seguir instruções à risca. O Opus em xhigh seria pagar a mais, o mesmo endpoint por muitas vezes o preço, enquanto o Haiku em low diante de uma regra vaga ficaria fraco demais, porque um modelo pequeno com pressa numa regra ambígua tende a chutar. No momento em que a regra fica obscura, o certo é subir, não torcer.
O segundo é um bug: um aviso de que o total de uma fatura às vezes sai errado. Um bug que se reproduz é trabalho de detetive com a confissão já em cima da mesa, e o Sonnet com esforço high é a medida certa, com critério suficiente para seguir a pista por várias partes do sistema. Um bug que não se reproduz, daqueles que aparecem às terças sob carga, é onde você sobe. O Fable em max num erro de digitação é pagar a mais em estado puro, e o Haiku num bug intermitente fica fraco demais do jeito mais caro, porque vai achar alguma coisa, corrigir com toda a confiança e deixar a causa real onde estava.
O terceiro é uma refatoração, reorganizar o código sem mudar o que ele faz. Quando ela é mecânica, como renomear um conceito no sistema inteiro ou dividir um arquivo que cresceu demais, o Sonnet com esforço medium dá conta com folga, e colocar o Opus para renomear não compra nada. A subida vem quando a própria estrutura muda, quando a pergunta deixa de ser como chamamos isto e passa a ser onde isto deve morar. A versão fraca demais aqui é a mais perigosa das seis: um modelo barato varrendo muitos arquivos sem testes para pegá-lo, produzindo uma mudança que parece arrumada e quebra em silêncio.
O quarto são os testes, e escrever testes a partir de uma especificação clara é trabalho cuidadoso e minucioso, não inspirado, de modo que o Sonnet com esforço high é a medida certa, com o esforço gasto em cobrir os casos e não em senioridade. Quando as regras são críticas, como dinheiro, conformidade ou dados pessoais, você sobe. O Fable em testes de rotina é pagar a mais, enquanto o caso fraco demais nem é sobre o tamanho do modelo: é o teste escrito pelo mesmo trabalhador que escreveu o código, que tende a testar o que construiu e não o que foi pedido, e por isso compartilha cada ponto cego do código.
O quinto é a revisão de código, e aqui a matriz se inverte. Um revisor mais fraco que o autor só consegue revisar ortografia, como diz a configuração do nosso próprio time, então a medida certa é o modelo do autor ou um mais forte, com esforço high; a revisão é um dos lugares em que o modelo caro é o eficiente, porque um defeito que ele pega não custa nada perto do mesmo defeito encontrado em produção, e você sobe de novo quando a mudança toca segurança, dinheiro ou dados. O Fable em max numa mudança de uma linha ainda é pagar a mais, mas o erro caro é o revisor barato que aprova o que não entendeu e dá a todo mundo uma falsa sensação de segurança.
O sexto é a arquitetura: uma decisão sobre como o sistema será construído, qual banco de dados, qual fronteira entre serviços, por onde os dados passam. O Opus em xhigh é a medida certa, e quando a decisão vai ser cara de desfazer, de modo que um erro só apareceria meses depois, vale passar para o Fable em max, porque nenhuma economia na decisão paga um alicerce errado. O Fable em max numa escolha que pode ser revertida na semana que vem é pagar a mais, e o Sonnet ou o Haiku decidindo a arquitetura ficam fracos demais de um jeito que a conta só vai mostrar muito tempo depois, o que faz disso o pior tipo.
Lidos juntos, os seis mostram um padrão: a ponta barata da matriz é onde o trabalho já está decidido e só precisa ser feito, a ponta cara é onde o trabalho é decidir, e nenhuma das células é lei, só um lugar para começar antes que o seu próprio trabalho mova uma linha para cima ou para baixo.
O time que escolhe por você
Uma matriz só serve se alguém a consultar, e a lição do episódio 4 é que, deixado por conta própria, ninguém consulta: o padrão vence, e o padrão é o modelo mais caro, que é onde entra o desenvolvimento com subagentes.
Um subagente é um segundo trabalhador de IA a quem o principal entrega uma parte do trabalho. Ele começa do zero: lê só o que precisa para a sua parte, faz o trabalho pesado por conta própria e devolve um resultado curto, de modo que a conversa principal continua pequena e focada. Esse começo do zero é o propósito do desenho e também a sua exigência, porque um subagente não sabe nada que a entrega não lhe diga. É também exatamente o serviço pequeno e bem definido que mantém um modelo barato no seu preço barato. Desenvolvimento com subagentes é organizar o trabalho desse jeito de propósito: um líder que entende o pedido, decide o plano e confere o resultado, e ajudantes, os subagentes, cada um fazendo um tipo de trabalho com o modelo e o esforço que aquele tipo de trabalho merece.
O nosso time, que A Cultura que se Instala descreve por inteiro, tem cinco ajudantes, e as configurações deles são a matriz escrita no próprio time.
O leitor roda no Sonnet com esforço low, porque lê e relata e não decide nada, que é o próprio exemplo da documentação para o esforço baixo. O construtor roda no Sonnet em medium, porque quando recebe uma mudança ela já está decidida, e o líder pode entregar uma trivial ao Haiku. O testador roda no Sonnet em high, porque atacar um trabalho pede profundidade e paciência mais do que senioridade. O revisor e o líder de QA, que decide o que os testes precisam cobrir, trabalham os dois no próprio modelo do líder e com esforço high, porque são os dois lugares em que um trabalhador mais fraco deixaria passar os erros do líder.
Há um princípio escondido nesse arranjo, e é o que eu levaria deste artigo se levasse um só: o esforço pertence ao papel, e o modelo pertence ao pedido. O esforço de cada ajudante fica fixo na sua própria descrição, porque o tipo de pensamento que um trabalho pede é uma propriedade do trabalho, enquanto o modelo é escolhido pelo líder a cada entrega, porque o quanto esta mudança é difícil depende da mudança. Assim o time não acerta cada célula da matriz com exatidão: o endpoint que a matriz põe no Haiku em high sai como o construtor no Haiku com o seu medium de sempre, e essa é uma troca que aceitamos de propósito, porque um time cujos papéis se comportam sempre do mesmo jeito é previsível e barato de operar, e um pouco de precisão é um preço justo por isso. Quando um pedido realmente precisa de outro esforço, a ferramenta permite defini-lo só para aquela entrega.
O episódio 4 contou o que acontece sem isso. O nosso testador não tinha modelo nomeado na sua descrição, e por isso durante 1.441 rodadas de trabalho herdou em silêncio o mais caro, a 13 centavos por rodada; depois que ganhou um nome, o mesmo trabalho passou a custar menos de 5 centavos. Ninguém tinha escolhido mal; ninguém tinha escolhido, simplesmente.
O líder é a próxima alavanca
O episódio 4 terminou apontando para o próprio líder, que, depois que os ajudantes foram para modelos mais baratos, tinha virado uns setenta por cento da conta de um dia tranquilo. A matriz responde isso na teoria, porque o líder é um trabalhador como qualquer outro e o seu modelo pode ser escolhido a cada sessão de trabalho. Uma sessão dedicada à arquitetura, ou a uma mudança que pede uma revisão exigente, mantém o Opus como líder, enquanto um dia de endpoints de rotina e pequenas correções pode ser liderado pelo Sonnet.
Há um risco nisso, e vale dizê-lo com todas as letras: o revisor e o líder de QA seguem o modelo do líder, então quando o líder desce eles descem junto. Rebaixar o líder só é certo nos dias em que uma revisão no nível do Sonnet basta, o que vale para a maioria dos dias e não para todos. É uma recomendação que ainda não medimos, e quando tivermos o comprovante ele vai virar episódio.
A medida certa
A planilha está fechada agora, porque o que ela realmente dizia cabe numa página. Eficiência com IA não é o modelo mais barato nem o mais capaz; é uma escolha feita a cada pedido, em preço e quantidade, perguntando o quanto o trabalho é difícil e o quanto um erro sairia caro, e ela falha pelos dois lados: ou você paga por um critério que não usou, ou paga duas vezes pelo critério que não comprou. O padrão é o que custa dinheiro, porque o padrão é o modelo mais caro fazendo tudo, e o remédio é estrutura, um líder e seus ajudantes com a escolha escrita em cada papel, para que a medida certa aconteça até na segunda-feira em que ninguém se lembra de pensar nisso.
Fontes. Preços e níveis de esforço são os preços de tabela e a documentação publicados pela Anthropic em outubro de 2026; o resultado de rodar no baixo e refazer as falhas vem dos testes de programação da própria Anthropic; os números sobre o nosso trabalho são os do episódio 4.