Probando MiniMax M2.7 a través de la API en tres flujos de trabajo reales de ML y codificación

Andrey Lukyanenko puso a prueba MiniMax M2.7 en tres flujos de trabajo realistas de ML y codificación a través de la API, usando Claude Code como plataforma. El objetivo: ver cómo se desempeña M2.7 en bucles agentivos comparado con Claude Opus 4.7.

Configuración

El entorno de prueba envolvió la API de MiniMax en un comando claude-mm que apunta Claude Code a 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 "$@"
}

Ejecutó en el nivel Plus de MiniMax ($40/mes), donde la ventana de contexto y el rendimiento diario fueron suficientes para trabajo agentivo de múltiples pasos.

Flujo de trabajo 1: Refactorizar un proyecto PyTorch

La tarea era actualizar dependencias y calidad de código en el repositorio pytorch_tempest (Hydra + PyTorch Lightning). Los cambios incluyeron:

• Actualización de versiones de CI y hooks de pre-commit.
• Reemplazo de black + flake8 con ruff para linting y formateo.
• Habilitación de fsdp_sharding_strategy en la configuración del trainer de Lightning.
• Actualización de documentación.
• Adición de uv para gestión de entornos.
• Cambio a tipado moderno de Python (list[X] en lugar de List[X], X | None en lugar de Optional[X]).
• Eliminación de rutas de código duplicadas.

El enfoque fue paso a paso: Lukyanenko dio requisitos explícitos, revisó cada cambio y proporcionó retroalimentación cuando el diff se desviaba del alcance. M2.7 se adaptó bien porque se mantuvo dentro de indicaciones estrechas y permitió revisión a nivel de línea. Las fallas de CI se solucionaron iterativamente con la ayuda del agente.

Flujo de trabajo 2: Notas de Obsidian Vault

Para escribir y auditar notas de referencia de ML en Obsidian, Lukyanenko ajustó las indicaciones específicamente para M2.7. Comenzó pidiendo tanto a M2.7 como a Opus 4.7 generar notas a partir de la misma indicación, luego hizo que M2.7 leyera ambas salidas y propusiera una indicación mejorada para sí mismo. La indicación resultante (condensada) fue:

Completa un enlace roto en el vault DSWoK: investiga el tema, redacta la nota con la voz de DSWoK, ejecuta draft-critic-mm, guarda en la carpeta correcta.

Pasos: leer guía de estilo, elegir un enlace roto, buscar referencias cruzadas con grep, seleccionar carpeta de destino, redactar, luego criticar.

Resultados clave

En las tres ejecuciones, M2.7 fue útil cuando las restricciones eran explícitas y el formato de salida concreto. Tuvo dificultades cuando el contexto importante quedaba implícito, aunque Opus 4.7 a veces tenía las mismas lagunas. Para casos abiertos, aún se recomienda una revisión humana. El autor señala que la calidad del modelo y el diseño de la plataforma son difíciles de separar: un modelo más fuerte puede inferir restricciones faltantes, mientras que una mejor plataforma las hace explícitas.