Pular para o conteúdo principal

MiniMax M2.5: Benchmarks de Codificação

Lucas Mendonça
Lucas MendonçaDev Full-Stack & Freelancer
Compartilhar

MiniMax M2.5: Benchmarks de Codificação

Acompanhei essa briga se montar por semanas. Em 12 de fevereiro de 2026 — pouco mais de um mês depois do IPO da MiniMax em Hong Kong — eles soltaram o M2.5, e meu Slack acendeu na hora com a mesma mensagem de cinco engenheiros diferentes: "Você viu esses números?"

A coisa que realmente me pegou: o MiniMax M2.5 marca 80,2% no SWE-Bench Verified. O Claude Opus 4.6, lançado uma semana antes, em 5 de fevereiro, tá em 80,8%. Isso é uma diferença de 0,6 ponto percentual entre um modelo que custa em torno de $0,15/M token de input e outro que custa $5/M token de input. Rodei os dois em cenário de produção real na última semana, e esse artigo é o que eu encontrei na prática — não só o que o benchmark diz.

Se você é dev, tech lead ou engineering manager tentando descobrir como rotear tarefa de codificação em 2026, essa é a comparação que você precisa ler.

Pra Que Essa Comparação Serve, na Real — Para de Discutir, Começa a Entregar

Olha, atuo em engenharia de software faz mais de uma década, e nunca vi debate de benchmark torrar mais hora de dev que a discussão "qual modelo é melhor". A pergunta certa não é qual modelo ganha — é qual modelo deve cuidar de qual tarefa no seu stack, e por qual custo.

Essa comparação não é pra fim acadêmico. É montada em torno de um problema de decisão específico: você tá construindo ou rodando um workflow de desenvolvimento assistido por IA, tem acesso aos dois modelos, e precisa de uma estratégia de roteamento.

Os modelos que tô comparando:

  • MiniMax M2.5 — Lançado em 12 de fevereiro de 2026. Um modelo Mixture-of-Experts de 230B parâmetros que ativa só 10B parâmetros por forward pass. Treinado em mais de 200.000 ambientes reais de RL, open source no Hugging Face.
  • Claude Opus 4.6 — Lançado em 5 de fevereiro de 2026. O modelo mais capaz da Anthropic, com Adaptive Thinking, janela de contexto de 1M token (em beta) e performance líder de mercado no Terminal-Bench 2.0.

Os dois estão prontos pra produção. Os dois são realmente bons. Mas não são intercambiáveis.

MiniMax M2.5: Benchmarks de Codificação

Snapshot dos Benchmarks (verificado em fev/2026)

Snapshot dos Benchmarks (verificado em fev/2026)

Deixa eu juntar os números de forma limpa. Todos os valores abaixo vêm de release oficial dos modelos e avaliação de terceiro verificada em fevereiro de 2026.

BenchmarkMiniMax M2.5Claude Opus 4.6Vantagem
SWE-Bench Verified80,20%80,80%Opus 4.6 (+0,6%)
Multi-SWE-Bench (multilíngue)51,30%50,30%M2.5 (+1%)
BFCL Multi-Turn (tool calling)76,80%63,30%M2.5 (+13,5%)
Terminal-Bench 2.052%65,40%Opus 4.6 (+13,4%)
BrowseComp76,30%~75%Praticamente empate
AIME 2025 (raciocínio matemático)45%~95%+Opus 4.6 (significativo)
HumanEval (Python)95%Opus 4.6

Fontes: anúncio oficial da MiniMax, página oficial da Anthropic, SWE-bench Results Viewer, Artificial Analysis.

SWE-Bench + O Que o Gap de 0,6% Significa de Verdade em Produção

Aqui eu preciso pisar no freio na manchete. O SWE-Bench Verified testa resolução autônoma de issue real do GitHub em repositório Python — é o melhor benchmark único que a gente tem pra agente de codificação. E sim, 80,2% vs 80,8% é estatisticamente próximo.

Mas o tipo de tarefa que cada modelo cuida melhor importa muito. Os gaps que observei na prática foram maiores do que 0,6% sugere:

  • Multi-SWE-Bench testa projeto multilíngue com vários arquivos — o M2.5 na real lidera aqui, com 51,3% vs 50,3%. Pra trabalho em Go, Rust, TypeScript e Java, esse é o benchmark mais relevante.
  • BFCL Multi-Turn é o que pulou pra mim. Uma vantagem de 13,5 ponto percentual pro M2.5 em tool calling multi-turn sustentado significa que ele perde contexto bem menos em loop agêntico longo. Num workflow multi-agente da Verdent onde você roda um agent de refactor por mais de 40 tool calls, essa diferença é enorme.
  • Terminal-Bench 2.0 conta a história oposta. O 65,4% do Opus 4.6 vs 52% do M2.5 reflete um gap real em operação autônoma de terminal, debug em vários passos e tarefa em nível de SO. Se seu agente precisa navegar filesystem, rodar suíte de teste de forma iterativa ou debugar no shell, o Opus 4.6 justifica o preço premium.

Resumindo: os 0,6% no SWE-Bench escondem um perfil de performance bifurcado. M2.5 domina loop de tool calling; Opus 4.6 domina terminal e tarefa pesada de raciocínio.

Resultados do Nosso Teste por Tarefa

Rodei os dois modelos por um conjunto de tarefa real ao longo de 7 dias — não problema de brinquedo, mas trabalho representativo de tipo de projeto real: refactor de uma API multi-serviço, suíte de validação de business logic, trabalho de nicho em Rust e migração de uma component library de TypeScript.

M2.5 Vence — Refactor Multi-Arquivo, Loop de Tool Calling Sustentado

Tarefa: migrar uma API Express.js de 14 arquivos de callbacks pra async/await, com atualização completa da suíte de teste

O comportamento nativo de "spec-writing" do M2.5 — onde ele planeja a arquitetura antes de tocar no código — fez diferença real aqui. Antes de escrever uma linha, ele produziu um plano de migração estruturado cobrindo dependência entre arquivo, padrão de callback compartilhado e área de impacto nos testes. O output final precisou de cerca de 20% menos revisão manual que a tentativa equivalente do Opus 4.6.

A vantagem do BFCL multi-turn apareceu clara no loop de tool calling. O M2.5 manteve contexto preciso ao longo de 47 tool calls consecutivas. O Opus 4.6 mostrou drift de contexto na chamada 28, exigindo uma injeção manual pra voltar pro trilho.

# Exemplo: padrão de tool calling paralelo do M2.5 no Verdent Agent Mode
# O M2.5 rodou essas três tool calls em paralelo sem perder contexto:
# 1. Lê src/routes/users.js → analisa cadeia de callback
# 2. Lê src/middleware/auth.js → identifica dependência de callback
# 3. Lê tests/users.test.js → mapeia cobertura de teste pros callbacks
# Total de rodadas necessárias: 6
# Equivalente Opus 4.6: 9 rodadas (drift de contexto na rodada 5)

Outras vitórias do M2.5 no nosso teste:

  • Refactor multilíngue (TypeScript + Go na mesma sessão)
  • Sessão longa do Verdent Agent (mais de 30 tool calls)
  • Implementação de trait em Rust com lifetime complexo (vantagem do treinamento multilíngue)
  • Processamento em batch otimizado em custo pra tarefa de code review

Opus 4.6 Vence — Business Logic Capciosa, Edge Case de Linguagem de Nicho

Tarefa: implementar um motor de arredondamento multi-moeda com regra de compliance regulatório pra 6 jurisdições

Esse é exatamente o tipo de tarefa onde o gap do Opus 4.6 em raciocínio e precisão de planejamento aparece. A business logic era ambígua em três pontos onde jurisdições diferentes se contradizem. O Opus 4.6 sinalizou as três contradições de forma proativa e pediu esclarecimento antes de seguir. O M2.5 fez assumption em duas — uma estava certa, a outra não.

Pra tarefa que toca lógica regulatória, cálculo financeiro ou exige raciocínio profundo de domínio, o Adaptive Thinking e o score mais alto no AIME do Opus 4.6 representam valor real em produção.

Outras vitórias do Opus 4.6 no nosso teste:

  • Sessão de debug autônomo que exigia operação no shell (o gap do Terminal-Bench é real)
  • Edge case obscuro de linguagem no módulo typing do Python, metaprogramação de template em C++
  • Tarefa que exige mais de 200K token de contexto com coerência total
  • Design de arquitetura nova onde o raciocínio por primeiros princípios importa

Realidade do Custo — Como Sua Fatura Mensal Fica de Verdade

Vou ser direto sobre os números, porque é aqui que a decisão geralmente termina.

MiniMax M2.5 StandardMiniMax M2.5 LightningClaude Opus 4.6 Standard
Input (por 1M token)$0,15$0,30$5,00
Output (por 1M token)$1,20$2,40$25,00
Velocidade50 TPS100 TPS~40 TPS (est.)
Custo médio por tarefa SWE-Bench~$0,15~$0,30~$3,00

Pricing do anúncio oficial da MiniMax e da página de pricing da API da Anthropic, fevereiro de 2026.

A conta que importa pra time rodando agente de codificação em escala:

Cenário: 100 tarefas de code review/dia, ~1M token de output no total

  • M2.5 Standard: ~$1,20/dia → $36/mês
  • Opus 4.6 Standard: ~$25,00/dia → $750/mês

Isso é 20× de diferença de custo em token de output. Pra um time de engenharia de porte médio rodando agente diariamente, rotear até 70% das tarefas pro M2.5 gera economia relevante com qualidade de output praticamente equivalente na maioria dos tipos de tarefa.

Duas alavancas de custo do Opus 4.6 que vale conhecer: a Batch API dá 50% de desconto, e o prompt caching derruba o input pra $0,50/M token (90% de economia). Se você tem system prompt repetido ou workflow pesado em documento, empilha as duas. Mas mesmo com cache, o M2.5 continua significativamente mais barato pra workload agêntico pesado em output.

Matriz de Decisão + Como a Verdent Roteia em Produção

Depois de uma semana de teste em mundo real, esse é o framework de roteamento que eu implementaria de verdade. Na Verdent, a gente roteia entre modelos com base em tipo de tarefa, nível de risco e tolerância a custo — não em assumption de "modelo único melhor".

Tipo de tarefaModelo recomendadoMotivo
Refactor multi-arquivo (3+ arquivos)M2.5Comportamento de spec-writing, vantagem no Multi-SWE-Bench, custo menor
Loop agêntico longo (25+ tool calls)M2.5Liderança no BFCL multi-turn (76,8% vs 63,3%)
Projeto multilíngue (Go/Rust/Java)M2.5Treinado em 10+ linguagens, #1 no Multi-SWE-Bench
Code review em batch de alto volumeM2.5Eficiência de custo; output 20× mais barato
Tarefa autônoma de terminal/shellOpus 4.6Terminal-Bench 2.0: 65,4% vs 52%
Business logic complexa / complianceOpus 4.6Profundidade de raciocínio, Adaptive Thinking
Codebase grande com 200K+ token de contextoOpus 4.6Janela de 1M token + coerência
Design de arquitetura novaOpus 4.6Vantagem em raciocínio por primeiros princípios
Script Python rápido / protótipoQualquer umParidade de performance no HumanEval
Código de produção de alto risco e baixo volumeOpus 4.6Vale o premium pelo gap de raciocínio

A lógica de roteamento em português claro:

Usa o M2.5 como modelo padrão de agent pra trabalho de codificação iterativo, pesado em tool e multi-arquivo. Roteia pro Opus 4.6 quando a tarefa exige raciocínio profundo, navegação autônoma de terminal, ou quando um erro tem consequência significativa lá na frente.

Isso não é uma hierarquia permanente — é um trade-off custo-risco. Os 0,6% de gap no SWE-Bench não definem qual modelo é "melhor". Eles te dizem que os dois estão próximos o suficiente pra que tipo de tarefa e custo dirijam o roteamento, não prestígio do modelo.

Uma nota rápida sobre a implementação da Verdent: na arquitetura multi-agente da Verdent, o agent do Plan Mode decide o roteamento com base na classificação da tarefa. O isolamento via Git Worktree faz cada agente — seja rodando M2.5 ou Opus 4.6 — trabalhar em ambiente sandboxed, então decisão de roteamento não cria conflito de código. Se você tá implementando algo parecido, essa camada de isolamento importa mais que a escolha de modelo pra manter a segurança do código.

FAQ

P: O MiniMax M2.5 é open source de verdade? R: Sim — a MiniMax liberou os weights publicamente. O model card do MiniMax M2.5 e os weights estão disponíveis no Hugging Face, com suporte a vLLM e SGLang pra self-hosting. Vale notar que com 230B de parâmetro total, o self-hosting exige hardware sério mesmo com a pegada de 10B parâmetro ativo do MoE.

P: Qual modelo eu uso pra projeto greenfield, do zero? R: Pra design de sistema 0-pra-1, eu iria de Opus 4.6. A profundidade de raciocínio e o Adaptive Thinking dão vantagem quando a arquitetura ainda não tá definida. Quando você tá em desenvolvimento de feature 1-pra-N com codebase já estabelecido, o M2.5 fica competitivo ou melhor.

P: O gap do BFCL multi-turn importa pra mim? R: Importa se seu agente roda mais de ~20 tool calls consecutivas numa sessão. Abaixo desse limiar, os dois modelos mantêm contexto bem. Acima dele — principalmente em refactor que atravessa muitos arquivos — os 76,8% vs 63,3% do M2.5 no Berkeley Function Calling Leaderboard multi-turn benchmark se traduzem em menos falha por drift de contexto.

P: E o Claude Sonnet 4.6 como alternativa? R: Vale a menção. O Sonnet 4.6 marca 79,6% no SWE-Bench Verified a $3/$15 por milhão de token — mais perto do preço do M2.5 e quase no score do Opus 4.6. Pra stack nativo Anthropic, o Sonnet 4.6 é o meio-termo pragmático.

P: Como os 37% de conclusão de tarefa mais rápida do M2.5 afetam o custo na real? R: Boa pergunta. Como o M2.5 também consome um pouco menos de token por tarefa (3,52M vs média de 3,72M do M2.1 no SWE-Bench), a vantagem de custo se acumula — você paga menos por token e usa menos token por tarefa. Em operação contínua, a MiniMax precifica o M2.5 Lightning a $1/hora a 100 TPS. É um jeito incomum de pensar pricing de modelo, mas útil pra sessão de agent longa.

Qual é a Linha de Fundo?

Para de debater modelo. Começa a rotear tarefa.

A decisão MiniMax M2.5 vs Claude Opus 4.6 não é binária. É um problema de roteamento: M2.5 pra trabalho iterativo, multi-arquivo, pesado em tool, em escala; Opus 4.6 pra tarefa que exige raciocínio intenso, pesada em terminal ou de alto risco, onde o premium de custo te compra precisão real.

Usa a matriz de decisão acima pra rotear suas tarefas de codificação por tipo de tarefa, nível de risco e custo. Se você tá rodando um stack multi-agente estilo Verdent, implementa o roteamento de modelo na camada de plan, pra que agente individual não herde uma assumption de "modelo único pra tudo". Essa decisão arquitetural sozinha faz mais pela qualidade de output do seu time e pelo custo de infra do que qualquer escolha de modelo único.

Fontes de dado: release oficial da MiniMax (12 fev 2026), página oficial do modelo da Anthropic (5 fev 2026), docs de pricing da API Anthropic (fev 2026), SWE-bench Results Viewer (17 fev 2026), dado de benchmark da Artificial Analysis, análise do M2.5 no HuggingFace (fev 2026).

Artigos relacionados

Claude AI: Acesso Gratuito 2026

Windsurf: Preços e Planos 2026

Claude Code: Preços Reais 2026

Nemotron 3 Super vs Qwen 3: Coding AI

Lucas Mendonça
Escrito porLucas MendonçaDev Full-Stack & Freelancer

Oi, aqui é o Lucas! Sou dev full-stack freelancer com experiência em construir MVPs e ferramentas internas pra startups. Comecei a escrever quando três clientes me fizeram a mesma pergunta no mesmo mês: "qual ferramenta de IA vale a pena?" — resolvi testar em projetos reais e documentar o que aprendi. Escrevo sobre o que funciona de verdade quando o deadline está chegando.