MiMo-V2.6: qual modelo da família escolher para cada tarefa?

Fala aí, beleza? A Xiaomi soltou a série MiMo-V2.6 e a notícia que quase ninguém está contando é essa: não veio um modelo, veio uma família inteira, com três nomes na API e pesos abertos publicados no Hugging Face

Ou seja, a sua decisão não é "vou usar ou não vou usar"

A sua decisão é "qual dos três, em qual parte do meu projeto, e quanto me custa errar essa escolha"

E isso muda bem mais coisa no seu código do que parece =)

O que a Xiaomi anunciou na série MiMo-V2.6

O anúncio saiu em 22 de setembro de 2026, com a Xiaomi abrindo o código dos modelos depois de escalar treino por aprendizado por reforço, segundo o TechNode

Na API, a família tem três nomes: MiMo-V2.6-Pro, MiMo-V2.6-Flash e MiMo-V2.6-Pro-UltraSpeed

Nos pesos, a organização XiaomiMiMo publicou MiMo-V2.6-Pro-RL, MiMo-V2.6-Flash-RL e o MiMo-V2.6-Distill-Qwen-9B no Hugging Face, tudo sob licença MIT

E junto veio uma coisa que vale mais do que o release em si pra quem trabalha com treino: mais de 7.000 ambientes de RL e ferramentas, também sob MIT

No Artificial Analysis, o MiMo-V2.6-Pro marca 46 no Intelligence Index e aparece como o modelo de pesos abertos mais bem colocado do índice, à frente de GLM-5.3 (45) e Kimi K3 (44)

A mesma página mede 130 tokens por segundo pro Pro, com preço de US$ 0,435 por 1M de entrada e US$ 0,87 por 1M de saída

Massa. Agora vem a parte chata, que é escolher

Pro, Flash e UltraSpeed: a tabela lado a lado

Repara no que a tabela NÃO diz

O UltraSpeed é descrito pela Xiaomi como a performance do V2.6-Pro com velocidade de saída até 20x maior, voltado a cenários de baixa latência, e é isso que dá pra afirmar com fonte

E repara no detalhe mais importante da tabela: Pro e Flash empatam em contexto e em saída máxima

Os dois vão a 1.048.576 tokens de janela e 131.072 de saída

Então esquece aquele critério preguiçoso de "pego o maior porque preciso de contexto grande"

Contexto aqui NÃO é desempate. O desempate é capacidade por tarefa e preço

Adotar uma família é diferente de adotar um modelo

Quando você adota um modelo único, a decisão é binária: entrou ou não entrou no projeto

Quando você adota uma família, você acabou de ganhar uma camada nova de arquitetura, que é o roteamento por tarefa

Se você já mexeu com pool de conexão de banco, é parecido: não é "qual conexão", é "qual política decide qual conexão pra qual query"

Na prática, três coisas mudam no seu código:

• O ID do modelo deixa de ser constante e vira configuração. Se "mimo-v2.6-pro" está escrito na mão em oito arquivos, trocar de variante vira um mutirão de find and replace
• O orçamento deixa de ser uma linha só. Você passa a ter custo por rota, não custo por projeto
• A observabilidade precisa gravar qual variante respondeu. Sem isso, quando a qualidade cair você não sabe se foi o prompt, o modelo ou o roteador

E aqui está o motivo pra levar isso a sério: o salto de preço dentro da própria família é brutal

De Flash pra Pro, a entrada vai de US$ 0,14 pra US$ 0,435 por 1M de tokens, ou seja, cerca de 3x

De Pro pra UltraSpeed, vai de US$ 0,435 pra US$ 4,35, exatos 10x

Juntando as pontas: rodar no UltraSpeed uma carga que o Flash resolveria custa cerca de 31x mais na entrada

Errar a variante não é detalhe estético, é a fatura do mês

Critério de escolha por tarefa (com os três cenários mais comuns)

Lote grande e repetitivo: comece pelo Flash

Classificação em volume, extração de campo, triagem de ticket, legenda de imagem em massa, esse tipo de coisa

O argumento pro Flash não é só ser barato, é a distância pequena nos benchmarks divulgados pela própria Xiaomi

No DeepSWE v1.1, o Flash marca 67,9 contra 71,9 do Pro

No Terminal-Bench 2.1, 87,6 contra 89,9

Poucos pontos atrás, por um terço do preço de entrada. Pra tarefa repetitiva e verificável, isso é fácil de justificar

O cuidado é o de sempre: se a tarefa começa a falhar em cadeia e você se vê remendando prompt sem parar, existem sinais de que pede modelo maior e insistir no menor só empurra o custo pra retrabalho

Refatoração e agente de código longo: Pro

Aqui o critério é diferente. Você não está pagando por token, está pagando por não ter que revisar cinquenta arquivos quebrados depois

O Pro é o topo do índice entre pesos abertos e é a variante que a doc da MiMo aponta como padrão pra uso em Claude Code

E já deixo o aviso de bastidor: agente rodando solto em refatoração grande gera diff gigante, e aí vale ter um método pra revisar diff grande de agente antes de aprovar qualquer coisa

Interface interativa onde o usuário fica olhando pra tela: UltraSpeed

Chat de produto, assistente dentro do app, aquela tela em que a pessoa espera o texto aparecer

É o cenário que a Xiaomi cita pro UltraSpeed: mesma performance do Pro com velocidade de saída até 20x maior, pensado pra baixa latência

Só não caia na tentação de usar ele como padrão geral

A 10x o preço do Pro, ele é ferramenta de latência, não ferramenta de volume

Rodar local e agêntico: o destilado de 9B

O MiMo-V2.6-Distill-Qwen-9B é um modelo agêntico de 9B, feito por fine-tuning supervisionado de Qwen3.5-9B com dados gerados pelo MiMo, cobrindo código, agentes, código visual e cibersegurança

Pesos no Hugging Face, licença MIT

Pra quem quer manter dado dentro de casa ou montar automação local sem depender de API, esse é o nome da família pra olhar primeiro

Como testar as três variantes sem reescrever seu código

A boa notícia é que trocar de variante é troca de string, desde que você monte certo desde o começo

1. Aponte o SDK da OpenAI pra base URL da MiMo. A API é compatível com Chat Completions da OpenAI, com base_url em https://api.xiaomimimo.com/v1 e a chave lida de MIMO_API_KEY, como mostra a documentação de primeira chamada

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["MIMO_API_KEY"],
    base_url="https://api.xiaomimimo.com/v1"
)

# o ID vem de config, nunca hardcoded no meio da lógica
MODELO = os.environ.get("MIMO_MODEL", "mimo-v2.6-flash")

resposta = client.chat.completions.create(
    model=MODELO,
    messages=[{"role": "user", "content": "Resuma o que este erro de build indica"}]
)

print(resposta.choices[0].message.content)

2. Rode a MESMA tarefa nos três IDs. Troque MIMO_MODEL entre mimo-v2.6-flash, mimo-v2.6-pro e mimo-v2.6-pro-ultraspeed e guarde as três saídas lado a lado

O erro comum deste passo: deixar o nome do modelo escrito na mão dentro da função. Aí o "teste rápido" vira refactor, você desiste e fica no primeiro que funcionou. Tome cuidado com isso desde a primeira linha

3. Se o seu fluxo é Claude Code, use o endpoint compatível com Anthropic. A plataforma da MiMo expõe esse caminho e a configuração fica em ~/.claude/settings.json

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.xiaomimimo.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "sua-chave-mimo",
    "ANTHROPIC_MODEL": "mimo-v2.6-pro"
  }
}

4. Limpe as variáveis antigas antes de testar. A própria doc de integração orienta limpar ANTHROPIC_AUTH_TOKEN e ANTHROPIC_BASE_URL preexistentes

O erro comum deste passo é exatamente esse: token antigo exportado no seu shell ganha da configuração nova, você acha que está falando com o MiMo-V2.6 e está falando com outra coisa. Já vi gente comparar modelo por meia hora assim, haha

5. Anote custo e latência por rota, não por projeto. Com três preços diferentes na mesma família, média geral não te diz nada

Armadilhas conhecidas logo após o lançamento

Sintoma: o modelo "novo" se comporta como um mais antigo

Causa provável: confusão de nome

Existe um MiMo-V2-Flash anterior, de dezembro de 2025, com a MESMA forma de 309B totais e 15B ativos, mas com contexto e preço diferentes (as referências dele falam em 256K de contexto)

Como prevenir: trate o 2.6 como parte obrigatória do nome em toda doc interna e em toda config. mimo-v2.6-flash e o Flash de 2025 são bichos diferentes

Sintoma: o catálogo que você consulta diz que os pesos são fechados

Causa provável: catálogo desatualizado logo depois do anúncio

Tem issue aberta no models.dev apontando justamente isso: Pro e Flash já estão em MIT no Hugging Face e no ModelScope, mas o dado seguia marcado como fechado

Como prevenir: pra licença e pesos, confira na página do modelo no Hugging Face, não no agregador

Sintoma: tool calling falha e o modelo insiste no mesmo erro

Causa provável: formato do argumento

Há relato público na issue #1005 do vercel-labs/fx: o MiMo-V2.6-Pro envia o argumento aninhado da ferramenta shell como string JSON, e repete o erro mesmo depois de a validação falhar

Como prevenir: se o seu produto depende de chamada de ferramenta em loop agêntico, valide esse caminho específico antes de mover qualquer carga de produção. Esse é o tipo de coisa que passa despercebida no teste de chat e explode no agente

Vale migrar para a família MiMo-V2.6?

Veredito honesto, e sem eu inventar experiência que não tenho aqui

O lado forte é difícil de ignorar: 46 no Intelligence Index, melhor colocado entre pesos abertos, licença MIT, entrada multimodal nativa (texto, imagem, áudio e vídeo) e preço de entrada de US$ 0,435 por 1M no Pro

O lado que o hype esquece: na tabela de benchmarks divulgada pela PRÓPRIA Xiaomi, o MiMo-V2.6-Pro fica atrás do Claude Opus 5 em 10 de 14 avaliações compartilhadas

Ou seja, "melhor de pesos abertos" é verdade, "melhor de todos" não é o que a tabela do fornecedor mostra

Faz sentido migrar se o seu gargalo é custo por token, se você precisa dos pesos pra rodar em casa ou se o multimodal de entrada resolve algo que hoje você faz com dois serviços colados

Não faz sentido migrar agora se o seu produto vive de tool calling em loop e você não tem fôlego pra lidar com o relato acima

Pra quem trabalha em Claude Code, OpenCode ou OpenClaw, existe o Token Plan, a assinatura da MiMo voltada a cenários de programação com IA, com acesso a mimo-v2.6-pro e mimo-v2.6-flash: Lite US$ 6/mês (60M créditos), Standard US$ 16/mês (200M), Pro US$ 50/mês (700M) e Max US$ 100/mês (1600M)

Conclusão

O recado da série MiMo-V2.6 é menos sobre benchmark e mais sobre postura: família de modelos exige que você tenha uma POLÍTICA, não uma preferência

Então o próximo passo é bem concreto:

1. Defina a variante padrão do projeto (na dúvida, comece no Flash e suba quando doer)
2. Tire o ID do modelo do meio do código e jogue pra configuração
3. Rode a mesma tarefa real nos três IDs e compare custo, latência e quantidade de retrabalho

Depois disso a conversa deixa de ser achismo e vira número seu, do seu caso de uso, que é o único que importa =)

Vou ficar de olho nas atualizações da série e volto por aqui quando os dados que hoje estão divergentes (cache, velocidade real do UltraSpeed) ficarem confiáveis…

Matheus Battisti, até o próximo post!