Claude Fable 5.2 montou um shooter de navegador em 8 horas por cerca de US$ 550

Deixar uma IA montando um protótipo durante a noite é uma ideia tentadora, até a conta chegar de manhã. A história do shooter de navegador Saltline mostra o que vale observar de antemão: o agente precisa receber o contexto da tarefa muitas vezes, e esse fluxo de entrada pode custar mais do que o código escrito. Para uma equipe que testa desenvolvimento autônomo, trata-se de um item de orçamento bastante concreto.

Segundo o engenheiro da Anthropic Felix Rieseberg, o Claude Fable 5.2 criou o Saltline em cerca de oito horas, recebendo um único prompt inicial e nenhum feedback humano durante o trabalho. O custo declarado, nas tarifas da API, é de cerca de US$ 550. O autor também indicou aproximadamente 2,7 milhões de tokens de saída e 445 milhões de entrada, boa parte dos quais passou pelo cache. Os links para o post do autor e para o jogo acompanham a mensagem original; não temos um detalhamento de custos verificado.

O que saiu em oito horas

Saltline é um shooter em primeira pessoa para navegador, com uma única missão. Segundo a descrição do experimento, o modelo criou o código, os modelos, os sons e as texturas. É um exemplo interessante de tarefa em que várias partes precisam ser coordenadas: imagem, controles, jogabilidade e som devem funcionar em conjunto.

O título «Call of Duty por US$ 550» cria uma expectativa ampla demais. Uma única missão não permite estimar o custo de um jogo grande, com campanha, modos online, suporte a diferentes dispositivos e testes prolongados. Aqui é mais útil ver o experimento como uma tentativa de obter um protótipo de jogo limitado em uma única execução prolongada.

Há ainda outro ponto: um prompt não significa uma única resposta do modelo. Sem feedback humano, o agente ainda pode executar muitas etapas, chamar ferramentas, receber resultados e continuar o trabalho. Quais verificações foram realizadas nessa execução não é possível saber a partir dos números apresentados. Por isso, vale transpor o resultado para um projeto próprio por meio de um pequeno teste.

Por que os tokens de entrada foram 165 vezes mais numerosos

Imagine que o agente adiciona uma porta ao jogo. Ele recebe a tarefa e o código necessário. Após a edição, recebe o resultado da ferramenta, depois corrige um erro ou passa ao objeto seguinte. A requisição seguinte volta a conter parte do material anterior mais novos dados. Ao longo de uma sessão longa, o volume de entrada pago se acumula.

Dividir 445 milhões por 2,7 milhões dá cerca de 165 tokens de entrada para cada token de saída. Trata-se da proporção entre os volumes totais da execução. Ela não prova que o modelo recebeu o projeto inteiro a cada passo nem que o contexto cresceu continuamente: para essa conclusão, é preciso um registro das requisições.

O cache permite processar a um custo menor a parte repetida da entrada. Ainda assim, o modelo não ganha memória de longo prazo automática: o desenvolvedor continua precisando gerenciar quais materiais entram na requisição. O valor prático do cache é especialmente visível quando o agente trabalha muitas vezes com as mesmas instruções e grandes trechos de contexto.

O que realmente dá para calcular

A Anthropic indica para o Fable 5.2 tarifas básicas de US$ 8 por milhão de tokens de entrada e US$ 40 por milhão de saída. Com essas taxas, 2,7 milhões de tokens de saída custam US$ 108. Se todos os 445 milhões de entrada fossem pagos pela taxa básica, seriam mais US$ 3.560. No total, US$ 3.668, cerca de 6,7 vezes mais que os US$ 550 declarados.

Mas esse é um cálculo hipotético, sem cache, e não uma reconstrução da fatura do experimento. Se tomarmos o total de US$ 550 e o custo de saída de US$ 108, restam cerca de US$ 442 para a entrada, ou aproximadamente US$ 0,99 por milhão de tokens em média. A taxa exata de acertos no cache não pode ser deduzida disso sem um detalhamento por leitura, gravação e tarifas aplicadas.

Antes de uma execução assim, o desenvolvedor deve ativar o controle dessas categorias de custo e definir um limite financeiro. O gerente de produto deve definir antecipadamente os critérios de conclusão: se a missão inicia, se é possível completá-la, em quais dispositivos funciona. Para o fundador, o próximo passo útil é repetir uma tarefa limitada várias vezes e comparar o custo do resultado aceito. Uma execução bem-sucedida mostra a possibilidade; o orçamento de um produto exige também previsibilidade.