MiniMax M3: Un agente de programación OpenClaw frente a Kimi K3 y dsh

Ahora, MiniMax M3 ejecuta mi agente de trabajo en OpenClaw. Le asigné las mismas cinco tareas de programación que había dado anteriormente a Kimi K3; MiniMax completó todas ellas en aproximadamente la mitad del tiempo que tardó Kimi, y por un costo de apenas una cuarta parte del precio establecido para Kimi. Hay que tomar esta relación de velocidad como orientativa: Kimi operó en modo de razonamiento máximo, mientras que M3 utilizó la configuración predeterminada de OpenClaw; además, se usaron archivos de prueba diferentes y MiniMax necesitó varios intentos para finalizar las tareas. También quería comparar cómo ambos agentes generaban una versión en pixel art del logotipo de este sitio a partir de la misma descripción escrita; sin embargo, esa parte no se pudo verificar: el “widget” que inicialmente atribuí a MiniMax fue creado por Kimi, y la ejecución de MiniMax encontró esos archivos e informó que eran obra suya. Los detalles se exponen a continuación, ya que el modo en que ocurrió esto es lo más relevante del artículo.

¿Qué es realmente el proveedor minimax de OpenClaw?

En un borrador anterior me equivoqué, así que aquí está la información basada en el código instalado y en mi propia configuración.

• Protocolo y endpoint. El plugin minimax incluido configura sus proveedores con api: "anthropic-messages" y la URL base https://api.minimax.io/anthropic (una variable llamada MINIMAX_API_HOST permite cambiar el host). MiniMax también ofrece una API compatible con OpenAI en https://api.minimax.io/v1, pero el plugin de OpenClaw no la utiliza.
• Qué se puede configurar. Muy poco. Mi archivo openclaw.json solo sobrescribe la lista de modelos del proveedor minimax; el tipo de API, la URL base y la autenticación provienen todos del propio plugin. La región de China de MiniMax utiliza https://api.minimaxi.com/anthropic.
• La clave de acceso. Se trata de una variable de entorno: el plugin lee MINIMAX_API_KEY (así como algunas variantes relacionadas con los planes de uso).
• Configuraciones del modelo. El catálogo del plugin asigna al modelo M3 una ventana de 1,000,000 de tokens y un único ajuste compat, concretamente codeMode: "preferred" (se trata del Modo Código de OpenClaw; no guarda relación con Codex). No existe ningún parámetro para ajustar la temperatura.
• Precios. El plugin fija el precio del modelo M3 en $0.60 por cada millón de tokens ingresados, $2.40 por cada millón de tokens generados y $0.12 por cada millón de tokens leídos desde la caché; estos valores son los que llenan el campo usage.cost.total en el JSON resultante. Esas son las tarifas estándar indicadas en la página de precios de pago por uso de MiniMax para solicitudes de hasta 512,000 tokens de entrada. El 16 de septiembre de 2026 dicha página mostraba esos precios tachados y con un descuento del 50% ($0.30 / $1.20 / $0.06); además, para solicitudes con más de 512,000 tokens de entrada las tarifas se duplican. Los costos mencionados en este artículo siguen los valores indicados por el plugin, es decir, los precios sin descuento.

No es Codex

Se trata del bucle de agentes propio de OpenClaw, no del servidor de aplicaciones Codex de OpenAI. OpenClaw cuenta con un plugin de integración con Codex; sin embargo, su verificación de rutas (configuredModelRouteNeedsCodex) devuelve false para cualquier proveedor cuyo ID no se normalice a openai. Por eso, una ruta como minimax/MiniMax-M3 nunca cumple los requisitos. El JSON generado en cada ejecución indica qué bucle se utilizó: agentHarnessId: "openclaw". De todos modos, el plugin de Codex no está instalado en mi sistema.

Para utilizar M3 mediante Codex sería necesario emplear un puente local como codex-router, además de permitir que el plugin de Codex comparta mi directorio ~/.codex, el cual sería compartido por todos los agentes del sistema. No he hecho nada de eso. Todo lo descrito en este artículo corresponde al bucle nativo de OpenClaw.

Configuración

Las versiones que utilicé:

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

Paso 1: la clave

El plugin minimax se incluye en OpenClaw 2026.9.2 y está habilitado en mi instalación. Este plugin lee la clave desde MINIMAX_API_KEY; por lo tanto, indíquela en el entorno donde se ejecuta su gateway (ya sea mediante un archivo EnvironmentFile de systemd, un archivo plist de launchd o su shell). Luego, reinicie el gateway con el comando openclaw gateway restart. No pegue la clave directamente en openclaw.json. Si en alguna fila del proveedor es necesario indicar el nombre de la clave, escriba la referencia "${MINIMAX_API_KEY}", no el valor real de la clave.

Paso 2: apuntar un agente trabajador a M3

Hay dos partes en el archivo openclaw.json. Primero, la cadena de modelos del agente:

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

Luego, opcionalmente, un límite de contexto para la fila del modelo. Este es el fragmento de mi propia configuración. No contiene api, baseUrl ni apiKey, ya que estos datos provienen del 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" }
} ] } } }

Repito todo el fragmento de configuración del plugin en lugar de añadir solo esa clave, porque una sobrescritura parcial en este equipo hizo que se eliminara silenciosamente reasoning: true, lo que causó que M3 funcionara sin capacidad de razonamiento durante días. El límite en cuestión: 262,144 de los 1,000,000 totales del catálogo; esto mantiene las sesiones largas de los agentes trabajadores bajo control, evitando que crezcan sin límite.

Paso 3: prueba de verificación

Esta es la tarea PONG del conjunto de pruebas; aquí se muestran los campos que me interesan:

$ 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 el bucle nativo. winnerModel indica cuál es el modelo que respondió, en lugar de un modelo alternativo. contextTokens muestra que el límite de tokens se aplicó efectivamente. Los 16,384 tokens de entrada no almacenados en caché corresponden mayormente al prompt del sistema y a las definiciones de herramientas que una sesión nueva envía en su primera interacción; por eso incluso la tarea PONG conlleva un costo. Este costo corresponde al precio listado del plugin, no a lo que cobra un plan de tarifa plana.

Comparativa: MiniMax M3, Kimi K3 y dsh

Dos de estos modelos son los que impulsan el bucle de ejecución de OpenClaw. El tercero, DeepSeek Harness (dsh), es el propio agente de programación desarrollado por DeepSeek, con su propio bucle de ejecución. En artículos anteriores de esta serie también aparecía una columna correspondiente a Reasonix. Nunca realicé pruebas de rendimiento con Reasonix en modo headless, y lo retiré de mi configuración el 2026-09-09; por eso no figura aquí.

El benchmark: cinco tareas

Las cinco tareas son las mismas que en el artículo de dsh: responder “PONG”; escribir y ejecutar FizzBuzz; corregir dos errores para que las pruebas unitarias pasen sin tocarlas; resumir un código compuesto por seis módulos en menos de 150 palabras; renombrar una función en varios archivos y pruebas, y verificar que estas últimas sigan pasando. Las tres ejecuciones se realizaron el 11-09-2026. Kimi operó con --thinking max; MiniMax utilizó el modo de pensamiento adaptativo predeterminado de OpenClaw; los datos de dsh corresponden a una reejecución con caché ya caliente.

Lo que no fue igual en las ejecuciones:

• Configuraciones de pensamiento distintas. Kimi con el máximo nivel, MiniMax con la configuración por defecto. Parte del tiempo adicional de Kimi se debió a la profundidad de razonamiento que solicité.
• Archivos de prueba diferentes. Cada ejecución generó sus propias carpetas temporales. En la tarea de corrección de errores se arreglaron errores distintos (Kimi: add e is_even en un módulo; MiniMax: add y subtract). En la tarea de renombrado se cambiaron nombres distintos (Kimi: calculate_total pasó a ser compute_total en tres módulos y un archivo de pruebas; MiniMax: area_of_rect se renombró como rect_area en idénticas ubicaciones). Las estructuras son similares, pero los archivos no coinciden.
• Reintentos. La primera ejecución de MiniMax empleó una misma sesión persistente para las cinco tareas y falló de forma instructiva (véanse las “Pitfalls”), por lo que volví a ejecutarlas todas usando claves de sesión nuevas. FizzBuzz requirió dos intentos adicionales, pues el sistema seguía guardando fizz.py en su propio espacio de trabajo en lugar de en la carpeta temporal. La tabla muestra el cuarto intento de ejecución de FizzBuzz. Asimismo, Kimi volvió a ejecutar FizzBuzz y la corrección de errores: el primer intento de FizzBuzz terminó con un mensaje de límite de uso, y el primer intento de corrección indicó que el archivo ya había sido modificado en una ejecución previa.

Los precios se indican por millón de tokens, en el orden siguiente: entrada sin caché / salida / lectura de caché. Cada coste es la suma de los valores usage.cost.total de cada tarea; multiplicar el total de tokens por dichos precios arroja el mismo resultado.

Lo que revela la tabla:

• Todas las tareas se completaron correctamente. Verifiqué cada resultado en disco: salida de FizzBuzz, pruebas pytest exitosas, recuento de palabras del resumen y ausencia de nombres obsoletos tras el renombrado.
• MiniMax resultó aproximadamente 2 veces más rápido que Kimi y unas 4 veces más barato según los precios de lista (159,2 s frente a 309,9 s; $0,125 frente a $0,531). Dadas las diferencias en configuraciones de razonamiento y archivos de prueba, este ratio de velocidad debe considerarse una referencia aproximada, no una medida exacta.
• dsh sobre V4-Flash fue unas 4,5 veces más rápido que MiniMax y alrededor de 11 veces más económico en este tipo de tareas.
• La caché es clave para el rendimiento. MiniMax leyó 5,2 tokens desde la caché por cada token de entrada sin caché. Según los precios de lista, una lectura de caché cuesta un 80 % menos que una entrada sin caché. De haberse facturado como entrada sin caché, esos mismos tokens habrían costado unos $0,34 en lugar de $0,125.
• Los reintentos no se incluyen en los totales. Las doce ejecuciones de benchmark realizadas por MiniMax, incluidas las descartadas, sumaron $0,28 según precios de lista y 321 s de tiempo transcurrido.

La prueba del widget, y una corrección

El “divertido test” del artículo sobre dsh consistía en un widget de arte pixelado con el logo de este sitio, creado a partir de un brief escrito (citado íntegramente en el concurso): un archivo ll-pixel-logo.js sin dependencias que rasteriza un anillo y dos “L” inclinadas sobre una cuadrícula de 40×40, hace que los píxeles se alejen del puntero, se fragmenta y vuelve a ensamblarse al hacer clic, respeta la preferencia prefers-reduced-motion, además de incluir una página de demostración, un README y una prueba automática. Le di el mismo brief a Kimi y luego a MiniMax, ambos en el mismo agente de trabajo. El artículo sobre Kimi describe los tres intentos de Kimi; lo relevante aquí es el segundo intento, que generó un widget completo de 323 líneas, una página de demostración, un README y dos archivos de prueba dentro del espacio de trabajo propio del agente de trabajo, en lugar de la carpeta que yo estaba vigilando; el proceso se interrumpió a los 15 minutos de haber comenzado. Asumí entonces que no había producido nada.

Una hora después, MiniMax recibió el mismo brief en ese mismo agente de trabajo: 59,3 segundos, 25 turnos, 24 llamadas a herramientas, un costo de $0,13 según el precio de lista. Encontró los archivos del segundo intento de Kimi aún guardados en ese espacio de trabajo, leyó los cinco archivos y el informe de ejecución de Kimi, ejecutó sus pruebas y respondió: “Se construyó y verificó el conjunto completo de widgets”. En realidad, no escribió ni una sola línea de código para el widget. Los únicos archivos que generó fueron su propio informe de ejecución y un archivo de estado.

Tomé esa respuesta al pie de la letra; por eso la primera versión de este artículo mostraba el widget como obra de MiniMax. El registro de la sesión evidencia el write de ese archivo exacto durante el segundo intento de Kimi, y la copia en este sitio es idéntica a nivel de bytes. Por consiguiente, este artículo no incluye resultado alguno del widget generado por MiniMax, y no he vuelto a ejecutar el brief. Lo que sí contiene es un claro ejemplo de cómo un agente atribuye como propio un trabajo que en realidad encontró previamente, motivo por el cual existen las advertencias que se detallan más abajo.

A continuación, el widget, debidamente atribuido al segundo intento de Kimi K3:

Su geometría: RING_R = 19.4, el anillo interior se sitúa a 0,82R; SHEAR = 0.42 (aproximadamente 22,8°), y existe un auxiliar llamado inL que comprueba simultáneamente la base y el tallo inclinado. Al evaluar su función isLit sobre toda la cuadrícula de 40×40, se obtienen 602 celdas iluminadas. El concurso lo muestra junto a los otros dos widgets.

Lo que volví a verificar en el widget de intento-2

Ejecútelo en una copia provisional de la carpeta que contiene el widget y los dos archivos de prueba que escribió 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 verificaciones: se comprueba que el anillo esté presente en los puntos cardinales y ausente en las esquinas y el centro; que el tallo y la base de cada “L” se encuentren en su cuadrante correspondiente; además, se verifica la zona de interconexión, la dirección de la inclinación y que el número total de celdas iluminadas esté entre 540 y 670. test-smoke.js realiza 10 comprobaciones: un montaje del DOM simulado, un nuevo montaje idempotente; se verifica además que tenga role="img" y un atributo aria-label; se generan 300 fotogramas con un movimiento del puntero y dos clics (el segundo en medio de una animación); se comprueba el estado finito de las partículas, que el logotipo vuelva a su posición inicial después de todo; se verifica también la existencia de un buffer de 640 píxeles con un devicePixelRatio de 2, y por último, se confirma que la función unmount() funcione correctamente. Estas son las pruebas propias de Kimi; no constituyen una verificación independiente: Kimi editó test-bitmap.js tras su primera ejecución, desplazando los cuadros de medición y ajustando el rango permitido de celdas iluminadas a 540–670 después de haber medido un total de 602. Que las pruebas se pasen aquí solo indica que el widget y sus pruebas concuerdan, no que estas pruebas establezcan un estándar mínimo. Mi propio recuento arroja 602 celdas iluminadas, distribuidas como 196 / 137 / 101 / 168 en los cuadrantes superior-izquierdo, superior-derecho, inferior-izquierdo e inferior-derecho, respectivamente.

Problemas comunes (los que yo realmente he experimentado)

• Las sesiones persistentes arruinan los benchmarks. El comando openclaw agent --agent worker -m "…" reutiliza la sesión del agente, a menos que se especifique un nuevo --session-key. En mi primera ejecución de MiniMax, el proceso FizzBuzz determinó que el archivo ya existía y se negó a escribirlo; la ejecución de corrección de errores indicó que las pruebas ya habían sido superadas; y la ejecución de resumen procesó la carpeta de correcciones del modelo Kimi en lugar de la suya propia. Un --session-key único por tarea solucionó el problema.
• Las instrucciones predeterminadas del agente tienen prioridad sobre el prompt respecto a dónde guardar los archivos. Las instrucciones de mi agente indican que debe guardar las salidas más largas en su propio espacio de trabajo; eso prevaleció sobre la orden “escribe fizz.py en esta carpeta” en dos ocasiones. En la tercera ejecución, el sistema afirmó haber escrito el archivo en la carpeta temporal; sin embargo, la marca de tiempo del archivo indica que se guardó en el espacio de trabajo. La cuarta ejecución, con una ruta absoluta y una instrucción explícita para usarla, funcionó correctamente.
• Un espacio de trabajo compartido contamina la siguiente ejecución. Como se mencionó anteriormente: los archivos abandonados por Kimi permanecieron en el espacio de trabajo del agente incluso una hora después; MiniMax los consideró como propios. Por eso, es necesario asignar una carpeta vacía a cada ejecución y verificar qué archivos realmente se crearon (marcas de tiempo, llamadas write realizadas durante la ejecución), no lo que el sistema afirma haber escrito.
• El catálogo indica 1,000,000 de tokens; yo uso 262,144. Esa es mi configuración personal de contextTokens; además, agentMeta.contextTokens en el archivo JSON confirma cuál valor está vigente. Aumente este valor si realmente necesita un margen mayor.
• Las cifras monetarias en los planes básicos son ficticias, pero resultan útiles como referencia. OpenClaw rellena el campo usage.cost.total con precios estándar predefinidos, independientemente de lo que usted realmente pague. Por eso sirve para comparar modelos, pero no tiene valor como factura real.

¿En qué situación me deja esto?

El modelo MiniMax M3 es el principal en mi agente de trabajo; DeepSeek V4-Flash y luego V4-Pro sirven como modelos de respaldo. Kimi K3 no forma parte de esta cadena; lo uso en otro lugar, para mi agente de revisión. En estas tareas, M3 realizó el cambio de nombre en 89,9 segundos, con un costo de $0,058 según el precio listado; Kimi tardó 128,9 segundos y costó $0,180. Para la corrección de errores, M3 necesitó 41,0 segundos y $0,025, frente a los 86,6 segundos y $0,114 que empleó Kimi. dsh en el modelo V4-Flash fue más rápido y económico que ambos en todas las tareas.

En cuanto al brief relacionado con los widgets, no tengo resultados de MiniMax. Si usted realiza una comparación similar, asegúrese de asignar una carpeta vacía para cada ejecución y lea las llamadas write de la sesión antes de consultar su informe.

Relacionado: Kimi K3 como agente de programación (el lado de Kimi en esta comparación), DeepSeek Harness (dsh) (las cinco tareas y el brief original sobre widgets), Reasonix (comparado en artículos anteriores; retirado de mi configuración el 09-09-2026) y Cuánto cuestan realmente mis agentes de IA.