Test de MiniMax M2.7 via API sur trois workflows ML et codage réels

Andrey Lukyanenko a testé MiniMax M2.7 sur trois workflows réalistes de ML et codage via l'API, en utilisant Claude Code comme harnais. Objectif : voir comment M2.7 se comporte dans des boucles agentiques par rapport à Claude Opus 4.7.

Configuration

L'environnement de test a enveloppé l'API MiniMax dans une commande claude-mm qui pointe Claude Code vers 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 "$@"
}

Il a utilisé le niveau Plus de MiniMax (40 $/mois), où la fenêtre de contexte et le débit quotidien étaient suffisants pour un travail agentique multi-étapes.

Workflow 1 : Refactorisation d'un projet PyTorch

La tâche consistait à mettre à jour les dépendances et la qualité du code dans le dépôt pytorch_tempest (Hydra + PyTorch Lightning). Les modifications comprenaient :

• Mise à jour des versions CI et des hooks pre-commit.
• Remplacement de black + flake8 par ruff pour le linting et le formatage.
• Activation de fsdp_sharding_strategy dans la configuration du trainer Lightning.
• Actualisation de la documentation.
• Ajout de uv pour la gestion d'environnement.
• Passage au typage Python moderne (list[X] au lieu de List[X], X | None au lieu de Optional[X]).
• Suppression des chemins de code dupliqués.

L'approche était progressive : Lukyanenko donnait des exigences explicites, examinait chaque modification et fournissait des retours lorsque le diff sortait du cadre. M2.7 s'adaptait bien car il restait dans des prompts étroits et permettait une révision ligne par ligne. Les échecs CI étaient corrigés de manière itérative avec l'aide de l'agent.

Workflow 2 : Notes Obsidian

Pour la rédaction et la relecture de notes de référence ML dans Obsidian, Lukyanenko a adapté les prompts spécifiquement pour M2.7. Il a d'abord demandé à M2.7 et Opus 4.7 de générer des notes à partir du même prompt, puis a fait lire les deux sorties par M2.7 et proposer un prompt amélioré pour lui-même. Le prompt résultant (condensé) était :

Remplir un stub de lien cassé dans le coffre DSWoK : rechercher le sujet, rédiger la note dans le style DSWoK, exécuter draft-critic-mm, enregistrer dans le bon dossier.

Étapes : lire le guide de style, choisir un stub, grep pour les références croisées, choisir le dossier de destination, rédiger, puis critiquer.

Résultats clés

Sur les trois essais, M2.7 était utile lorsque les contraintes étaient explicites et le format de sortie concret. Il peinait quand un contexte important était implicite, bien qu'Opus 4.7 présente parfois les mêmes lacunes. Pour les cas ouverts, un passage de révision humaine reste recommandé. L'auteur note que la qualité du modèle et la conception du harnais sont difficiles à séparer — un modèle plus fort peut inférer les contraintes manquantes, tandis qu'un meilleur harnais les rend explicites.