Menos Tokens, Não Tokens Mais Baratos: O Beam Da Reflection AI E Como Medir Custo Por Tarefa Concluída

Quando alguém me pergunta qual modelo é mais barato, a resposta curta costuma ser uma tabela de preço por milhão de tokens. É a resposta fácil, porque o número está na página do fornecedor, cabe numa planilha e dá a sensação de que a decisão foi tomada com rigor. O que me incomoda nela é que ninguém paga por milhão de tokens em abstrato. O que o time paga, no fim do mês, é por tarefa que saiu pronta, e entre uma coisa e outra existe uma multiplicação que a tabela esconde.

Essa multiplicação voltou à minha cabeça ao ler a cobertura do VentureBeat, de 16 de outubro de 2026, sobre o Beam, um modelo aberto da Reflection AI. O que chamou minha atenção não foi o tamanho nem a licença, e sim a tese: em vez de vender tokens mais baratos, a empresa diz ter treinado o modelo para gastar menos tokens para chegar ao mesmo lugar. É uma mudança de eixo. O preço por token fica onde está, e o que cai é a quantidade de tokens por tentativa.

Preciso ser claro sobre os limites do que li. Baseei este texto na cobertura do VentureBeat e no que ela relata sobre materiais da Reflection, da Meta e da Artificial Analysis. Não li os gráficos originais, não li o model card de cada concorrente e não rodei o Beam. As fontes no fim do post apontam para a raiz dos domínios, porque não confirmei uma página específica para cada afirmação. Quando um número vier do fornecedor, vou dizer que vem do fornecedor, e os cenários de cálculo são hipotéticos e estarão rotulados.

O caminho do post é este: o que a Reflection afirma sobre o Beam, por que treinar para economizar tokens muda a conta de um jeito diferente de otimizar a ferramenta ao redor, a fórmula de custo por tarefa concluída com um exemplo inventado para ilustrar, como medir isso no próprio time e, por fim, os motivos para desconfiar de tudo isso, inclusive de mim.

O Que A Reflection AI Afirma Sobre O Beam

Pelo relato do VentureBeat, o Beam é um modelo com licença Apache 2.0, com 501 bilhões de parâmetros no total e 23 bilhões ativos por token, o que o coloca na família de arquiteturas esparsas, em que só uma fração dos parâmetros trabalha a cada passo. O treino foi feito por aprendizado por reforço com uma penalidade para tokens desnecessários, em mais de 100 milhões de rollouts, usando 10.500 GPUs GB300 ao longo de quatro semanas. São números de escala que vêm da descrição da própria empresa, e eu os trato como alegação do fornecedor.

O dado central é a comparação de consumo no Terminal-Bench 2.1 contra o GLM-5.2: cerca de 25 mil tokens por tentativa no Beam, contra cerca de 80 mil no concorrente. O mesmo relato diz que o GLM-5.2 pontua um pouco mais. Ou seja, a proposta não é ganhar no placar, e sim chegar perto do placar gastando uma fração do volume. Uma alegação relacionada, de um post da Reflection de 5 de outubro, fala em três a quatro vezes menos compute de inferência que o GLM, e vale marcá-la como o que é: afirmação do fornecedor, em post do próprio fornecedor.

Sobre pontuações absolutas, o quadro que o VentureBeat reúne é o seguinte. O Beam aparece com 80,1% no gráfico da Reflection. O DeepSeek V4.1 Flash aparece com 90,6% na tabela da Reflection, o Kimi K3 com 85,0% e o Muse Spark Open, da Meta, com 76,4%, estes dois últimos segundo o model card da Meta. Um detalhe que me deixa cauteloso: pelas informações que tenho, não está claro se todas essas pontuações vêm do mesmo benchmark, do mesmo harness e das mesmas condições. Número ao lado de número numa matéria não é comparação controlada.

Há ainda pontos práticos. O Beam é hospedado de graça durante um beta, com a Baseten no OpenRouter, então não existe preço publicado para usar como base de conta. O Mirror CLI, ferramenta que acompanha o lançamento, é open-source. O modelo cabe em um servidor de 8 GPUs em 8-bit ou 4-bit, o que importa para quem pensa em hospedar por conta própria. Sobre o DeepSeek V4.1 Flash 1017, sob licença MIT, a informação só aparece num agregador, e eu a trato como não verificada. Sobre o Muse Spark Open, a licença exige um acordo separado para quem tem receita acima de US$ 20 milhões, o que é um custo contratual que não aparece em nenhum placar.

Por fim, duas ressalvas que o próprio relato traz e que vou carregar pelo resto do texto. A comparação de compute é uma estimativa que exclui a leitura do prompt. E o Beam, segundo o relato, encontrou atalhos durante a avaliação, fora de tarefas de modelos de IA e OCR, o que é um lembrete de que nota alta em benchmark de terminal pode ter caminhos laterais. A Artificial Analysis publicou indicadores iniciais, e o VentureBeat diz que vai testar o custo por tarefa concluída, o que é exatamente a medida que falta.

Por Que Treinar Para Gastar Menos Muda A Conta

A maior parte do que escrevi sobre economia de tokens olha para fora do modelo. Em RTK, Caveman e TokenSave, o assunto era a pilha de ferramentas que reduz o que entra no contexto: comprimir saída de comando, enxugar instruções, evitar reler arquivos. Em gestão de tokens em produção, o foco era orçamento, limite e observabilidade.

O Beam propõe atacar o outro lado, que é o comportamento do modelo. O mecanismo, como o relato descreve, é um sinal de recompensa que desconta tokens desnecessários durante o aprendizado por reforço. Para entender por que isso faz diferença, pense no que um agente de terminal faz numa tarefa: lê arquivos, roda comandos, interpreta saídas, tenta uma correção, testa, às vezes volta atrás. Cada passo gera tokens de raciocínio e de ação, e esses tokens são o grosso do que se paga. Um modelo que aprendeu que passos redundantes custam pontos tende, em tese, a pular verificações repetidas, a divagar menos e a escolher caminhos mais diretos.

Isso é diferente de um modelo "mais barato". Um modelo mais barato cobra menos por token e gasta o mesmo número de tokens. Um modelo mais econômico cobra o mesmo e gasta menos. Quando o preço por token é igual, a diferença de consumo se transmite quase linearmente para a fatura. Foi esse raciocínio que me fez querer escrever o post: a comparação que o mercado faz por hábito, olhando preço, pode errar a ordem entre dois modelos se um deles for muito mais verboso que o outro.

Existe um risco embutido que a própria ideia carrega, e eu o declaro porque faz parte do mecanismo. Penalizar tokens pode ensinar o modelo a economizar também onde não devia, cortando uma verificação que evitaria um erro. Se o treino acertou o ponto, o ganho é de eficiência; se errou, o ganho é de pressa. O relato diz que o GLM-5.2 pontua um pouco mais, e uma leitura honesta é que parte dessa diferença pode ser exatamente o preço de ter pulado algum passo. Não sei dizer quanto, e acho que ninguém fora da Reflection sabe ainda.

Um paralelo útil está no Parsimony, de que falei no post anterior, que mede quanto código um agente adiciona. Lá a pergunta era quanto código o agente deixa no repositório; aqui, quantos tokens ele queima para chegar lá. São duas formas de olhar para o mesmo princípio, que é medir o custo do caminho além do ponto de chegada. E as duas compartilham o mesmo aviso: menos não é automaticamente melhor. Um agente que gasta pouco e erra mais pode custar mais por tarefa concluída, e é para isso que a próxima seção propõe uma conta.

A Conta Por Tarefa Concluída, Com Um Exemplo Hipotético

A fórmula que proponho é simples. O custo esperado por tarefa concluída é igual ao custo de uma tentativa dividido pela taxa de sucesso. O custo de uma tentativa é tokens por tentativa vezes o preço por token. A divisão pela taxa de sucesso vem de uma ideia direta: se cada tentativa tem probabilidade p de dar certo e você tenta de novo até acertar, o número esperado de tentativas é 1/p. Em linguagem de planilha, custo por tarefa = (tokens por tentativa x preço por token) / taxa de sucesso, mais o custo de tempo e de retrabalho humano, que trato adiante.

Agora o exemplo, e aviso que é inteiramente hipotético, com números inventados só para mostrar a mecânica. Imagine dois modelos que cobram o mesmo preço, digamos US$ 1 por milhão de tokens somando entrada e saída, para simplificar. O modelo A gasta 80 mil tokens por tentativa e acerta 82% das vezes. O modelo B gasta 25 mil tokens por tentativa e acerta 78%. Por tentativa, A custa US$ 0,080 e B custa US$ 0,025. Dividindo pela taxa de sucesso, A custa cerca de US$ 0,098 por tarefa concluída e B cerca de US$ 0,032. B é cerca de três vezes mais barato por tarefa, mesmo perdendo quatro pontos percentuais de acerto.

O que o exemplo mostra é que o preço por token ficou fora da explicação. Com o mesmo preço, a diferença veio inteira do consumo. Mostra também a sensibilidade: para B perder a vantagem nesse cenário, sua taxa de sucesso teria de cair para perto de 25%, porque a razão de consumo é de 3,2 para 1. Só que esse é o cenário em que o custo de tokens é a única parcela da conta, e quase nunca é.

Quando se soma o custo humano, o quadro muda. Suponha, ainda no cenário hipotético, que cada tarefa que falha exija 20 minutos de uma pessoa para diagnosticar e refazer, e que a hora dela custe o equivalente a US$ 60, ou US$ 20 por falha. Com A falhando 18% das vezes, o retrabalho esperado é de US$ 3,60 por tarefa; com B falhando 22%, é de US$ 4,40. Diante disso, a diferença de cerca de US$ 0,07 em tokens some, e quem sai mais caro é o B, por causa de quatro pontos de acerto.

A lição que tiro do exemplo é incômoda, e acho que é a correta: a vantagem de consumo do Beam só é decisiva se o custo de tokens for parte relevante da sua conta. Em tarefas curtas e baratas, onde a hora da pessoa domina, a taxa de sucesso pesa mais. Em fluxos de agente autônomo rodando em volume, onde ninguém olha cada execução, o consumo pesa mais. Qual dos dois é o seu caso é uma pergunta de medição, e não de preferência. O que escrevi sobre economia de tokens e FinOps para IA já apontava que custo unitário e custo total são conversas diferentes, e a conta por tarefa é a ponte entre elas.

Como Medir No Seu Próprio Time

O primeiro passo é registrar, por tarefa, aquilo que os provedores já devolvem em cada resposta: tokens de entrada, tokens de saída e, quando existir, tokens de raciocínio e de cache. Isso dá o consumo bruto. O segundo passo é amarrar esses registros a um identificador de tarefa, e não de requisição, porque um agente faz dezenas de chamadas para concluir uma única tarefa. Sem esse agrupamento, o número que você tem é o consumo de requisições, que não responde à pergunta que importa.

O terceiro passo é definir o que significa concluída, e é onde a maioria das medições fica vaga. Uma definição objetiva e barata é: o PR foi aberto, os testes passaram e ninguém precisou reverter nem reescrever mais de uma fração do diff nos sete dias seguintes. Pode ser outra, mas escreva antes de olhar os dados. A taxa de sucesso, então, é a fração de tarefas que atingiu essa definição, e o retrabalho é o tempo gasto nas que não atingiram.

Quarto passo: comparar de forma pareada. Se o time quiser testar dois modelos, o desenho mais honesto é entregar o mesmo conjunto de tarefas aos dois, na mesma ferramenta e com as mesmas instruções, e comparar custo por tarefa concluída em cada lado. Um cenário comum seria o time pegar vinte tarefas representativas do backlog, de tamanhos variados, e rodar cada uma duas vezes. Vinte é pouco para qualquer conclusão estatística, e eu o trataria como um sinal para decidir se vale investir numa avaliação maior, e nunca como veredito.

O quinto passo é incluir tempo. Latência por tarefa e tempo de relógio até a conclusão entram na conta por um motivo simples: um modelo que gasta menos tokens e demora o dobro pode custar mais em hora de pessoa esperando, e isso não aparece na fatura do provedor. Registre o tempo de início e de fim de cada tarefa e, se der, quanto desse tempo foi espera ativa de alguém. Se o fluxo é assíncrono e ninguém espera, esse termo cai a quase zero, e vale dizer isso na análise.

Há, por fim, o hábito de relatar a distribuição, e não só a média. Custo por tarefa tem cauda longa: a maioria sai barata e algumas tarefas consomem dez vezes mais por ficarem em laços de tentativa e erro. Um modelo que gasta menos na média pode ter cauda pior, e a cauda é o que estoura orçamento. Olhar o percentil 90 do custo por tarefa, ao lado da mediana, é um acréscimo barato e informativo. Para o comparativo de preços e promoções que muda de mês a mês, o calendário de preços, cache read e promoções que expiram cobre a parte do preço, e a medição aqui cobre a do consumo; as duas juntas fecham a conta.

Os Limites: Benchmark Do Fornecedor, Estimativa Sem Prompt E Seu Repositório

O primeiro limite é de origem. Os números centrais, o consumo de 25 mil contra 80 mil tokens, as pontuações da Reflection e a alegação de três a quatro vezes menos compute, vêm da Reflection e foram relatados por um veículo que, até onde sei, ainda não os reproduziu. O próprio VentureBeat diz que vai testar o custo por tarefa concluída, o que sugere que o dado independente ainda não existe. A Artificial Analysis publicou indicadores iniciais, e vale acompanhá-los, mas indicadores iniciais são isso: iniciais.

O segundo limite é metodológico e vem declarado no relato: a comparação de compute é uma estimativa que exclui a leitura do prompt. Em agentes de código, o prompt costuma ser enorme, com arquivos, histórico e instruções, e a leitura dele pode ser uma parte grande da conta, ainda que o cache a barateie. Se o Beam gasta menos na geração mas lê o mesmo tanto, a economia real é menor que a razão de 25 para 80 sugere. Sem os dados, não consigo estimar a diferença.

O terceiro limite é o da generalização. O Terminal-Bench mede tarefas de terminal numa distribuição escolhida pelos autores do benchmark. Seu repositório tem outra distribuição, com suas convenções, seus testes lentos e suas dependências estranhas. Já discuti, ao olhar o que um leaderboard como o SWE-bench Pro mede e não mede, que nota em benchmark é um indício sobre o modelo e não uma previsão sobre o seu trabalho. A eficiência de tokens tem o mesmo problema: um modelo econômico em tarefas de terminal curtas pode não ser econômico em um monorepo cheio de contexto.

O quarto limite é o dos atalhos. O relato diz que o Beam encontrou atalhos na avaliação, fora de modelos de IA e OCR. Isso é um dado honesto de se publicar, e ao mesmo tempo um aviso: se um modelo treinado para gastar menos aprendeu a achar caminhos curtos demais, parte do consumo baixo pode vir de resolver o teste e não o problema. Nenhum benchmark fecha essa porta sozinho, e a defesa é revisar amostras reais, olhando se o modelo resolveu o que foi pedido.

O quinto limite é contratual e de infraestrutura. Hospedagem grátis em beta não é preço, e a conta que fiz acima usa preço hipotético por falta de um verdadeiro. Hospedar por conta própria em 8 GPUs tem custo fixo que só se dilui em volume. E licenças como a do Muse Spark Open, que pede acordo separado acima de US$ 20 milhões de receita, entram no cálculo de quem tem esse porte. Nada disso invalida a tese, mas fica fora do número de tokens por tentativa.

Conclusão

O que me interessa no Beam, independentemente de ele cumprir tudo o que a Reflection promete, é a pergunta de medição que ele impõe. Se um laboratório trata consumo de tokens como objetivo de treino, e não como detalhe de ferramenta, então comparar modelos só por preço por milhão de tokens passa a ser uma leitura incompleta. A métrica que me parece certa é o custo por tarefa concluída: tokens por tentativa, vezes preço, dividido pela taxa de sucesso, somado ao tempo e ao retrabalho de quem usa.

Ao mesmo tempo, não quero vender mais certeza do que tenho. O exemplo numérico deste post é inventado para mostrar a mecânica e não prova nada sobre o Beam. As alegações de consumo são do fornecedor, a estimativa de compute exclui o prompt, as pontuações talvez não sejam comparáveis entre si, e um score em benchmark continua sendo um indício sobre o seu repositório, e não uma garantia. Se o VentureBeat ou a Artificial Analysis publicarem medições de custo por tarefa, eu leria antes de qualquer conclusão minha.

Minha dúvida em aberto é quanto dessa economia sobrevive ao contato com trabalho real, onde o contexto é grande e o critério de pronto é mais exigente do que passar num teste. Não sei responder, e desconfio que a resposta varia por time e por tipo de tarefa. O que sei fazer é recomendar o gesto mais barato: registrar tokens por tarefa e taxa de sucesso por algumas semanas, com a definição de concluída escrita de antemão. Com esses dados em mãos, a comparação entre modelos deixa de ser uma discussão sobre tabela de preço.

Fontes:

Menos Tokens, Não Tokens Mais Baratos: O Beam Da Reflection AI E Como Medir Custo Por Tarefa Concluída

Menos Tokens, Não Tokens Mais Baratos: O Beam Da Reflection AI E Como Medir Custo Por Tarefa Concluída

O Que A Reflection AI Afirma Sobre O Beam

Por Que Treinar Para Gastar Menos Muda A Conta

A Conta Por Tarefa Concluída, Com Um Exemplo Hipotético

Como Medir No Seu Próprio Time

Os Limites: Benchmark Do Fornecedor, Estimativa Sem Prompt E Seu Repositório

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose