Testen von MiniMax M2.7 über API in drei realen ML- und Coding-Workflows

Andrey Lukyanenko hat MiniMax M2.7 über die API in drei realistischen ML- und Coding-Workflows getestet, wobei Claude Code als Steuerung diente. Ziel war es zu sehen, wie M2.7 in agentischen Schleifen im Vergleich zu Claude Opus 4.7 abschneidet.

Einrichtung

Die Testumgebung hat die MiniMax-API in einen claude-mm-Befehl eingebunden, der Claude Code auf M2.7 lenkt:

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 "$@"
}

Er arbeitete im MiniMax-Plus-Tarif (40 $/Monat), bei dem Kontextfenster und tägliches Durchsatzvolumen für mehrschrittige agentische Arbeit ausreichten.

Workflow 1: Refactoring eines PyTorch-Projekts

Die Aufgabe war, Abhängigkeiten und Codequalität im pytorch_tempest-Repository (Hydra + PyTorch Lightning) zu aktualisieren. Die Änderungen umfassten:

• Aktualisierte CI-Versionen und Pre-Commit-Hooks.
• Ersatz von black + flake8 durch ruff für Linting und Formatierung.
• Aktivierung von fsdp_sharding_strategy in der Lightning-Trainer-Konfiguration.
• Aktualisierte Dokumentation.
• Hinzufügen von uv für die Umgebungsverwaltung.
• Umstellung auf modernes Python-Typing (list[X] statt List[X], X | None statt Optional[X]).
• Entfernung doppelter Codepfade.

Das Vorgehen war schrittweise: Lukyanenko gab explizite Anforderungen, prüfte jede Änderung und gab Feedback, wenn der Diff vom Scope abwich. M2.7 passte gut, da es innerhalb enger Prompts blieb und eine zeilenweise Überprüfung ermöglichte. CI-Fehler wurden iterativ mit Hilfe des Agenten behoben.

Workflow 2: Obsidian-Vault-Notizen

Für das Schreiben und Prüfen von ML-Referenznotizen in Obsidian hat Lukyanenko die Prompts speziell auf M2.7 abgestimmt. Er begann damit, sowohl M2.7 als auch Opus 4.7 zu bitten, Notizen aus demselben Prompt zu generieren, und ließ dann M2.7 beide Ausgaben lesen und einen verbesserten Prompt für sich selbst vorschlagen. Der resultierende Prompt (gekürzt) war:

Fülle einen defekten Link-Stub im DSWoK-Vault: Recherchiere das Thema, entwirf die Notiz im DSWoK-Stil, führe draft-critic-mm aus, speichere im richtigen Ordner.

Schritte: Lese den Styleguide, wähle einen Stub aus, greppe nach Querverweisen, wähle Zielordner, entwirf, dann kritisiere.

Wichtigste Ergebnisse

In allen drei Durchläufen war M2.7 nützlich, wenn die Einschränkungen explizit und das Ausgabeformat konkret waren. Es hatte Schwierigkeiten, wenn wichtiger Kontext implizit blieb, obwohl Opus 4.7 teilweise dieselben Lücken aufwies. Für offene Fälle wird immer noch eine menschliche Durchsicht empfohlen. Der Autor stellt fest, dass Modellqualität und Steuerungsdesign schwer zu trennen sind – ein stärkeres Modell kann fehlende Einschränkungen ableiten, während eine bessere Steuerung sie explizit macht.