Kimi K3 en OpenClaw frente a dsh: 5/5 tareas, 9 veces más lento y 48 veces el coste

Apunté mi agente trabajador de OpenClaw a Kimi K3, el modelo de razonamiento insignia de Moonshot, y lo sometí a los mismos cinco pequeños trabajos de programación que utilicé en agosto para evaluar DeepSeek Harness (dsh). Kimi superó los cinco. Ese mismo día volví a ejecutar dsh con DeepSeek V4-Flash, dos veces. Frente a su segunda pasada (con caché caliente), Kimi tardó aproximadamente 9 veces más (309,9 s frente a 35,7 s) y costó unas 48 veces más ($0,531 frente a $0,011). Frente a la primera pasada en frío de dsh (44,8 s, $0,024), la diferencia es de unas 7 veces en tiempo y 22 veces en coste.

Luego le entregué a Kimi el brief del logotipo en pixel art con el que dsh había construido su widget. Necesitó tres intentos. El primero no produjo ningún widget. El segundo escribió un widget completo en la carpeta equivocada y mi timeout lo interrumpió antes de que lo dijera, así que al principio no me di cuenta. El tercero funcionó después de que acortara el brief y le dijera que se saltara la planificación. El widget de abajo es ese tercer intento, y la trampa de configuración del Paso 2 es la parte que más merece la pena copiar.

Configuración: en qué entorno lo ejecuté

Estos son los comandos que ejecuté en mi máquina el 11-09-2026, junto con sus resultados reales:

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'
{"id":"moonshot","enabled":true,"version":"2026.9.2"}
$ openclaw config get models.providers.moonshot.models.0.compat
{
  "supportsReasoningEffort": true,
  "supportsTemperature": false,
  "supportedReasoningEfforts": [
    "low",
    "high",
    "max"
  ]
}
$ openclaw config get models.providers.moonshot.models.0.contextTokens
262144

Dos cosas que vale la pena saber antes de ejecutar nada:

• K3 siempre realiza razonamiento. El plugin envía por defecto reasoning_effort: "max" y acepta los valores low, high y max; yo ejecuté el benchmark con --thinking max. Además, elimina cualquier configuración de muestreo (temperature, top_p y similares) ya que K3 los fija automáticamente; mi entrada de modelo indica lo mismo mediante supportsTemperature: false. Incluso el comando “Responde exactamente: PONG.” consumió 53 tokens de razonamiento, así que tenga eso en cuenta al calcular el presupuesto.
• Se anuncia un contexto de 1 millón de tokens; yo lo limito. El catálogo Moonshot de OpenClaw indica que K3 admite hasta 1,048,576 tokens de contexto. Sin embargo, en mi entrada de modelo he establecido contextTokens: 262144, de modo que las sesiones se compactan al mismo punto que mis otros modelos. Con ese límite, en la práctica se trabajará con 256k tokens, no con 1 millón. Si aumenta ese valor, el gasto en lectura desde el caché y la latencia por turno también crecerán según la duración de la sesión.

La ruta: desde lo básico hasta lo avanzado

Los pasos del 1 al 3 le permitirán tener un modelo funcional. Los pasos 4 y 5 son lo que hice a continuación.

Paso 1: instale el plugin y proporcione la clave

Estos son los pasos que se indican en la documentación oficial de OpenClaw. En mi sistema, el plugin y la clave ya estaban configurados; por eso solo ejecuté la comprobación de la última línea (su salida aparece en el bloque de configuración anterior):

openclaw plugins install @openclaw/moonshot-provider
openclaw gateway restart
openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'

El plugin lee la clave desde MOONSHOT_API_KEY. Yo la mantengo en el archivo de entorno que carga mi servicio de gateway; además, mi archivo openclaw.json no contiene ninguna clave. La documentación también ofrece el comando openclaw onboard --auth-choice moonshot-api-key si prefiere que el proceso se realice paso a paso. El endpoint por defecto es https://api.moonshot.ai/v1; para la región de China se utiliza https://api.moonshot.cn/v1 (con la opción de autenticación moonshot-api-key-cn).

El catálogo del plugin incluye K3, K2.7 Code y K2.7 Code HighSpeed. El plugin se encarga automáticamente de las particularidades de Kimi: para K2.7 es necesario omitir tanto thinking como reasoning_effort en la solicitud, algo que el plugin hace por usted. Tenga cuidado con el nombre de la variable de entorno: MOONSHOT_API_KEY corresponde a la Plataforma Abierta de Moonshot; por su parte, KIMI_API_KEY pertenece al servicio de suscripción independiente de Kimi Code (kimi/kimi-for-coding).

Paso 2: apunte su agente trabajador a K3

Las partes relevantes de mi archivo openclaw.json durante el benchmark, con mi agente trabajador renombrado como worker:

{
  agents: {
    entries: {
      worker: {
        model: {
          primary: "moonshot/kimi-k3",
          fallbacks: ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"],
        },
      },
    },
  },
  models: {
    providers: {
      moonshot: {
        baseUrl: "https://api.moonshot.ai/v1",
        api: "openai-completions",
        timeoutSeconds: 1200,
        models: [
          {
            id: "kimi-k3",
            name: "Kimi K3",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 3, output: 15, cacheRead: 0.3, cacheWrite: 0 },
            contextWindow: 1048576,
            maxTokens: 131072,
            contextTokens: 262144,
            compat: {
              supportsTemperature: false,
              supportsReasoningEffort: true,
              supportedReasoningEfforts: ["low", "high", "max"],
            },
          },
        ],
      },
    },
  },
}

Un error me causó una regresión silenciosa: en OpenClaw 2026.9.2, un bloque compat dentro de la entrada del modelo reemplaza al objeto compat propio del plugin. No se realiza una fusión de datos. En una versión anterior, mi entrada solo contenía supportsTemperature: false, lo cual eliminó silenciosamente la compatibilidad con el cálculo de esfuerzo de razonamiento del plugin. Si decide incluir un bloque compat, asegúrese de escribir todo el objeto, tal como se muestra arriba.

Paso 3: la prueba de verificación y el JSON que genera

Cada tarea de referencia consistió en una llamada como esta, utilizando una clave de sesión nueva cada vez:

openclaw agent --agent <your-agent-id> --model moonshot/kimi-k3 --thinking max \
  --session-key "<fresh-key>" --message-file prompt.txt --json > out.json

Estos son los campos importantes, extraídos del registro guardado de la tarea PONG:

$ jq '.result | {harness: .meta.agentMeta.agentHarnessId, model: .meta.executionTrace.winnerModel, usage: .meta.agentMeta.usage}' out.json
{
  "harness": "openclaw",
  "model": "kimi-k3",
  "usage": {
    "input": 15068,
    "output": 70,
    "reasoningTokens": 53,
    "total": 15138,
    "cost": {
      "total": 0.046254
    }
  }
}

harness: "openclaw" indica que la jugada se ejecutó dentro del propio bucle de OpenClaw; si la jugada se hubiera ejecutado mediante el servidor de aplicaciones Codex, aparecería "codex". winnerModel: "kimi-k3" confirma que la jugada realmente se ejecutó en K3 y no recurrió a un modelo más económico. reasoningTokens se cuentan dentro de output (el total es la suma de input y output); por lo tanto, esos 53 tokens de razonamiento forman parte de los 70 totales.

El punto de referencia: las mismas 5 tareas

Estas son las mismas cinco tareas que se ejecutaron en el artículo sobre dsh; cada una se realizó en una carpeta temporal nueva, con una sesión distinta para cada tarea de Kimi. Ese mismo día volví a ejecutar dsh en V4-Flash, asignando deepseek-v4-flash en un archivo de configuración temporal. La primera ejecución tomó 44,8 segundos y costó $0,024, con la caché vacía; la columna siguiente muestra el segundo intento, con la caché ya cargada, que es el resultado más rápido y barato que he obtenido con dsh; este valor se utiliza en todos los cálculos de este artículo, salvo que se indique lo contrario. La redacción de los prompts no fue idéntica: dsh opera desde la carpeta donde se inicia, por lo que sus prompts mencionaban “el directorio actual”; los prompts de Kimi indicaban la ruta absoluta de cada carpeta de tarea. Además, el prompt de corrección de errores de Kimi incluía la instrucción “si pytest no está disponible, instálelo primero con ‘pip install --user pytest’” (aunque pytest ya estaba instalado, Kimi nunca ejecutó ese comando). Las columnas correspondientes a V4-Pro y Gemma-4-26B provienen del artículo sobre dsh de agosto; no se volvieron a ejecutar. El tiempo total incluye todo el proceso. Los datos de tokens y costos de Kimi provienen del archivo JSON generado por OpenClaw, mientras que los de dsh provienen de su propio registro de sesión.

Tarea	Kimi K3	dsh V4-Flash (mismo día)	dsh V4-Pro (agosto, datos históricos)	Gemma-4-26B (agosto, datos históricos)
Responder “PONG” (arranque + una llamada)	✅ 6,1 s · 0 herramientas	✅ 1,7 s · 0 herramientas	✅ 2,8 s	✅ 13,2 s*
Escribir y ejecutar FizzBuzz	✅ 22,8 s · 2 herramientas (write, exec)	✅ 5,3 s · 3 herramientas	✅ 8,4 s · 2 herramientas	✅ 4,9 s · 2 herramientas
Corregir 2 errores para que las pruebas unitarias pasen (sin tocar las pruebas)	✅ 86,6 s · 6 herramientas (exec, write, edit)	✅ 11,3 s · 7 herramientas	✅ 15,8 s · 7 herramientas	✅ 10,4 s · 8 herramientas
Resumir un código de 6 módulos (<150 palabras)	✅ 65,5 s · 10 herramientas (read, exec, write)	✅ 5,1 s · 7 herramientas	✅ 10,9 s · 7 herramientas	✅ 12,1 s · 7 herramientas
Cambiar el nombre de una función en 3 archivos + pruebas; luego verificar que todo funcione	✅ 128,9 s · 9 herramientas (exec, write; un solo sed en todos los archivos)	✅ 12,3 s · 11 herramientas	✅ 18,2 s · 12 herramientas	✅ 12,2 s · 11 herramientas
Tiempo total	309,9 s	35,7 s	56,1 s	52,8 s
Tokens: entrada sin caché / lectura desde caché / salida (razonamiento)	91,470 / 355,328 / 9,990 (4,053)	6,141 / 147,328 / 4,697 (1,984)	41,4k / 107k / 3,2k	40,5k / 237k / 5,6k
Costo	≈ $0,531 ($3 / $15 / $0,30 por millón)	≈ $0,011 ($0,44 / $1,32 / $0,014 por millón)	≈ $0,072	$0 (solo costo eléctrico)

El número de herramientas indica cuántas veces se llamaron. Los datos de Kimi provienen de toolSummary.calls en el archivo JSON generado por OpenClaw; los tipos de herramientas aparecen entre paréntesis. Los datos de dsh provienen de su registro de sesión. *Primera ejecución tras cargar el modelo sin caché. Las tarifas de Kimi son las que figuran en mi entrada del catálogo de OpenClaw, usadas para calcular el costo de cada tarea; consulte la página de precios de Moonshot para valores actuales. El costo de dsh V4-Flash se calcula con las mismas tarifas máximas que en el artículo original (tarifas de DeepSeek); los datos de V4-Pro y Gemma provienen de dicho artículo.

Lo que revela la tabla:

• 5/5 en todas las columnas. Ninguna de estas tareas supuso un problema para Kimi. Respondió “PONG” tal como se pedía; FizzBuzz imprimió las 15 líneas correctas. Para corregir los errores, bastaron dos cambios de una sola línea (una instrucción return que faltaba y un == 1 que debía ser == 0); las pruebas siguieron intactas y todas pasaron. El resumen consistió en un único párrafo de 107 palabras que describía correctamente seis módulos idénticos encargados de obtener, transformar y validar datos. Para el cambio de nombre, Kimi usó un solo comando sed en cuatro archivos, lo cual también renombró el método de prueba; tras ello, las cuatro pruebas pasaron. Mi prompt pedía una búsqueda vacía mediante grep en toda la carpeta; como allí se encontraba mi propia copia del prompt, Kimi aplicó el mismo sed a ese archivo y lo mencionó en su respuesta. Se trata de tareas sencillas; no probé una refactorización que implicara múltiples archivos.
• Kimi dedica más recursos al razonamiento. K3 consumió 53, 241, 315, 1.586 y 1.858 tokens de razonamiento en las cinco tareas (4.053 en total). dsh en V4-Flash también razona, pero en menor medida: 0, 52, 834, 5 y 1.093 tokens (1.984 en total). La mayor parte del tiempo adicional empleado por Kimi corresponde a procesos de razonamiento y pasos adicionales.
• La caché marca la diferencia en el costo. Cada tarea de Kimi comienza con unos 15.000 tokens correspondientes al prompt del sistema y a las definiciones de herramientas. En total, Kimi envió 91.470 tokens de entrada sin caché y leyó 355.328 tokens desde la caché (157.952 solo en la tarea de renombrar); ello significa que el 80 % de sus tokens provino de la caché, a un costo de $0,30 por millón en lugar de $3. De haberse cobrado todos los tokens como entrada sin caché, el costo habría sido de aproximadamente $1,49 en lugar de $0,53; la caché redujo el gasto a un tercio. No obstante, esa tarifa sigue siendo elevada: $0,30 equivale a unas 21 veces el precio de lectura desde caché de dsh V4-Flash, que es de $0,014 por millón.
• Para tareas pequeñas, V4-Flash es la mejor opción. Comparado con el segundo intento (con caché ya cargada), dsh fue unas 9 veces más rápido y 48 veces más barato. En comparación con el primer intento (modelo sin caché), resultó ser unas 7 veces más rápido y 22 veces más económico. En ambos casos, el resultado final es idéntico. Solo para la tarea de renombrar, Kimi necesitó 128,9 segundos y $0,180; dsh, en cambio, lo hizo en 12,3 segundos y por solo $0,0043.

Kimi K3 en OpenClaw frente a dsh: un vistazo rápido

Ambos son bucles de agente que leen archivos, ejecutan comandos del shell y cobran por cada token procesado. La diferencia radica en quién desarrolla cada uno y en cómo se controlan.

	Kimi K3 en OpenClaw	dsh
Quién lo desarrolla	Modelo: Moonshot AI. Bucle de agente: OpenClaw	DeepSeek (modelo y herramientas), MIT
Llamarlo desde un script	openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json	dsh --profile headless "…"
Cambiar de modelo	El parámetro model.primary en el archivo openclaw.json	~/.dsh/settings.yaml
Benchmark sin interfaz, 5 tareas pequeñas	309,9 s, ≈ $0,531, 5/5	35,7 s, ≈ $0,011, 5/5 (V4-Flash; en primera ejecución tardó 44,8 s, ≈ $0,024)
Creación de un widget de pixel art, con el mismo encargo	3 intentos; dos de ellos produjeron un widget. El que se muestra aquí tomó 7,4 minutos y costó ≈ $0,47	2 intentos; el que funcionó tardó 25 minutos y costó ≈ 49 centavos
Versión probada	OpenClaw 2026.9.2, plugin de Moonshot 2026.9.2	0.1.1-rc.2 (versión preliminar para desarrolladores)

En comparativas anteriores en este sitio aparecía una columna de Reasonix. El 9 de septiembre de 2026 retiré Reasonix de mi máquina, por lo que ya no figura aquí; su artículo de julio permanece como registro histórico. También probé MiniMax M3 con el mismo conjunto de pruebas; MiniMax es una empresa distinta a Moonshot, y ese experimento cuenta con su propio análisis.

La prueba divertida: el mismo encargo para crear un widget, Kimi vs dsh

En el artículo de dsh, la “prueba divertida” consistía en crear un widget de arte pixelado con el logo de este sitio, desarrollado por dsh mediante V4-Flash a partir de un encargo escrito. Le entregué a Kimi ese mismo encargo, sin modificaciones, y cronometré el proceso. En resumen, se pedía lo siguiente:

• Un único archivo en JavaScript puro, ll-pixel-logo.js, sin dependencias ni llamadas a redes; este archivo debe montar un canvas HiDPI en cada elemento .ll-pixel-logo y exponer la función window.LLPixelLogo.mount(el). Además, se requiere un archivo de demostración index.html y un README.md.
• Arte generado procedimentalmente, no un bitmap dibujado a mano: una cuadrícula de 40×40 celdas iluminadas según la función isLit(col, row); se trata de un anillo (desde 0.82R hasta R) y dos “L” inclinadas, cada una compuesta por dos paralelogramos distorsionados.
• Interacciones: repulsión del puntero con efecto de retorno elástico, un efecto especial al hacer clic, una animación sutil en reposo, compatibilidad con la opción “prefers-reduced-motion”, y una autoprueba (node --check además de un conteo de celdas iluminadas sin necesidad de DOM).

El desafío de los widgets de arte pixelado incluye el texto completo del encargo.

Cómo lo manejó Kimi:

• Intento 1 (el encargo original, sin modificaciones): se detuvo tras 8.8 minutos; no generó código para el widget y costó aproximadamente $0.31. K3 analizó el logo de referencia, reflexionó sobre la geometría y los pasos a seguir, pero no escribió ningún archivo solicitado. El primer intento de dsh también fracasó de forma similar (una iteración de 10 minutos en la que intentaba dibujar un bitmap mentalmente), aunque en ese momento el encargo permitía usar bitmaps dibujados a mano.
• Intento 2 (el mismo encargo, nueva sesión): se creó un widget completo, pero en una ubicación incorrecta; costó aproximadamente $0.72. Tras unos ocho minutos, escribió un archivo ll-pixel-logo.js de 323 líneas, además de una página de demostración, un README y dos archivos de prueba; ejecutó dichas pruebas y las ajustó hasta que pasaron, y luego redactó un breve informe. Todo este contenido se guardó en el espacio de trabajo del agente asignado, no en la carpeta que mi script vigilaba; la sesión alcanzó el límite de 15 minutos impuesto por mi script antes de que Kimi respondiera. Desde mi perspectiva, el intento 2 no produjo nada, así que no esperé: inicié el intento 3 a los siete minutos aproximadamente.
• Intento 3 (un encargo abreviado y con instrucciones específicas): tomó 7.4 minutos; se generaron los tres archivos solicitados y costó $0.47. Conservé los requisitos de entregables, arte e interacciones; coloqué TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. al inicio del texto, y reemplacé la sección de pruebas por una línea que decía Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. El widget resultante cuenta con repulsión del puntero con efecto elástico, animaciones al hacer clic, destellos sutiles en reposo y compatibilidad con “prefers-reduced-motion”. Mis propias comprobaciones aparecen más abajo.

En total, los tres intentos tardaron 8.8, 15 y 7.4 minutos respectivamente, y costaron $0.31, $0.72 y $0.47: un gasto total de $1.50 por la creación de dos widgets. El coste del intento 3 proviene de su propio recibo JSON; los intentos 1 y 2 no generaron recibos, por lo que sus cifras corresponden a los costes por mensaje en OpenClaw para cada sesión, sumados; esta suma coincide con el monto indicado en el recibo del intento 3.

Una hora después, el widget creado en el intento 2 reapareció: un agente MiniMax M3 ejecutado en el mismo entorno detectó los archivos, ejecutó sus pruebas y las reportó como su propio trabajo. Este relato se detalla en el artículo sobre MiniMax M3; ambos widgets de Kimi se exhiben junto al de dsh en el desafío de los widgets de arte pixelado.

Lo que Kimi produjo, empezando por las primeras ~30 líneas del archivo ll-pixel-logo.js:

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Self-contained vanilla JS: no dependencies, no build step, no network.
 * Embed on any page with:
 *
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * Every .ll-pixel-logo element gets a <canvas> mounted inside it at load.
 * Programmatic API: window.LLPixelLogo.mount(el) -> instance.
 *
 * Art: 40x40 pixel grid, rasterised procedurally from geometry (ring + two
 * interlocking italic Ls). Interactions: pointer repulsion with spring-back,
 * click/tap shatter-and-reassemble, idle shimmer/twinkle, reduced-motion
 * support. Mouse and touch. No scroll hijacking (all listeners passive).
 */
(function () {
  'use strict';

  // -- constants ------------------------------------------------------------
  var VERSION = '1.0.0';
  var GRID = 40;                                // logical grid: GRID x GRID cells
  var BLUE   = [31, 63, 143];                   // #1f3f8f logo blue
  var HILITE = [46, 168, 255];                  // #2ea8ff highlight blue
  var AMBER  = [255, 182, 74];                  // #ffb64a twinkle amber
  var CYAN   = [0, 230, 207];                   // #00e6cf max-displacement glow

  var CENTER = GRID / 2;                        // grid centre coordinate (20)
  var R_OUT = 19;                               // ring outer radius (cells)
  var R_IN = 0.82 * R_OUT;                      // ring inner radius
  var SLANT = Math.tan(20 * Math.PI / 180);     // ~20 deg italic shear

Kimi genera cada “L” mediante dos paralelogramos (un tallo y una base inclinados) usando una pequeña función auxiliar makeL; verifica si una celda debe iluminarse con la función inPara dentro de isLit. Todas las constantes de ajuste (radio del anillo entre 0.82R y R, ángulo de inclinación de 20° calculado con Math.tan, parámetros de elasticidad y amortiguación) se agrupan en un único bloque al inicio del archivo. Los archivos resultantes (el ll-pixel-logo.js de 397 líneas, el index.html de 40 líneas y el README.md de 79 líneas) se encuentran en /assets/uploads/2026/09/kimi-codex/.

El widget de dsh (su código fuente, citado en el artículo sobre dsh) se crea de forma idéntica: ambos generan un anillo y dos “L” inclinadas a partir de cálculos geométricos; ambos exponen window.LLPixelLogo.mount y respetan la opción prefers-reduced-motion. No obstante, sus constantes difieren: dsh emplea un radio exterior de 19.7, uno interior de 0.80R y un ángulo de inclinación de 0.453 (aprox. 24°); Kimi usa 19, 0.82R y 20°. Además, los trazos de Kimi son más finos: sus tallos y bases miden 3 celdas de grosor, mientras que los de dsh tienen 4.2 celdas de ancho y 3.8 de altura. Por eso el logo de Kimi ilumina 510 celdas frente a las 656 del de dsh. Ninguno replica exactamente el logo de referencia, aunque ambos resultan reconocibles a primera vista. El segundo intento de dsh también generó una prueba unitaria en Node y, sin que se le solicitara, un script Playwright; en cambio, al tercer intento de Kimi se le indicó omitir las pruebas, y así lo hizo.

Comandos de verificación que ejecuté en el widget de Kimi

Los volví a ejecutar el 11-09-2026 sobre la copia que sirve esta página, desde dentro de /assets/uploads/2026/09/kimi-codex/:

$ wc -l ll-pixel-logo.js
397 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "node --check passed"
node --check passed

Otras dos verificaciones fueron propias y privadas; las realicé con dos pequeños scripts auxiliares (de menos de 20 líneas cada uno) que no he publicado. Por eso aquí les indico el método en lugar de comandos que puedan copiar directamente:

• Conteo de celdas iluminadas. Cargué el archivo del widget en Node con un DOM simulado (objetos canvas, window y document sin funcionalidad real). Luego tomé la función isLit(col, row) definida en el propio archivo y la llamé para cada celda de la cuadrícula 40×40, contando las celdas iluminadas por cuadrante. El resultado fue 510 celdas: 124 en la parte superior izquierda, 103 en la superior derecha, 160 en la inferior izquierda y 123 en la inferior derecha.
• Comprobación de montaje. Utilizando el mismo DOM simulado, confirmé que el archivo define window.LLPixelLogo como un objeto, y que al llamar a mount() sobre un elemento simulado se obtiene un objeto en lugar de producirse un error.

Solo el anillo (celdas cuyos centros se encuentran entre 0,82R y R, siendo R = 19) abarca 352 de las 510 celdas; eso deja 158 celdas para formar las dos letras “L”. Los scripts auxiliares son míos, no de Kimi; además, solo sirven como pruebas básicas, no como ejecuciones en navegador: la página que está leyendo ahora es el resultado de dicha ejecución en el navegador.

¿Por qué esto no se ejecuta mediante Codex?

OpenClaw también incluye un plugin de integración con Codex que ejecuta el servidor de aplicaciones de Codex (gestiona @openai/codex 0.153.4). Nada en este artículo se ejecuta a través de dicho plugin, ya que no puede manejar este modelo: su comprobación de rutas, configuredModelRouteNeedsCodex, devuelve false para cualquier proveedor cuyo ID normalizado no sea openai. El ID del proveedor de Moonshot es moonshot, por lo que una ruta como moonshot/kimi-k3 nunca llega al entorno de ejecución de Codex. “Compatible con OpenAI” no significa “compatible con el plugin de Codex”.

Por eso, Kimi se ejecuta aquí dentro del propio bucle de OpenClaw, de la misma forma que cualquier otro modelo nativo de OpenClaw. No se obtienen funcionalidades como la reanudación de hilos en Codex, su sistema de compactación, el puente de herramientas dinámicas ni el modelo de ejecución del servidor de aplicaciones. Si necesita esas características con Kimi, la solución conocida es codex-router, un puente local que redirige las solicitudes de Codex a un endpoint en 127.0.0.1:4202 y luego las reenvía a Kimi (según indica su README). Para que el plugin de integración reconozca esta configuración, el parámetro appServer.homeScope debe establecerse en "user"; esto hace que el plugin comparta su carpeta ~/.codex (o $CODEX_HOME) con OpenClaw, en lugar de aislar el estado de Codex por cada agente. Aún no he decidido si me parece aceptable este enfoque, así que no lo he implementado todavía.

Problemas comunes (los que yo realmente he experimentado)

• Los briefs creativos abiertos pueden hacer que un modelo de razonamiento se estanque, y un tiempo de espera agotado puede ocultar un éxito. En el primer intento, el modelo pensó durante 8,8 minutos sin escribir ningún código para el widget; en el segundo intento, sí generó un widget funcional, pero se le agotó el tiempo y los archivos quedaron en una carpeta incorrecta, por lo que pareció ser otro fracaso. La solución fue utilizar un brief más breve, con el siguiente texto: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop., además de indicar claramente la carpeta de destino. K3 sigue razonando con ese texto; simplemente ya no planifica indefinidamente. Independientemente del código de salida, hay que revisar lo que el modelo escribió y también examinar el espacio de trabajo del agente.
• Un código de salida de error no significa necesariamente que la tarea haya fallado. Hay que comprobar los archivos. La primera ejecución del programa FizzBuzz finalizó con código 1; el sistema no identificó ningún modelo adecuado para resolver el problema y el mensaje final fue “⚠️ Se ha alcanzado el límite de solicitudes a la API. Por favor, inténtelo más tarde.” Sin embargo, ya había creado el archivo fizz.py, y este funcionaba correctamente. Al volver a ejecutar el programa, se respondió “Ya se ha creado y ejecutado”, y solo ese mensaje indicaba que la tarea estaba completa. Mi script guardaba en el mismo archivo el JSON de cada ejecución; por eso el registro de la primera ejecución se sobrescribió. No obstante, su código de salida y su mensaje final permanecen en el historial de la sesión que realizó el benchmark. En la tabla se muestra el resultado de una ejecución posterior, realizada en una sesión nueva.
• No copie una carpeta de trabajo de una ejecución terminada en otro entorno. Configuré la carpeta para las correcciones de errores de Kimi copiando los archivos de la carpeta terminada de dsh, después de que este ya hubiera corregido los errores; por eso la primera ejecución de Kimi simplemente verificó que los archivos estaban ya corregidos. Para evitar esto, hay que copiar los archivos desde una fuente “limpia”. Restablecí la carpeta y volví a ejecutar el proceso en una sesión nueva; en la tabla se muestra el resultado de esa segunda ejecución.

¿Qué significa esto para mí?

En estas cinco tareas, Kimi K3 dio respuestas correctas, pero fue lento y costoso. Para tareas sencillas, dsh en V4-Flash realizó el mismo trabajo en aproximadamente una novena parte del tiempo y por solo 1/48 del precio (según los resultados del benchmark). Tras este test, trasladé mi agente trabajador de Kimi a MiniMax-M3; Kimi K3, por su parte, permaneció donde ya estaba: detrás de mi agente de revisión, donde una respuesta más lenta y cuidadosa justifica el costo adicional.

Relacionado: DeepSeek Harness (dsh) (el sistema con el que hice la comparación; de allí provienen el benchmark y las instrucciones), El concurso de widgets de arte pixelado (donde se compararon los tres widgets lado a lado), MiniMax M3 (el mismo conjunto de pruebas en el modelo que utiliza mi agente trabajador desde el 11 de septiembre de 2026), y Cuánto cuestan realmente mis agentes de IA (una comparación más amplia de precios).