Teste de custo de modelo no vibe coding: 10 centavos por candidato

Antes de escolher o modelo que vai para produção, dê a cada candidato o mesmo teto de gasto, 10 centavos de dólar, e solte todos no fluxo inteiro do seu produto para ver até onde cada um chega. O que sai disso é uma medida de alcance dentro do orçamento, e ela diz mais sobre o que vai acontecer em produção do que a nota de qualquer benchmark de marketing.

Guilherme Saraiva abriu essa tabela ao vivo porque foi cobrado. Ele tinha acabado de mostrar quanto um jogador custaria por mês no sistema de RPG com IA que constrói em público, e veio a pergunta do chat:

como que você validou esses números aqui se você não tem base de jogadores ainda?

A resposta começou em "eu fiz uma média" e terminou com ele arrastando na tela o relatório de um teste automatizado. Ele montou com o assistente de código um sistema de contagem de tokens ligado aos logs do agregador por onde chama os modelos, e é esse sistema que roda o teste antes de qualquer troca.

O teto de gasto igual é o que torna os candidatos comparáveis

O desenho cabe numa frase dele:

com cap de até 10 centos de dólar para cada modelo. E ele vê até onde esse modelo vai na história.

Fixar o dinheiro e medir quanto de produto cabe lá dentro inverte o eixo da comparação. Um modelo mais barato por token que precisa de duas tentativas para acertar a mesma ação aparece na tabela como distância percorrida menor, sem que você tenha que cravar critério de qualidade antes de rodar. O teto também limita o custo do próprio teste, porque soltar todos os candidatos numa sessão inteira sem limite gasta mais do que a resposta vale. Esse mesmo número de custo por sessão é o que depois vira preço na ponta, como em vibe coding para precificar por crédito com base no custo real da API. Foi o mesmo caminho de glm no vibe coding.

O script joga o produto inteiro, não um prompt isolado

A segunda decisão de desenho é o que o script exercita:

Ele mesmo roda aqui, ele joga, ele força o modelo a jogar eh tudo, tudo, tudo. Então, rolagem de dado, movimentação de personagem, narração, ataque, tudo, tudo isso. E com até 10 cent dólar.

O script assume o papel do jogador e obriga o modelo a passar por cada parte do sistema. Rolagem de dado depende de o modelo chamar a ferramenta certa e devolver o formato combinado. Movimentação mexe no estado da partida. Narração é texto longo em português, e o combate junta tudo isso num turno só. Um prompt solto pedindo uma cena de taverna teria aprovado quase todos os candidatos.

Escrever esse script é o trabalho que o teste custa. Se o produto já roda, metade dele existe: as chamadas estão prontas, falta o laço que dispara uma sessão inteira sem humano no meio e vai somando o gasto.

A tabela mostra quem quebrou e de que jeito

E ele tabelou para mim ali, entendeu, os custos, quem foi bem, quem foi mal.

O que a tabela tem de mais útil são os modos de falha, e nenhum deles apareceria numa nota de benchmark. Um dos modelos parou no meio da partida:

mas ele ficou mudo no quarto e no quinto turno, então ele parou de responder

Ele estava dentro do orçamento e narrando bem, e mesmo assim não serve, porque um mestre que emudece no quarto turno acaba com a sessão do jogador.

Outro candidato entregou ao jogador o que devia ficar escondido:

vaza pro jogador as toos de combate. Então o jogador vê o que o mestre tá fazendo.

Guilherme explicou a gravidade com a regra da mesa, e não com argumento técnico:

E quem já jogou RPG sabe que tu não vê o que o mestre tá fazendo. Tem um um item, um acessório que chama escudo do mestre que te protege de ver o que o mestre tá fazendo.

Essa falha só aparece num teste que percorre o fluxo, porque ela não está na qualidade da resposta e sim na fronteira: o conteúdo está correto e chegou ao destinatário errado. Todo produto tem uma fronteira dessas. No RPG é a rolagem secreta do mestre; num app de suporte é a política interna que mora no prompt de sistema.

A terceira falha era comum a todos os candidatos, pedaços de JSON escapando para dentro da narração, e essa ele diz que já resolveu do seu lado. Para o candidato que passou limpo sobrou o problema mais velho do mercado: "é perfeito, mas muito caro".

Como rodar um teste de custo de modelo no seu vibe coding

Comece pela lista de candidatos que você trocaria mexendo em uma variável de ambiente. Num projeto de vibe coding essa lista costuma ser longa, já que o agregador entrega todos eles pela mesma API. Escolha então um teto de gasto que doa pouco e ainda assim leve o produto longe, o mesmo para todo mundo, e escreva o roteiro do teste como uma sessão de usuário, com as ações que o seu produto realmente tem. Se precisar baratear, separe qual parte só precisa decidir regra e qual parte escreve prosa. Vale ver como isso aparece também em vibe coding para vencer o perfeccionismo.

Registre 2 colunas por candidato: até onde ele chegou dentro do teto, que é a sua conta de custo por sessão antes de existir um usuário pagante, e o que ele fez de errado no caminho. A segunda coluna costuma decidir a escolha, porque emudecer no quarto turno ou mostrar ao usuário o que era para ficar atrás da cortina são defeitos que preço baixo nenhum compensa. Vale ver como isso aparece também em cache de contexto no vibe coding.

Responder à pergunta do chat com a tabela aberta, em vez de com uma estimativa, é o que as leis cobram de quem constrói em público, e é assim que o vibe coding decide qual modelo entra no produto. Dá para assistir à live e ver a tabela linha por linha, com ele lendo quem foi bem e quem foi mal.