Preço por token não é custo por tarefa: a inversão que muda a economia dos modelos de raciocínio

Preço por token não é custo por tarefa: a inversão que muda a economia dos modelos de raciocínio

Modelos aparentemente baratos podem consumir mais tokens, executar mais etapas e terminar com uma conta maior - especialmente em agentes de programação e outros fluxos de trabalho longos.

Uma API, ou interface de programação, permite que uma aplicação envie solicitações ao modelo e receba respostas. Normalmente, a cobrança considera tokens - pequenas unidades em que textos e códigos são divididos durante o processamento. Em uma chamada simples, o custo pode ser representado aproximadamente por:

C = n_entrada × p_entrada + n_saída × p_saída

Aqui, n representa o número de tokens consumidos e p, o preço de cada tipo de token. O custo de inferência - isto é, de executar um modelo já treinado para produzir uma resposta - depende tanto do preço unitário quanto do volume consumido. A tabela do fornecedor mostra principalmente o p. Mas a aplicação paga por: p × n.

Nos modelos de raciocínio, a saída pode incluir tokens de pensamento: computação intermediária usada antes da resposta visível. Dependendo da API, esses tokens podem não aparecer para o usuário, embora sejam contabilizados e cobrados como tokens de saída. No conjunto avaliado pelo estudo, todos os fornecedores cobravam os tokens de raciocínio pela tarifa de saída.

Em sistemas com várias interações, a fórmula fica ainda mais extensa. É preciso contabilizar entradas novas, saídas, tokens de raciocínio, leituras e gravações de cache e o número de turnos executados. Cache de prompt é o mecanismo que reutiliza partes já processadas do contexto por um preço reduzido. Ele ajuda, mas não transforma históricos crescentes em consumo gratuito.

O que o estudo encontrou

Os pesquisadores avaliaram oito modelos de raciocínio em 12 conjuntos de tarefas: nove testes de turno único, envolvendo matemática, ciência, conhecimento, programação e chat, além de três ambientes com agentes capazes de usar ferramentas e interagir com sistemas ao longo de vários turnos. Entre os benchmarks estavam AIME, GPQA, LiveCodeBench, MMLU-Pro, GAIA, Cybench e Terminal-Bench 2.0.

Com oito modelos, existem 28 pares possíveis. Multiplicando-os pelas 12 tarefas, o estudo obteve 336 comparações. Em 106 delas - 32% - o modelo com menor preço listado produziu maior custo real. A maior inversão observada chegou a 28 vezes. (arXiv)

A Figura 1, na página 2 do anexo, deixa a inversão especialmente visível. O GPT-5.4 tinha preço listado de US$ 17,50 por milhão de tokens na métrica adotada pelo trabalho, contra US$ 3,50 do Gemini 3 Flash. Apesar disso, os gastos agregados do experimento foram de US$ 509 e US$ 705, respectivamente. Esses valores são o total daquela bateria de testes, não uma previsão universal para qualquer aplicação.

A ordem também mudou conforme a tarefa. A taxa de inversão foi de 11% no ArenaHard e chegou a 57% no MMLU-Pro. Em Cybench, um ambiente de segurança com várias interações, o Kimi K2.6 foi listado como 72% mais barato que o GPT-5.4, mas terminou com aproximadamente o dobro do custo. Nenhum modelo permaneceu universalmente como o mais barato ou o mais caro. Essa dependência do workload - o conjunto real de tarefas da aplicação - é a principal razão pela qual benchmarks genéricos não substituem testes internos.

"Overthinking": quando o modelo pensa demais

Em tarefas de turno único, o principal responsável pela inversão foi o volume de tokens de pensamento. O estudo chama esse comportamento de overthinking, ou raciocínio excessivo: o modelo executa uma deliberação muito maior do que a necessária para chegar à resposta.

Em um exemplo de MMLU-Pro, o Gemini 3 Flash consumiu mais de 60 mil tokens de pensamento, enquanto o GPT-5.4 utilizou apenas 25 para a mesma questão. O exemplo é extremo, mas ilustra por que uma diferença de cinco vezes no preço unitário pode desaparecer rapidamente.

A atribuição estatística do estudo indicou que, entre os pares com inversão em tarefas de turno único, mais de 95% da diferença de custo estava associada aos tokens de pensamento. Em outras palavras, nesses casos não era a tarifa que explicava a conta: era o comportamento de consumo do modelo. Isso não significa que raciocinar seja ruim. Computação adicional pode melhorar resultados difíceis. O problema aparece quando não há proporcionalidade entre o esforço utilizado e o valor produzido.

"Overacting": agentes que executam etapas demais

Em agentes de IA, o problema muda de forma. Um agente não entrega apenas uma resposta: ele planeja, chama ferramentas, lê resultados, corrige erros e tenta novamente. Cada ciclo é um turno de interação. O estudo encontrou casos em que um modelo precisou de sete turnos e outro de 57 para identificar o mesmo risco em um código. Em uma das comparações de Cybench, o número de turnos respondeu por mais de 80% da inversão de custo.

Há ainda um efeito acumulativo. Se cada nova chamada inclui a conversa anterior, o contexto cresce a cada turno. Com incrementos de tamanho semelhantes, o volume total reapresentado ao modelo se aproxima de:

1 + 2 + 3 + ⋯ + T = T(T + 1) / 2

Ou seja, o crescimento pode se aproximar de uma curva quadrática em relação ao número de turnos. A página 18 do anexo mostra que, nos agentes avaliados, o custo aumentou mais do que linearmente porque o histórico era reenviado sucessivamente. Cache, sumarização e truncamento podem reduzir esse impacto, mas precisam ser projetados e medidos.

Para assistentes de programação, isso é particularmente relevante. Ler arquivos, executar testes, interpretar erros e editar novamente são ações úteis, mas um agente que entra em loop pode consumir muito mais do que outro que encontra rapidamente a causa do problema.

O valor de Shapley como ferramenta de diagnóstico

Para explicar a diferença entre dois modelos, os autores aplicaram o valor de Shapley, uma técnica da teoria dos jogos cooperativos. Em termos simples, ela estima quanto cada fator contribui para um resultado ao avaliar sua participação em diferentes combinações possíveis. É como investigar uma conta alta separando o efeito da tarifa, do volume utilizado e do número de viagens. A técnica evita atribuir toda a culpa ao último fator observado quando vários elementos interagem.

O trabalho separou oito componentes: total de turnos; médias de tokens novos de entrada, saída, cache e pensamento por turno; e os preços de entrada, saída e cache. A soma das contribuições explica integralmente a diferença de custo entre os sistemas comparados.

Na prática, uma empresa não precisa implementar imediatamente toda a matemática de Shapley. O insight operacional é mais direto: registre separadamente preço, tokens de cada categoria, cache, turnos e tentativas. Sem essa decomposição, a fatura informa quanto foi gasto, mas não explica por quê.

O custo é uma distribuição, não um número fixo

Mesmo depois de selecionar o modelo e congelar o prompt, o custo não fica completamente estável. Modelos generativos podem seguir caminhos de raciocínio diferentes em execuções repetidas. No estudo, o custo realizado para o mesmo par de modelo e consulta variou até 9,7 vezes entre execuções. A Figura 5, nas páginas 7 e 8, mostra distribuições longas e irregulares tanto em matemática quanto em tarefas com agentes.

Isso torna a média insuficiente para planejamento financeiro. Um produto precisa observar também percentis:

• p50: custo mediano, representando uma execução típica
• p90 ou p95: patamar que cobre a maior parte das solicitações
• p99: cauda extrema, relevante para limites de segurança e proteção de margem

No próprio estudo, a taxa média de inversão ficou próxima de 32%, mas atingiu 39,6% no quantil 40. O modelo aparentemente mais barato pode, portanto, perder a vantagem em diferentes regiões da distribuição de consumo.

Para um SaaS com cobrança mensal fixa, isso afeta diretamente o COGS, ou custo dos serviços vendidos. Usuários que acionam consultas difíceis, grandes repositórios ou longos ciclos de ferramentas podem consumir mais receita do que geram, mesmo que o custo médio inicial pareça saudável. Essa preocupação também aparece explicitamente na discussão do Reddit. (Reddit)

Custo sozinho também não escolhe o melhor modelo

O estudo mede gastos, mas não incorpora qualidade ao ranking principal. Além disso, utiliza um único nível de esforço de raciocínio por modelo e uma fotografia de preços registrada em 1º de maio de 2026. Os próprios autores reconhecem que mudanças de tarifa, configuração e qualidade podem alterar os resultados específicos.

A métrica mais útil para produção não é apenas custo por chamada, mas custo por resultado bem-sucedido:

Custo por sucesso = Custo total das execuções / Número de tarefas concluídas corretamente

Um modelo barato que falha e exige nova tentativa pode ser mais caro que um modelo premium que resolve o problema de primeira. Por outro lado, usar sempre o modelo mais sofisticado em tarefas triviais também desperdiça recursos. A consequência natural é o model routing: direcionar cada solicitação ao modelo mais adequado à sua dificuldade, escalando para opções mais fortes quando necessário. O Reddit aponta exatamente esse dilema entre usar modelos fracos para problemas complexos e modelos caros para trabalhos simples. (Reddit)

Como aplicar isso na prática

• Construa um conjunto representativo de tarefas. Separe consultas simples, médias e difíceis, além de fluxos de turno único e agentes com ferramentas. Não use somente benchmarks públicos.
• Execute os candidatos repetidamente. Mantenha prompts, ferramentas, limites e ambiente equivalentes. Uma única execução não revela a variabilidade observada pelo estudo.
• Registre telemetria por solicitação. Inclua versão do modelo, tokens de entrada, saída e raciocínio, leituras e gravações de cache, turnos, chamadas de ferramentas, novas tentativas, latência, custo e sucesso.
• Compare distribuições e resultados. Analise custo médio, mediana, p90, p95, taxa de sucesso e custo por tarefa concluída. Evite selecionar modelos somente por US$/milhão de tokens.
• Imponha limites arquiteturais. Defina orçamento de tokens, máximo de turnos, detecção de loops, sumarização de histórico, interrupção antecipada e escalonamento para outro modelo. Teste o impacto desses controles na qualidade.
• Reavalie periodicamente. Preços, versões, políticas de cache e comportamento dos modelos mudam. Um roteamento eficiente hoje pode deixar de ser eficiente após uma atualização.

Conclusão

O preço listado continua sendo útil, mas é apenas um multiplicador. O custo real nasce da combinação entre tarifa e comportamento: quanto o modelo pensa, quantas ações executa, quanto contexto reapresenta e quantas tentativas precisa fazer. O estudo mostra que essa diferença não é marginal. Na versão atualizada, quase um terço das comparações apresentou inversão de preço, com casos extremos de até 28 vezes.

Em tarefas simples, o vilão costuma ser o excesso de tokens de pensamento. Em agentes, são os turnos adicionais e o crescimento do histórico. E, mesmo mantendo modelo e prompt fixos, a conta ainda pode variar significativamente.

A decisão economicamente correta, portanto, não é escolher "o modelo mais barato". É escolher o modelo com melhor custo por resultado no seu workload, observando também qualidade, latência e risco de cauda.

Referências

• The Price Reversal Phenomenon: When Cheaper Reasoning Models Cost More - Lingjiao Chen, Chi Zhang, Yeye He, Ion Stoica, Matei Zaharia e James Zou. Versão 2, arXiv, revisada em 28 de maio de 2026. Fonte principal para metodologia, resultados, atribuição de custos e limitações. (arXiv)
• The Price Reversal Phenomenon - versão 1 - Resumo original publicado em março de 2026. Usado para identificar a origem dos números "78% mais barato" e "22% mais caro" reproduzidos no Reddit. (arXiv)
• A model listed 78% cheaper cost 22% more to actually run. Unit price isn't your bill - Discussão na comunidade r/cursor. Usada como contexto sobre COGS, seleção de modelos, monitoramento e roteamento em aplicações reais. (Reddit)