Testando MiniMax M2.7 via API em Três Fluxos de Trabalho Reais de ML e Codificação

Andrey Lukyanenko colocou o MiniMax M2.7 à prova em três fluxos de trabalho realistas de ML e codificação via API, usando o Claude Code como estrutura. O objetivo: ver como o M2.7 se sai em loops agentivos comparado ao Claude Opus 4.7.

Configuração

O ambiente de teste transformou a API MiniMax em um comando claude-mm que aponta o Claude Code para o M2.7:

claude-mm () {
  ANTHROPIC_BASE_URL = "https://api.minimax.io/anthropic" \
  ANTHROPIC_AUTH_TOKEN = "$MINIMAX_API_KEY" \
  ANTHROPIC_MODEL = "MiniMax-M2.7" \
  ANTHROPIC_DEFAULT_SONNET_MODEL = "MiniMax-M2.7" \
  ANTHROPIC_DEFAULT_OPUS_MODEL = "MiniMax-M2.7" \
  ANTHROPIC_DEFAULT_HAIKU_MODEL = "MiniMax-M2.7" \
  ANTHROPIC_SMALL_FAST_MODEL = "MiniMax-M2.7" \
  API_TIMEOUT_MS = "3000000" \
  CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC = "1" \
  claude "$@"
}

Ele executou no plano Plus da MiniMax (US$ 40/mês), onde a janela de contexto e a taxa de transferência diária foram suficientes para trabalho agentivo de várias etapas.

Workflow 1: Refatorando um Projeto PyTorch

A tarefa era atualizar dependências e qualidade do código no repositório pytorch_tempest (Hydra + PyTorch Lightning). As alterações incluíram:

• Versões de CI e hooks de pre-commit atualizados.
• Substituição de black + flake8 por ruff para linting e formatação.
• Habilitação de fsdp_sharding_strategy na configuração do trainer Lightning.
• Documentação atualizada.
• Adição de uv para gerenciamento de ambiente.
• Migração para tipagem Python moderna (list[X] em vez de List[X], X | None em vez de Optional[X]).
• Remoção de caminhos de código duplicados.

A abordagem foi passo a passo: Lukyanenko deu requisitos explícitos, revisou cada alteração e forneceu feedback quando o diff saía do escopo. O M2.7 se encaixou bem porque permaneceu dentro de prompts estreitos e permitiu revisão linha a linha. Falhas de CI foram corrigidas iterativamente com a ajuda do agente.

Workflow 2: Notas no Vault do Obsidian

Para escrever e auditar notas de referência de ML no Obsidian, Lukyanenko ajustou prompts especificamente para o M2.7. Ele começou pedindo tanto ao M2.7 quanto ao Opus 4.7 para gerar notas a partir do mesmo prompt, depois fez o M2.7 ler ambas as saídas e propor um prompt melhorado para si mesmo. O prompt resultante (condensado) foi:

Preencher um stub de link quebrado no vault DSWoK: pesquisar o tópico, rascunhar a nota no estilo DSWoK, executar draft-critic-mm, salvar na pasta correta.

Etapas: ler guia de estilo, escolher um stub, grep por referências cruzadas, escolher pasta de destino, rascunhar, depois criticar.

Principais Descobertas

Em todas as três execuções, o M2.7 foi útil quando as restrições eram explícitas e o formato de saída era concreto. Ele teve dificuldades quando contexto importante foi deixado implícito, embora o Opus 4.7 às vezes tivesse as mesmas lacunas. Para casos abertos, uma revisão humana ainda é recomendada. O autor observa que a qualidade do modelo e o design da estrutura são difíceis de separar — um modelo mais forte pode inferir restrições ausentes, enquanto uma estrutura melhor as torna explícitas.