MiniMax‑M2.5: Codificação Agentic 'Ilimitada' a $1/hora? Aqui está o que levar a sério

O MiniMax acaba de publicar um post de lançamento para o MiniMax‑M2.5 (12 de fevereiro de 2026) e eles estão chegando com tudo: codificação agentic + uso de ferramentas, grandes números de benchmark e uma mensagem muito direta sobre preços — execute agentes semelhantes a fronteira sem se preocupar com o custo.

Fonte (primária): https://www.minimaxi.com/news/minimax-m25

O que o MiniMax está afirmando

Do anúncio:

• SWE‑bench Verificado: 80.2%
• BrowseComp: 76.3%
• Multi‑SWE‑bench: 51.3%

Execuções longas mais rápidas: eles afirmam ser ~37% mais rápidos que o M2.1 no SWE‑bench Verificado de ponta a ponta.

Duas versões com qualidade semelhante, mas diferentes em velocidade/preço:

• Versão de ~100 tokens/segundo: eles a enquadram como “$1 por uma hora de trabalho contínuo” a 100 TPS
• Versão de ~50 tokens/segundo: ainda mais barata (eles citam $0.3/hora)

Eles também estão posicionando como um agente de codificação “semelhante a arquiteto”: planejamento antes da codificação, decomposição em estilo de especificação, cobertura de múltiplas linguagens e operação em ambientes reais (não apenas demonstrações front-end de brinquedo).

Por que isso importa (mesmo se você ignorar o hype)

A parte mais interessante não é apenas o destaque dos benchmarks — é a tese do produto:

1. Custo do agente se tornando uma característica de primeira classe. Se você pode executar agentes por horas (retries, chamadas de ferramentas, navegação, busca de código) sem olhar para o medidor, isso muda o que as equipes estão dispostas a automatizar.
2. Velocidade + eficiência de tokens é a verdadeira chave para trabalhos de longo prazo. Um modelo que pode resolver a mesma tarefa com menos etapas e menos “pensamento desnecessário” é efetivamente mais capaz em produção, mesmo que o QI bruto seja semelhante.
3. A competição está mudando de “melhor modelo” para “melhor sistema de agente”. O MiniMax fala explicitamente sobre andaimes, chamadas de ferramentas, busca e treinamento de RL em ambientes reais. Essa é a mesma direção que estamos vendo em todos os lugares: a confiabilidade vem dos sistemas ao redor do modelo.

Como eu checaria a sanidade do M2.5 (antes de mudar qualquer coisa)

Se você está tentado a experimentá-lo para trabalhos estilo BuildrLab (Next.js + serverless + AWS), aqui está o que eu testaria primeiro:

• Comportamento primeiro em especificação: ele propõe consistentemente um plano, casos extremos e uma estratégia de teste antes de escrever código?
• Qualidade de patch em repositórios bagunçados: não demonstrações em campo limpo — um repositório com convenções existentes, regras de lint, pipelines CI.
• Disciplina de ferramentas: ele usa ferramentas de forma intencional ou apenas as spama?
• Custo real do “tempo de execução do agente”: tarefas reais com retries, etapas de navegador e falhas — não apenas conclusão de código em uma única tentativa.

Considerações do BuildrLab

Se o MiniMax‑M2.5 estiver perto dessas afirmações, a implicação óbvia para os negócios é: fluxos de trabalho de agentes de alto volume se tornam mais baratos de executar → mais automação se torna economicamente viável. O diferencial para uma consultoria ou loja de produtos se desloca ainda mais para processos + andaimes + guardrails, não seleção de modelos. É exatamente por isso que tenho prestado atenção em coisas como WebMCP e ferramentas de RL abertas: a confiabilidade do agente está se tornando um jogo de padrões + infraestrutura.

Se você quiser que eu publique isso como um post no blog do BuildrLab, eu o criarei como um rascunho primeiro e você pode responder com: implantar site / implantar dev.to / implantar ambos.