Vibe coding para reduzir custo de token: separe o juiz do narrador

Quando o custo por usuário não fecha, a reação comum é trocar o modelo inteiro por um mais barato e engolir a queda de qualidade. Existe um corte melhor antes desse: abrir uma interação ao meio e perguntar qual parte daquele trabalho precisa escrever bem. A parte que só decide regra roda num modelo pequeno e barato. Só a parte que produz texto para o usuário ler paga o preço da prosa.

Foi essa a mudança que o time por trás de um RPG com combate por turnos desenhou e testou na mesma live, o projeto que Guilherme constrói em público. Ainda no desenho da arquitetura, antes de existir código rodando, eles estimaram que a separação ia cortar o custo "pela metade praticamente". Bem depois, com o teste rodado no próprio sistema, leram o resultado: "cortou tipo 45% do custo". A estimativa e a medição chegaram perto uma da outra, mas são coisas diferentes, e vale saber qual é qual antes de copiar a ideia.

Um modelo fazendo tudo é um modelo cobrando por tudo

O ponto de partida era um único modelo tocando o turno inteiro. Ele resolvia regra, verificava inventário, atualizava o codex do jogador, mexia no minimapa, conduzia o combate e ainda narrava a cena. "Ela tá narrando tudo, tudo, tudo", resumiram na live, descrevendo a IA "cuidando de várias coisas ao mesmo tempo".

Cada mensagem do jogador obrigava esse modelo a decidir o que chamar, às vezes mais de uma coisa por vez, e todas essas decisões passavam pelo mesmo modelo caro que escrevia a narração. Como eles repetem no quadro, "tudo isso custa". Com o catálogo de ferramentas do jogo pendurado no contexto, o custo por jogador ficou alto demais para o produto fechar a conta, e a leitura deles foi direta: "dá para baratear, rapaziada". O mesmo problema apareceu em vibe coding para calcular custo real de api de video antes de usar.

A pergunta que decide onde o modelo caro entra

A régua que eles aplicaram tem uma pergunta só: esta etapa precisa escrever bem? Se não precisa, ela não paga modelo caro.

Aplicada ao turno do RPG, essa régua parte o trabalho em dois papéis. Um juiz de mecânica resolve as regras, decide se o jogador consegue ficar furtivo, dispara a rolagem de dados, confere o que o personagem pode ou não fazer. Esse juiz não escreve uma linha de prosa, então pode rodar num modelo pequeno e barato sem que o jogador perceba diferença. Do outro lado, um narrador recebe o log que o motor do jogo produziu e transforma aquilo em cena. É o único lugar onde a qualidade de escrita aparece na tela, e o único que justifica o modelo caro.

No quadro da live, a arquitetura ficou registrada como "juiz de mecânica, mais narrador separado atrás da flag". São 2 chamadas de modelo por turno, uma para cada papel, com o modelo caro reservado à ponta da prosa. Quem faz vibe coding costuma tomar essa decisão no escuro, escolhendo um modelo para o sistema inteiro; a régua troca a escolha única por duas escolhas baratas de defender.

O juiz emite um lote e nunca é reperguntado

A outra metade da economia não está em qual modelo roda, e sim em quantas vezes ele é chamado. O desenho fecha essa porta:

O juiz emite um lote de tools e nunca é reperguntado.

O motor do jogo roda esse lote inteiro, cobre a iniciativa que ficou esquecida e resolve a vez dos inimigos sozinho. O ida e volta é onde o token se multiplica, porque cada repergunta reenvia o histórico inteiro e o contexto incha a cada rodada. Cortar o loop é o que faz o juiz ficar barato de verdade, para além de rodar num modelo menor.

Vibe coding para reduzir custo de token começa pela ponta cara

Na leitura do resultado veio a frase que fecha o raciocínio da arquitetura inteira:

A conta só fecha com narrador barato na ponta da prosa.

Cortar o desperdício das rodadas de turno resolve metade do problema. Se a narração continuar rodando num modelo caro, ela puxa a conta de volta para cima sozinha, porque é ela que gera o texto mais longo do turno, toda vez, para todo jogador. É preciso baratear onde o custo está, e não em volta dele. O mesmo raciocínio aparece quando é preciso medir o custo de um modelo antes de adotar.

Estimativa é uma coisa, medição é outra

O "pela metade praticamente" foi uma projeção feita no desenho, antes de existir código rodando, do tipo que qualquer um faz de cabeça olhando para a arquitetura nova. Os 45% saíram depois, de uma rodada de teste do próprio sistema deles, com o juiz forçado num modelo pequeno e a narração no modelo caro. É medição de primeira mão do produto deles, não benchmark de fornecedor. Quando o resultado apareceu na tela, o veredito lido na live foi "Saiu validado".

Ter estimado pela metade e medido 45% importa por um motivo específico: o modelo mental da arquitetura estava certo antes de o código existir. Não vira promessa de produção nem número que você pode esperar no seu caso. O mesmo problema apareceu em access token mercado pago.

A dobra que você consegue fazer no seu próprio agente

Pegue o agente que você está construindo e liste o que ele faz numa interação. Marque cada item com uma pergunta só: isso vira texto que o usuário vai ler? O que não vira sai do modelo caro hoje mesmo. Depois conte quantas idas e voltas cada decisão exige, e veja se dá para pedir o pacote inteiro de uma vez em vez de conversar com o modelo. Decidir barato e escrever caro é o tipo de dobra que o vibe coding força cedo, porque a conta chega antes do produto ficar pronto.

Vale assistir à live para ver a arquitetura sendo desenhada primeiro e o número sendo lido bem depois, na ordem em que aconteceu.