Um benchmark lançado em 12 de setembro de 2026 que avalia modelos em bases de código corporativas reais e privadas, em vez de repositórios públicos. Ele somou 275 pontos e 158 comentários no Hacker News.

Por que o custo por issue resolvida é melhor que a taxa de acerto?

A taxa de acerto ignora o consumo de tokens e o número de tentativas. Dois modelos separados por poucos pontos podem diferir em 3x no custo por issue resolvida quando se contam novas tentativas, revisões do plano e diffs rejeitados.

Como calculo internamente o custo por issue resolvida?

Gasto total atribuível ao trabalho agêntico, dividido pelos PRs mesclados para os quais o agente contribuiu de forma material. Acompanhe separadamente o multiplicador de novas tentativas e os minutos de revisão humana, pois ambos são custos reais.

Modelos de pesos abertos têm vantagem em bases de código privadas?

Eles partem de um prior de repositório local que os modelos de API hospedados não têm. Neste mês, um modelo de 27B com pesos abertos foi relatado no nível do Fable 5 por um preço cerca de 40x menor, que é o padrão a observar.

Custo do Real-SWE por issue resolvida

Atualizado September 27, 2026 · publicado originalmente September 27, 2026

O Real-SWE foi lançado em 12 de setembro de 2026 e somou 275 pontos e 158 comentários no Hacker News. A premissa é justamente o que a maioria dos modelos de custos erra: as suítes de benchmark são públicas, memorizadas e pouco representativas do código que seus agentes realmente tocam. O Real-SWE executa os modelos contra repositórios corporativos reais e privados.

Por que o número de custo importa mais que a pontuação

Um benchmark público dá uma taxa de acerto. Não dá um custo. O custo por issue resolvida exige três coisas ao mesmo tempo:

Taxa de acerto nas tarefas difíceis e privadas.
Tokens consumidos por tentativa, incluindo as falhas.
Número de tentativas — o modelo precisou de uma nova tentativa, de uma revisão do plano, de um ciclo de comparar o diff e repensar?

Multiplique os três e você obtém o único número que corresponde a uma linha do orçamento. Um modelo que pontua 4 pontos abaixo do líder, mas resolve as issues em uma tentativa e com um terço dos tokens, sai mais barato por issue resolvida, e num backlog real essa diferença se acumula mais rápido do que a lacuna de pontuação sugere.

Por que os benchmarks públicos superestimam a qualidade

Bases de código corporativas têm as propriedades que quebram as premissas dos benchmarks públicos: longas convenções internas, invariantes sem documentação, testes que registram acidentes históricos e sistemas de build que ninguém entende por completo. Um modelo que reconhece padrões em um repositório público não consegue fazer isso num monorepo de 400 arquivos com três anos de decisões acumuladas. Por isso, um resultado muito comentado neste mês foi o de um modelo de escrita criativa de 27B com pesos abertos que opera no nível do Fable 5 por um preço, segundo relatos, 40x menor — pesos abertos partem de um prior de repositório local que os modelos de API não têm.

Fazendo a conta

Pegue um repositório de backend real com 40 issues no escopo. Digamos que o modelo mais barato resolva 22 em uma tentativa com 60K de entrada / 8K de saída, e o modelo premium resolva 26 com um multiplicador de novas tentativas de 1.4x e 90K de entrada / 14K de saída. Com as tarifas do Opus 5.5 ($4/$20, leituras de cache $0.20):

Modelo	Resolvidas	Custo por issue	Total
Faixa econômica	22	$0.32	$7.04
Faixa premium	26	$0.61	$15.86

O premium custa 2.3x o total para 18% mais issues resolvidas. Num backlog de 40 issues, são $9 a mais. A mesma troca com 4,000 issues por mês dá $880 — e continua comprando apenas 18% a mais de vazão. A faixa econômica não está obviamente errada; você troca taxa de resolução por volume, e a resposta certa depende de uma issue não resolvida custar mais de um dólar.

O que instrumentar

Custo por issue resolvida, não por tentativa. O denominador são os PRs mesclados, não as requisições.
Multiplicador de novas tentativas por modelo. Um modelo a 1.4x equivale a um terço do seu preço de tabela antes de você contar qualquer outra coisa.
Tokens por diff aceito, incluindo os tokens de plano e de autorrevisão que o diff nunca mostra.
Minutos de revisão humana. Um modelo 12% mais barato que leva 20% mais tempo para revisar sai mais caro.

Conclusão

Os benchmarks públicos ranqueiam capacidade em tarefas que não se parecem com o seu backlog. O Real-SWE é uma tentativa inicial da versão honesta. Até você executá-lo nos seus próprios repositórios, trate toda comparação de modelos como uma hipótese de custo por issue resolvida e precifique essa hipótese com as suas próprias contagens de tokens.