Na Tech86, já vimos empresas queimando seis dígitos por mês em modelos premium para tarefas que um modelo 42x mais barato resolve igual. O problema não é o modelo — é a ausência de critério econômico na seleção. Model selection é unit economics, não fanboyismo.
Os números que o mercado ignora
O SWE-bench é o benchmark de referência para capacidade de código. E os números recentes são reveladores. O MiniMax M2.5 entrega 80.2% por US$ 0,99 por milhão de tokens de saída. O Claude Opus 4.6 entrega 80.8% por US$ 25 por milhão. A diferença de performance é 0,6%. A diferença de preço é 42x.
Na entrada, o gap é igualmente brutal: US$ 0,118/M no MiniMax contra US$ 5/M no Opus. O MiniMax ainda oferece janela de contexto de 1M tokens contra 200K do Opus. E é open-source.
Esses números não são teóricos. São os preços publicados, os benchmarks rodados, as especificações declaradas. Quando colocamos no Excel, a conclusão é inevitável: para a maioria dos workloads de código, pagar premium é capital mal alocado.
O que o benchmark não te conta
O SWE-bench mede uma coisa: capacidade de resolver issues de repositórios open-source. É útil como referência, mas não representa o que acontece em produção. O que o MiniMax não te conta: quantos tokens de reasoning ele queima por task? Qual a latência real em código complexo? O modelo consegue manter contexto de 1M tokens sem degradação? A qualidade do código gerado é comparável ou é "syntax correct, logic broken"?
Na nossa experiência, benchmarks são o ponto de partida, nunca o veredito. Já vimos modelos com SWE-bench alto que geram código sintaticamente correto mas logicamente quebrado. Já vimos modelos com benchmark menor que entregam código mais robusto porque foram treinados em datasets mais alinhados com o domínio do cliente.
O SWE-bench não mede robustez do código, edge cases tratados, arquitetura da solução ou legibilidade e manutenibilidade. Essas são as métricas que importam em produção. E só dá para avaliá-las testando no seu workload real.
O desperdício silencioso: Opus para CRUD
Se você está rodando Opus 4.6 para gerar código commodity — CRUDs, APIs simples, scripts de automação, extração de dados — está pagando premium por algo que um modelo 42x mais barato faz igual ou melhor. Essa é a realidade que ninguém quer admitir.
Já auditamos operações de IA onde 80% das requisições eram tasks commodity rodando em modelos premium. O custo mensal era 5x maior do que precisava ser. E a qualidade não melhorava — porque para CRUD e boilerplate, qualquer modelo com 75%+ no SWE-bench entrega o mesmo resultado.
Agora, se você precisa de reasoning profundo sobre arquitetura, context window massivo para monorepos, agentic behavior com tool calling complexo, ou safety e alignment de nível enterprise — o Opus ainda pode justificar o custo. A questão é: quantas das suas requisições realmente precisam disso?
O custo real por task (e por que ninguém calcula)
O preço por milhão de tokens é só a superfície. O custo real de uma task inclui tokens de entrada, tokens de saída e tokens de reasoning. Um modelo que custa 42x menos por token mas queima 3x mais tokens de reasoning pode não ser tão barato quanto parece.
Na prática, descobrimos que o cálculo é mais sutil. Modelos premium tendem a ser mais eficientes em reasoning — chegam na resposta com menos tokens intermediários. Modelos mais baratos podem compensar o preço menor com mais tokens de raciocínio. O custo por task completa é o que importa, não o preço por token.
Nosso processo: rodamos o mesmo workload em múltiplos modelos, medimos tokens totais consumidos (input + reasoning + output), multiplicamos pelo preço, e comparamos o custo por task. Em 7 de cada 10 casos de uso de código, o modelo mais barato vence mesmo considerando o overhead de reasoning.
Model routing: a arquitetura que separa amador de profissional
Model routing é a prática de direcionar cada requisição para o modelo mais adequado baseado na complexidade da task. Tasks simples vão para modelos de alto throughput e baixo custo. Tasks complexas vão para modelos premium. É a mesma lógica de usar sedan para o trajeto diário e caminhão para mudança.
Na Tech86, implementamos model routing baseado em classificação de complexidade. O sistema analisa o prompt, classifica a task entre commodity e complexa, e direciona para o modelo correto. O resultado: redução de 60-70% no custo de inferência sem perda de qualidade nos outputs finais.
O mercado está reclassificando o que é "frontier". Não é mais definido por quem tem o maior benchmark. É definido por quem entrega mais throughput por dólar. E model routing é a ferramenta que transforma essa reclassificação em economia real.
FinOps para IA não é opcional
Se seu caso de uso roda em 80% do que o modelo oferece, pagar 42x a mais é desperdício de capital. Ponto. Não existe argumento de "brand" ou "confiança" que justifique queimar orçamento de infra em modelos oversized.
FinOps para IA é o processo de garantir que cada dólar gasto em inferência gere valor proporcional. Isso significa mapear casos de uso, medir custo por task, implementar model routing e revisar continuamente. O mercado de LLMs muda a cada semana — o modelo que era premium mês passado pode ser commodity hoje.
Na Tech86, desenhamos arquiteturas de IA com model routing baseado em complexidade e custo real. Se você está rodando o modelo mais caro porque "sempre foi assim", está na hora de recalcular. Consultoria FinOps para IA não é custo — é ROI.
