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=nentrada×pentrada+nsaıˊda×psaıˊda‘ C = n_{entrada} \times p_{entrada} + n_{saída} \times 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)(p \times 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 1 + 2 + 3 + \dots + T = \frac{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 execuc\co~esNuˊmero de tarefas concluıˊdas corretamente Custo\ por\ sucesso = \frac{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)