MiniMax M3: Um Agente de Programação OpenClaw versus Kimi K3 e dsh

O MiniMax M3 agora executa meu agente de trabalho no OpenClaw. Dei a ele as mesmas cinco pequenas tarefas de programação que havia dado ao Kimi K3 mais cedo naquela mesma manhã, e ele passou em todas as cinco em cerca de metade do tempo de execução do Kimi a cerca de um quarto do custo de tabela do Kimi. Trate a proporção de velocidade como aproximada: o Kimi rodou no modo de processamento máximo e o M3 nas configurações padrão do OpenClaw, as duas execuções usaram arquivos de teste diferentes, e o MiniMax precisou de novas tentativas. Eu também pretendia comparar como os dois criaram uma versão em pixel art do logotipo deste site a partir do mesmo briefing escrito. Essa parte não resistiu à verificação: o widget que inicialmente atribuí à MiniMax foi escrito pelo Kimi, e a execução da MiniMax encontrou os arquivos do Kimi e os reportou como seu próprio trabalho. Os detalhes estão abaixo, porque como isso aconteceu é a coisa mais útil deste artigo.

O que realmente é o provedor minimax do OpenClaw

Eu estava errado num rascunho anterior; portanto, aqui está a informação correta, baseada no código instalado e na minha própria configuração.

• Protocolo e endpoint. O plugin minimax incluso no OpenClaw configura seus provedores com api: "anthropic-messages" e URL base https://api.minimax.io/anthropic (uma variável chamada MINIMAX_API_HOST permite alterar esse host). O MiniMax também disponibiliza uma API compatível com o OpenAI em https://api.minimax.io/v1, mas o plugin do OpenClaw não a utiliza.
• O que você pode configurar. Quase nada. No meu arquivo openclaw.json, só sobrescrevo a lista de modelos do provedor minimax; o tipo de API, a URL base e os dados de autenticação são definidos pelo próprio plugin. Na região da China, o MiniMax utiliza https://api.minimaxi.com/anthropic.
• A chave de acesso. Trata-se de uma variável de ambiente: o plugin lê o valor de MINIMAX_API_KEY (além de algumas variantes relacionadas ao plano de uso).
• Configurações do modelo. O catálogo do plugin atribui ao modelo M3 uma janela de contexto de 1.000.000 de tokens e uma única configuração compat, especificamente codeMode: "preferred" (modo de codificação do OpenClaw; não tem relação com o Codex). Não há opção para ajustar a temperatura na configuração.
• Preços. O plugin define os custos do modelo M3 em $0,60 por milhão de tokens enviados, $2,40 por milhão de tokens recebidos e $0,12 por milhão de tokens lidos do cache; esses valores preenchem o campo usage.cost.total no JSON gerado. Essas são as tarifas padrão indicadas na página de preços sob demanda do MiniMax para solicitações com até 512 mil tokens de entrada. Em 16/09/2026, a página exibia esses valores riscados e com desconto de 50% ($0,30 / $1,20 / $0,06); acima de 512 mil tokens de entrada, as tarifas padrão dobram. Os custos mencionados neste artigo seguem os valores informados pelo plugin, ou seja, os preços sem desconto.

Não é o Codex

Este é o próprio loop de agentes do OpenClaw, e não o servidor de aplicações Codex da OpenAI. O OpenClaw possui um plugin para integração com o Codex, mas a verificação de rotas (configuredModelRouteNeedsCodex) retorna false para qualquer provedor cujo ID não seja normalizado para openai; portanto, uma rota minimax/MiniMax-M3 nunca é considerada válida. O JSON gerado a cada execução indica qual loop foi utilizado: agentHarnessId: "openclaw". De qualquer forma, o plugin do Codex não está instalado na minha máquina.

Para usar o M3 em conjunto com o Codex, seria necessário um “bridge” local como o codex-router, além de permitir que o plugin do Codex compartilhe meu próprio diretório ~/.codex, que então seria utilizado por todos os agentes na máquina. Não fiz isso. Tudo descrito neste artigo refere-se ao loop nativo do OpenClaw.

Configuração

As versões que utilizei:

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2

Passo 1: a chave

O plugin minimax vem incluído no OpenClaw 2026.9.2 e está ativado na minha instalação. Ele lê a chave de MINIMAX_API_KEY; portanto, configure essa variável no ambiente em que o seu gateway está rodando (um arquivo EnvironmentFile do systemd, um plist do launchd ou seu shell). Em seguida, reinicie o gateway com o comando openclaw gateway restart. Não cole a chave diretamente no arquivo openclaw.json. Caso seja necessário mencionar a chave em alguma entrada do provedor, use a referência "${MINIMAX_API_KEY}", e não o valor real da chave.

Passo 2: apontar um agente de trabalho para o M3

Há duas partes no arquivo openclaw.json. Primeiro, a cadeia de modelos do agente:

"agents": { "entries": { "worker": { "model": {
  "primary": "minimax/MiniMax-M3",
  "fallbacks": ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"]
} } } }

Em seguida, opcionalmente, um limite de contexto para a linha do modelo. Este é o trecho da minha própria configuração. Não contém api, baseUrl ou apiKey, pois esses valores vêm do plugin:

"models": { "providers": { "minimax": { "models": [ {
  "id": "MiniMax-M3", "name": "MiniMax M3",
  "reasoning": true, "input": ["text", "image"],
  "contextWindow": 1000000, "contextTokens": 262144, "maxTokens": 128000,
  "compat": { "codeMode": "preferred" }
} ] } } }

Eu repito toda a entrada de modelo do plugin em vez de adicionar apenas uma chave, pois uma sobrescrita parcial nessa configuração fez com que reasoning: true fosse ignorado, fazendo com que o M3 rodasse sem o modo de raciocínio por dias. O limite em si: 262.144 dos 1.000.000 disponíveis no catálogo, mantendo as sessões longas do agente compactas, em vez de crescerem indefinidamente.

Passo 3: teste de verificação

Este é o desafio PONG do benchmark, com os campos que me interessam destacados:

$ openclaw agent --agent worker --model minimax/MiniMax-M3 \
    --session-key agent:worker:bench-pong-1 \
    -m "Reply with exactly: PONG." --json \
  | jq '{harness: .result.meta.agentMeta.agentHarnessId,
         provider: .result.meta.executionTrace.winnerProvider,
         model: .result.meta.executionTrace.winnerModel,
         contextTokens: .result.meta.agentMeta.contextTokens,
         usage: (.result.meta.agentMeta.usage | {input, output, cacheRead, cost: .cost.total})}'
{
  "harness": "openclaw",
  "provider": "minimax",
  "model": "MiniMax-M3",
  "contextTokens": 262144,
  "usage": {
    "input": 16384,
    "output": 184,
    "cacheRead": 128,
    "cost": 0.01028736
  }
}

harness: "openclaw" representa o loop nativo. winnerModel indica qual foi o modelo que forneceu a resposta principal, em vez de um modelo secundário. contextTokens mostra que o limite de tokens realmente foi aplicado. Os 16.384 tokens de entrada não armazenados em cache são, na maioria, o prompt do sistema e as definições das ferramentas que uma nova sessão envia no seu primeiro turno; é por isso que até mesmo o desafio PONG gera custos. O custo mencionado corresponde ao preço de lista do plugin, não ao valor cobrado por planos com taxa fixa.

Lado a lado: MiniMax M3, Kimi K3, dsh

Dois desses são modelos que impulsionam o loop do OpenClaw. O terceiro, DeepSeek Harness (dsh), é o próprio agente de codificação da DeepSeek, com seu próprio loop de execução. Artigos anteriores desta série também incluíam uma coluna referente ao Reasonix. Nunca realizei testes de desempenho no Reasonix em modo headless; além disso, retirei-o da minha configuração em 2026-09-09, por isso ele não aparece aqui.

O benchmark: cinco tarefas

As cinco tarefas são as mesmas do artigo do dsh: responder “PONG”; escrever e executar o FizzBuzz; corrigir dois bugs para que os testes unitários passem, sem tocar nos próprios testes; resumir um código composto por seis módulos em menos de 150 palavras; renomear uma função em vários arquivos e testes, comprovando que os testes ainda passam. Todas as três execuções ocorreram em 11/09/2026. O Kimi foi executado com --thinking max; o MiniMax utilizou a configuração adaptativa padrão do OpenClaw; os números do dsh são resultado de uma nova execução com cache aquecido.

O que não foi igual:

• Configurações de raciocínio diferentes. O Kimi operou no modo máximo, enquanto o MiniMax usou a configuração padrão. Parte do tempo extra gasto pelo Kimi corresponde ao raciocínio adicional que solicitei.
• Arquivos de teste diferentes. Cada execução criou suas próprias pastas temporárias. Na tarefa de correção de bugs, foram corrigidos bugs distintos (Kimi: add e is_even em um módulo; MiniMax: add e subtract). Na tarefa de renomeação, funções diferentes foram alteradas (Kimi: calculate_total virou compute_total em três módulos e um arquivo de teste; MiniMax: area_of_rect virou rect_area em três módulos e um arquivo de teste). As formas dos códigos são semelhantes, mas os arquivos não coincidem.
• Tentativas repetidas. Na primeira execução, o MiniMax reutilizou uma sessão persistente para todas as cinco tarefas; isso gerou erros interessantes (veja as “Armadilhas”), por isso executei tudo novamente com chaves de sessão novas. O FizzBuzz exigiu mais duas tentativas, pois o sistema continuava gravando fizz.py em seu próprio diretório em vez da pasta temporária. A tabela mostra a quarta tentativa do FizzBuzz. O FizzBuzz e a correção de bugs também foram reexecutados no Kimi: na primeira tentativa, o FizzBuzz foi interrompido por um limite de uso; na primeira correção de bugs, o arquivo já havia sido alterado em uma execução anterior.

Os valores indicam o custo por milhão de tokens, na ordem: entrada sem cache / saída / leitura do cache. Cada custo total é a soma dos valores usage.cost.total de cada tarefa; multiplicar os totais de tokens pelas taxas indicadas gera o mesmo valor.

O que a tabela revela:

• Todas as tarefas foram concluídas com sucesso. Verifiquei cada resultado diretamente no disco: saída do FizzBuzz, testes pytest aprovados, contagem de palavras do resumo dentro do limite permitido e ausência de nomes antigos após a renomeação.
• O MiniMax foi cerca de 2× mais rápido que o Kimi e aproximadamente 4× mais barato, segundo os preços listados (309,9 s contra 159,2 s; US$ 0,531 contra US$ 0,125). Considerando as diferenças nas configurações de raciocínio e nos arquivos de teste, use essa proporção como uma referência aproximada, não como um valor exato.
• O dsh no V4-Flash foi cerca de 4,5× mais rápido que o MiniMax e aproximadamente 11× mais barato nas mesmas tarefas.
• O cache é o grande responsável pela eficiência. O MiniMax leu 5,2 tokens do cache para cada token de entrada sem cache. Pelos preços listados, uma leitura do cache custa 80% menos que a entrada sem cache. Se fossem cobrados como entrada sem cache, os mesmos tokens gerariam um custo de cerca de US$ 0,34 em vez de US$ 0,125.
• As tentativas repetidas não estão incluídas nos totais. Todas as doze execuções do MiniMax, inclusive as descartadas, resultaram em um custo total de US$ 0,28 e 321 segundos, segundo os preços listados.

O teste do widget, e uma correção

O “teste divertido” mencionado no artigo sobre dsh era um widget em estilo pixel art com o logotipo deste site, criado a partir de um briefing escrito (citado na íntegra no artigo): um único arquivo ll-pixel-logo.js sem dependências, que rasteriza um anel e dois “Ls” inclinados numa grade de 40×40, afasta os pixels do cursor, se fragmenta e se recompõe ao ser clicado, respeita a configuração prefers-reduced-motion, além de incluir uma página de demonstração, um README e um autoteste. Dei o mesmo briefing para o Kimi e depois para o MiniMax, ambos operando no mesmo agente de trabalho. O artigo sobre o Kimi descreve as três tentativas do Kimi; a parte relevante aqui é a segunda tentativa, na qual ele gerou um widget completo com 323 linhas de código, uma página de demonstração, um README e dois arquivos de teste dentro do espaço de trabalho do agente, em vez da pasta que eu monitorava; porém, sua resposta foi interrompida aos 15 minutos. Eu supus então que ele não tivesse produzido nada.

Uma hora depois, o MiniMax recebeu o mesmo briefing no mesmo agente: 59,3 segundos, 25 iterações, 24 chamadas a ferramentas, custo de $0,13 segundo os preços listados. Ele encontrou os arquivos da segunda tentativa do Kimi ainda presentes no espaço de trabalho, leu todos os cinco arquivos além do relatório de execução do Kimi, rodou os testes e respondeu: “O conjunto completo de widgets foi criado e verificado”. Na verdade, ele não escreveu uma única linha de código para o widget. Os únicos arquivos que gerou foram seu próprio relatório de execução e um arquivo de status.

Eu aceitei essa resposta como verdadeira; a primeira versão deste artigo atribuiu o widget ao MiniMax. O log da sessão, porém, mostra o write desse exato arquivo na segunda tentativa do Kimi, e a cópia disponível neste site é idêntica a ele em nível de bytes. Portanto, este artigo não apresenta nenhum resultado de widget gerado pelo MiniMax; também não voltei a executar o briefing. O que ele traz, na verdade, é um exemplo claro de um agente que atribui a si mesmo o trabalho encontrado por outro, motivo pelo qual incluí as verificações listadas abaixo.

Aqui está o widget, devidamente creditado à segunda tentativa do Kimi K3:

Sua geometria: RING_R = 19.4, o anel interno fica a 0,82R da borda, SHEAR = 0.42 (cerca de 22,8°), e existe um auxiliar inL que testa simultaneamente a base e o caule inclinado. Ao avaliar a função isLit sobre toda a grade de 40×40, obtém-se 602 células iluminadas. O artigo comparativo o posiciona ao lado dos outros dois widgets.

O que reverifiquei no widget da tentativa-2

Executei tudo numa cópia temporária da pasta que contém o widget e os dois arquivos de teste escritos por Kimi:

$ wc -l ll-pixel-logo.js
323 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "syntax ok"
syntax ok
$ node test-bitmap.js | tail -1
ALL PASS
$ node test-smoke.js | tail -1
SMOKE PASS

test-bitmap.js realiza 18 verificações: a presença do anel nos pontos cardinais e sua ausência nos cantos e no centro; cada haste e base do “L” deve estar em seu respectivo quadrante; também verifica a zona de intertravamento, a direção da inclinação e o número total de células iluminadas, que deve estar entre 540 e 670. test-smoke.js realiza 10 verificações: montagem do widget usando um DOM fictício; remontagem idempotente; uso de role="img" e de um atributo aria-label; execução de 300 quadros com movimento do cursor e dois cliques (o segundo no meio da animação); estado final das partículas; retorno do logotipo à posição inicial após a animação; uso de um buffer de 640 px com devicePixelRatio igual a 2; além disso, verifica-se que o método unmount() funciona corretamente. Esses são os próprios testes de Kimi, e não constituem uma verificação independente: Kimi editou o arquivo test-bitmap.js após a primeira execução, movendo as caixas de detecção e ajustando o intervalo do número de células iluminadas para 540–670, depois de ter medido um total de 602. Uma execução bem-sucedida aqui indica apenas que o widget e seus testes estão alinhados; não significa que os testes estabeleçam um padrão mínimo a ser atingido. Minha própria contagem aponta para 602 células iluminadas, distribuídas da seguinte forma: 196, 137, 101 e 168 nos quadrantes superior-esquerdo, superior-direito, inferior-esquerdo e inferior-direito, respectivamente.

Armadilhas (as que eu realmente encontrei)

• Sessões persistentes estragam os benchmarks. O comando openclaw agent --agent worker -m "…" reutiliza a sessão do agente, a menos que você especifique um novo --session-key. Na minha primeira execução do MiniMax, o teste FizzBuzz concluiu que o arquivo já existia e se recusou a gravá-lo; a execução de correção de bugs informou que os testes já haviam sido aprovados; já a execução de resumo acabou resumindo o conteúdo da pasta de correção do Kimi, em vez do seu próprio. Um --session-key único por tarefa resolveu esse problema.
• As instruções padrão do worker têm prioridade sobre o prompt quanto ao local de gravação dos arquivos. As instruções do meu agente worker determinam que saídas maiores sejam salvas em seu próprio espaço de trabalho; isso prevaleceu sobre a ordem “grave o fizz.py nesta pasta” em duas ocasiões. Na terceira execução do FizzBuzz, a resposta indicou que o arquivo foi gravado na pasta temporária; porém, o timestamp mostrava que ele foi para o espaço de trabalho. Na quarta execução, ao usar um caminho absoluto e uma instrução explícita, tudo ocorreu corretamente.
• Um espaço de trabalho compartilhado contamina a execução seguinte. É o mesmo problema mencionado anteriormente. Os arquivos deixados pelo Kimi permaneceram no espaço de trabalho do worker uma hora depois; o MiniMax os considerou como seus próprios arquivos. Portanto, forneça uma pasta vazia para cada execução e verifique o que realmente foi gravado (timestamps, chamadas write da sessão), não apenas o que o sistema diz ter escrito.
• O catálogo indica 1.000.000 de tokens; eu uso apenas 262.144. Esse é o meu próprio valor configurado em contextTokens; o campo agentMeta.contextTokens no JSON confirma qual valor está em vigor. Aumente esse valor se realmente precisar de uma janela maior para processamento.
• Os valores monetários exibidos num plano fixo são fictícios, mas úteis como referência. O OpenClaw preenche o campo usage.cost.total com os preços padrão da plataforma, independentemente do valor real que você paga; por isso, serve para comparar modelos, mas não tem utilidade como fatura.

O que isso significa para mim

O MiniMax M3 é o modelo principal no meu agente de trabalho; o DeepSeek V4-Flash e, posteriormente, o V4-Pro servem como alternativas. O Kimi K3 não faz parte dessa cadeia de modelos; eu o uso em outro lugar, para o meu agente de revisão. Nessas tarefas, o M3 realizou a renomeação em 89,9 segundos, por um custo de US$ 0,058 (preço de tabela); o Kimi levou 128,9 segundos e custou US$ 0,180. Para a correção de bugs, o M3 precisou de 41,0 segundos e US$ 0,025, enquanto o Kimi exigiu 86,6 segundos e US$ 0,114. O dsh no V4-Flash foi mais rápido e mais barato que ambos em todas as tarefas.

Para o brief relacionado aos widgets, não tenho nenhum resultado do MiniMax. Se você fizer uma comparação semelhante, crie uma pasta vazia para cada execução e leia as chamadas write da sessão antes de consultar o relatório resultante.

Relacionado: Kimi K3 como agente de programação (o lado do Kimi nesta comparação), DeepSeek Harness (dsh) (as cinco tarefas e o brief original sobre widgets), Reasonix (comparado em artigos anteriores; retirado da minha configuração em 09/09/2026) e Quanto realmente custam os meus agentes de IA.