Kimi K3 iguala a GPT-5.6. Tarda 4,6 veces más

Artificial Analysis da 61 puntos a Kimi K3 y a GPT-5.6 medium en el Coding Agent Index, pero Kimi necesita 23,8 minutos frente a 5,2: tarda 4,6 veces más [1]. GLM-5.2 sale peor: su precio de entrada de 1,40 $ acaba en 6,51 $ por intento [2]. Creo que son capaces, pero ninguno resulta tan barato como promete su precio.

La comparación en una tabla: Kimi compite y GLM-5.2 queda atrás

Kimi K3 compite, pero no domina: iguala a GPT-5.6 Sol medium en el índice combinado, lidera la prueba de terminal, queda atrás en comprensión de repositorios y tarda mucho más. GLM-5.2 va por detrás de los otros tres modelos con estos ajustes y no lidera ninguna medición [1] [2].

Medición	Kimi K3	GLM-5.2	Sol medium	Opus 5 medium
Coding Agent Index	61	43	61	62 (El mejor valor de la fila)
DeepSWE, %	64	29	64	63
Terminal-Bench v2, %	84 (El mejor valor de la fila)	72	78	79
SWE-Atlas Q&A, %	37	29	40	44 (El mejor valor de la fila)
Coste por tarea, $	3,18	6,51	2,99 (El mejor valor de la fila)	3,14
Tiempo activo, min	23,8	25,1	5,2 (El mejor valor de la fila)	12,2

El empate entre Kimi y Sol medium permite la comparación más útil: ambos obtienen 61 puntos y sus costes medidos por tarea son parecidos, 3,18 $ y 2,99 $ respectivamente [1]. La diferencia está en cómo llegan al resultado. Kimi consume 23,8 minutos activos y 10,6 millones de tokens por tarea, frente a los 5,2 minutos y 5,8 millones de Sol. Opus 5 medium muestra algo similar: supera a Kimi por un punto, cuesta cuatro céntimos menos y termina aproximadamente en la mitad de tiempo [2].

Los modelos occidentales siguen marcando las puntuaciones más altas del índice. Sol max y Opus 5 xhigh llegan a 67, con costes de 7,08 $ y 8,23 $ por tarea, mientras que Opus también lidera la comprensión de repositorios con un 55 % en SWE-Atlas Q&A [1] [2]. Fable 5 max les sigue con 66 puntos, aunque cuesta 11,71 $ por tarea [2]. Kimi sigue compitiendo donde más destaca: su 84 % en Terminal-Bench v2 supera el 83 % de Sol high y se acerca a los modelos con esfuerzo max [1] [2].

La comprensión de repositorios es su debilidad más clara. Kimi obtiene un 37 % en el componente de preguntas sobre código, por debajo del 40 % de Sol medium y bastante lejos de las configuraciones de Claude [1] [2]. Esto importa menos al empezar un proyecto, pero en un repositorio existente con 300.000 líneas, entender lo que ya existe es buena parte del trabajo.

¿Por qué genera tanta expectación Kimi K3? Por sus resultados en el navegador

Las posiciones de Kimi en las arenas explican gran parte de la expectación, porque muestran que la gente prefiere su trabajo en el navegador incluso cuando las pruebas de agentes más amplias revelan puntos débiles. Lidera la clasificación de código fullstack de Arena [3] y ocupa el segundo puesto en la WebDev Arena, por delante de Claude Fable 5 y GPT-5.6 [4]. Los pesos abiertos y unos precios por token que parecen bajos completan el atractivo.

Los resultados de las arenas importan porque miden qué resultado prefiere la gente, no si una batería de tests pasa. En la clasificación fullstack del 24 de julio de 2026, Kimi K3 max ocupa el primer puesto con 1.664 puntos, por delante de GPT-5.6 Sol con 1.633 y Fable 5 con 1.623 [3]. Cuatro días después, Opus 5 max lideraba la WebDev Arena con 1.712 puntos y Kimi era segundo con 1.682 tras 3.777 votos, por delante de Fable 5, Sol y GLM-5.2 [4]. Está claro que a los usuarios les gusta lo que Kimi construye en el navegador.

Los datos publicados por ambas empresas respaldan la afirmación de que sus pesos son abiertos. Moonshot presenta Kimi K3 como el primer modelo de pesos abiertos con 2,8 billones de parámetros, junto con una ventana de contexto de un millón de tokens, visión integrada y una API que cuesta 3 $ por millón de tokens de entrada y 15 $ por millón de tokens de salida [5]. Z.ai publica GLM-5.2 con 753.000 millones de parámetros y licencia MIT [6], a precios de 1,40 $ para la entrada y 4,40 $ para la salida [7]. Si solo miramos el precio de lista, ambos parecen mucho más baratos que sus competidores occidentales.

El propio post de lanzamiento de Moonshot es más prudente de lo que sugiere esa comparación. Reconoce que K3 sigue por detrás de Fable 5 y GPT-5.6 Sol, con “una diferencia apreciable en la experiencia de uso” frente a ambos [5]. Las mediciones independientes concretan esa diferencia, sobre todo en velocidad y comprensión de repositorios. Conviene recordar la prudencia de la propia Moonshot cada vez que se señala a un laboratorio chino como la causa de algo, y es lo que defiendo en la marca de agua de Claude responde a la UE y no a los laboratorios chinos.

¿Qué mide el Coding Agent Index? Sistemas de agentes completos

El Coding Agent Index mide sistemas completos formados por un modelo y un agente en tareas de ingeniería de software, terminal y preguntas sobre repositorios. Artificial Analysis combina con el mismo peso 113 tareas DeepSWE, 84 tareas Terminal-Bench v2 y 124 preguntas SWE-Atlas Q&A en la versión 1.3 [8].

Ese límite importa porque Kimi se ejecutó en Kimi Code CLI, GLM-5.2 en Claude Code, Sol en Codex y los modelos Claude en Claude Code [1] [2]. Por tanto, cada puntuación refleja en conjunto el modelo, su agente y el nivel de esfuerzo elegido. La tabla compara configuraciones que funcionan, pero no puede decirnos cómo quedarían los mismos pesos dentro de un harness neutral.

¿Son más baratos Kimi K3 y GLM-5.2? No por tarea completada

No. El coste de una tarea completada depende de cuántos tokens necesita el agente y de la frecuencia con la que acierta, no solo del precio de cada token. GLM-5.2 es el ejemplo más claro: tiene el precio de lista más bajo de esta comparación, pero cada intento cuesta más que en todas las configuraciones occidentales con esfuerzo medium [2] [7].

Anthropic convirtió en permanentes los precios iniciales de Claude Sonnet 5: 2 $ por la entrada y 10 $ por la salida por millón de tokens [9]. Kimi K3 cuesta 3 $ y 15 $ [5], así que tanto la entrada como la salida son un 50 % más caras que en Sonnet. Kimi no ofrece una ventaja de precio de lista frente a ese modelo.

Más arriba en la tabla de precios, Anthropic cobra 5 $ por la entrada de Opus 5 y 25 $ por la salida, mientras que Fable 5 cuesta 10 $ y 50 $ [9]. OpenAI fija GPT-5.6 en 5 $ y 30 $, o 10 $ y 45 $ en su nivel de contexto largo [10]. Z.ai rebaja a todos con GLM-5.2 a 1,40 $ y 4,40 $, más lecturas de caché a 0,26 $ [7]. Todas las cifras son por millón de tokens.

Ni siquiera esas unidades se pueden comparar a la perfección. Los fabricantes usan tokenizadores distintos, y Anthropic afirma que el actual produce cerca de un 30 % más de tokens para el mismo texto que su tokenizador anterior [9]. El quickstart de Moonshot también indica que Kimi K3 siempre razona, que ese modo no se puede desactivar y que el esfuerzo predeterminado es max [11]. Los tokens de razonamiento ocultos también aparecen en la factura.

precio de lista, por millón de tokens de entrada

1,40 $

el modelo más barato de esta comparación

medido, por tarea intentada

6,51 $

dentro de Claude Code, 25,1 minutos activos

derivado, por tarea resuelta

15,14 $

coste por intento dividido por la tasa de acierto del 43 %

Cuando comparo tareas resueltas en lugar de intentos, Sol medium, Opus 5 medium y Kimi K3 quedan cerca, con unos 4,90 $, 5,06 $ y 5,21 $. GLM-5.2 salta a 15,14 $, cerca de tres veces más. El precio por token más bajo del grupo produce el coste estimado más alto por resultado satisfactorio.

La estimación sigue siendo favorable para los intentos fallidos porque excluye el tiempo del ingeniero. Diez minutos dedicados a revisar un fallo cuestan más que cualquiera de los cargos de la figura, así que la tasa de acierto pesa mucho más que el precio por token en cuanto una persona tiene que examinar el resultado. Aclarado el coste, la siguiente pregunta es qué tareas encajan lo bastante bien con Kimi como para aceptar su lentitud.

¿Para qué sirve Kimi K3? Terminal y trabajo fullstack

Kimi K3 encaja mejor en tareas que dependen mucho del terminal, desarrollo web fullstack y ejecuciones largas de agentes, sobre todo cuando un equipo necesita pesos abiertos y ejecutar el modelo en su propia infraestructura. Las mediciones independientes, los votos de las arenas y los resultados de Moonshot apuntan a esos usos [1] [3] [5]. No respaldan tratar a Kimi como un sustituto barato para trabajar en grandes repositorios existentes.

El resultado de terminal aparece tanto en las pruebas independientes como en las del fabricante: Artificial Analysis midió un 84 % en la CLI de Kimi, mientras que Moonshot obtuvo un 88,3 % en su configuración preferida [1] [12]. K3 también lidera la tabla SWE-Marathon de Moonshot con 42 puntos, aunque las notas importan. Fable 5 usó modelos de respaldo en el 35 % de sus tareas y algunas filas de Kimi ejecutaron una rama preliminar calibrada para hardware H20 [12]. Si añadimos su codificador de visión dedicado y la ventana de contexto de un millón de tokens, el flujo que Moonshot propone entre el código y las capturas en vivo tiene una base técnica creíble [5] [12].

Esas ventajas tienen límites prácticos. El 37 % en las preguntas sobre código convierte a Kimi en una opción dudosa cuando la tarea depende de comprender el repositorio [1], y sus 23,8 minutos activos por ejecución obligan a lanzar agentes en paralelo o a esperar. Alojarlo por cuenta propia tampoco es sencillo: 2,8 billones de parámetros requieren cerca de 1,4 TB solo para los pesos con cuantización de 4 bits, antes de contar la caché KV y la sobrecarga del servicio. Una instalación práctica necesita un clúster de servidores, no una estación de trabajo.

También hay que revisar las condiciones legales antes de adoptarlo. Un negocio de modelo como servicio con más de 20 millones de dólares de ingresos totales necesita un acuerdo distinto con Moonshot, mientras que los productos con más de 100 millones de usuarios activos mensuales o 20 millones de dólares de ingresos mensuales deben mostrar “Kimi K3” de forma destacada. El uso interno queda exento [13]. Los términos estándar de la API también permiten a Moonshot usar el contenido del cliente para prestar, mantener, desarrollar, apoyar y mejorar sus servicios, mientras que las restricciones de entrenamiento se gestionan mediante acuerdos empresariales separados [14]. Yo exigiría esas restricciones por escrito antes de enviar un repositorio propio a la API pública.

¿Por qué falla GLM-5.2 en Claude Code? El agente importa

La caída de nueve puntos de GLM-5.2 en Terminal-Bench debe leerse como una advertencia sobre la configuración del agente, no como prueba de que el modelo sea débil. Obtiene un 81 % en el harness Terminus de Z.ai y un 72 % dentro de Claude Code [6] [2]. Nadie fuera de Z.ai conoce la causa exacta, pero las herramientas, la recuperación de errores, la caché o las convenciones del agente podrían explicar la diferencia.

Sea cual sea la causa, esa configuración rinde mal. GLM-5.2 obtiene 43 en el índice y un 29 % tanto en DeepSWE como en las preguntas sobre código. Con 6,51 $ y 25,1 minutos activos por intento, también es la configuración más lenta de la comparación [2]. Sus precios de 1,40 $ para la entrada y 4,40 $ para la salida nunca se convierten en un coste bajo por tarea.

La ficha de Z.ai muestra por qué importa el sistema que rodea al modelo. Su resultado de 62,1 en SWE-Bench Pro usa OpenHands con un prompt de instrucciones adaptado, DeepSWE se ejecuta en contenedores aislados con límites de dos horas y Terminal-Bench usa Terminus con un presupuesto de cuatro horas [6]. Son mediciones válidas de GLM-5.2 en una configuración elegida para él, pero no predicen cómo se comportará en otro agente.

GLM-5.2 todavía tiene un uso plausible en tareas ejecutadas en infraestructura propia y verificadas de forma automática. Sus 753.000 millones de parámetros y la licencia MIT lo convierten en el modelo más fácil de alojar de los dos [6], mientras que el precio de entrada de 1,40 $ encaja con codemods a gran escala o migraciones respaldadas por comprobaciones deterministas. Esas comprobaciones pueden rechazar el 57 % de intentos fallidos sin revisión manual. Si un ingeniero tiene que examinarlos, el descuento por token deja de ahorrar dinero. Alojarlo tiene su propio coste, como vi con DeepSeek V4.1 Flash, cuya API barata viene con pesos abiertos enormes.

Cómo leer una clasificación de código: compara primero el harness

Empieza por el harness, la versión del benchmark y la tarea medida, porque una puntuación pertenece a esa configuración. La distancia entre el éxito de Kimi en las arenas y los resultados de GLM, que cambian según el harness, muestra por qué el nombre del modelo y la cifra final no bastan.

Señal	Qué premia	Qué no te puede decir
DeepSWE, 113 tareas	completar tareas de ingeniería de principio a fin	el encaje con las convenciones de tu código
Terminal-Bench v2, 84 tareas	llevar una shell a un estado final verificado	la comprensión de un gran repositorio existente
SWE-Atlas Q&A, 124 tareas	responder preguntas técnicas sobre código	la capacidad de implementar el cambio que describe
WebDev y Fullstack Arena	lo que la gente prefiere en comparaciones directas	corrección, tests, seguridad y mantenibilidad
Fichas de los fabricantes	el modelo en su mejor configuración	si sus filas se pueden comparar entre sí

La infraestructura es la primera fuente de incertidumbre. El equipo de ingeniería de Anthropic cambió una puntuación de Terminal-Bench 2.0 en seis puntos porcentuales solo al modificar los límites de recursos, mientras que los errores de infraestructura bajaron del 5,8 % al 0,5 % al aumentarlos [15]. El equipo concluyó que las diferencias inferiores a unos tres puntos merecen escepticismo hasta que las configuraciones estén documentadas y sean equivalentes. Kimi y Sol medium entran en ese margen, así que su misma puntuación indica paridad, no una victoria de ninguno.

El segundo problema es la falta de uniformidad entre las configuraciones. Moonshot ejecuta cada competidor en un harness diferente, usa modelos de respaldo en algunas filas e incluye un benchmark propio. Fable 5 recurrió a modelos de respaldo 13 veces y rechazó una de las 80 tareas de esa prueba [12]. Moonshot revela los detalles, pero la comparación pierde gran parte de su valor cuando un resumen omite esas notas.

Por último, la versión del benchmark debe coincidir. Artificial Analysis asigna versiones a su índice porque la mezcla de tareas cambia, y aquí corresponde la v1.3 [8]. Las puntuaciones de versiones distintas no se pueden comparar directamente aunque el benchmark conserve el nombre. Una comparación útil debe indicar el harness, el nivel de esfuerzo, el presupuesto de la tarea y la versión. El recálculo de Muse Spark 1.3 en el índice de Artificial Analysis muestra cuánto puede mover un puesto un cambio de versión.

Mi reparto: Kimi para UI, GLM tras comprobaciones automáticas

Yo probaría Kimi K3 en proyectos fullstack nuevos y trabajo con mucha UI, mientras que GLM-5.2 se quedaría detrás de comprobaciones automáticas y dentro de un harness nativo. Para el resto, seguiría repartiendo el trabajo entre Claude y GPT-5.6 según la tarea:

El trabajo	Mi elección hoy
Cambios rutinarios con buenos tests	Sonnet 5, a su precio permanente de 2 $/10 $
Bucles rápidos de agentes y trabajo de terminal	GPT-5.6 con esfuerzo medium o high
Trabajo en un gran repositorio existente	Opus 5 con esfuerzo medium o high
Proyectos fullstack nuevos y builds con mucha UI	Kimi K3, respaldado por los votos de las arenas
Trabajo masivo con verificación automática	GLM-5.2 en su harness nativo, como prueba piloto
Escalación cuando todo lo demás falla	Fable 5, con moderación

La tabla sigue la misma regla que utilicé durante la semana del lanzamiento de Opus 5: compara el coste de los cambios aprobados, no solo el precio de los tokens. Así, Kimi queda donde sus resultados de terminal y arena son más sólidos, mientras que GLM permanece detrás de comprobaciones automáticas.

Dos mediciones cambiarían mis elecciones. Kimi K3 tendría que mantener sus 61 puntos en un harness neutral como Claude Code o Codex, lo que separaría la capacidad del modelo de la ventaja de Kimi Code CLI. GLM-5.2 necesita la prueba contraria: una ejecución independiente en su agente nativo por parte de alguien que no lo venda. Hasta entonces, ambos modelos muestran una capacidad útil en tareas concretas, pero ninguno ofrece la ventaja general de costes que sugiere su precio por token.