Kimi K3: el modelo de Moonshot para código, agentes y frontend

Kimi K3 es el modelo generalista más ambicioso que ha sacado Moonshot hasta la fecha. Y viene con músculo: 2,8 billones de parámetros, una ventana de contexto de 1.048.576 tokens (un millón redondo) y una orientación descarada a software engineering, trabajo agéntico y frontend generativo.

Si vienes de la familia K2, la diferencia salta a la vista. Esta vez no es una variante especializada en código, es el modelo grande que muchos esperaban.

La pregunta que te interesa no es «¿existe?», sino «¿para qué me sirve a mí y cuándo compensa usarlo?». A eso vamos. Esto es lo que vas a encontrar:

• Qué trae K3 por dentro y qué capacidades expone la API.
• Para qué tipo de trabajo pinta bien (spoiler: frontend generativo y tareas largas).
• Su carácter más marcado: razona siempre a tope, sin término medio.
• Cuánto cuesta y por qué ya no es «el chino barato».
• Qué dicen benchmarks, foros y fuentes chinas, y cómo leerlos sin tragártelos enteros.
• Qué modelo usaría yo para cada tipo de tarea.

Vamos al lío.

🔑 Resumen en una frase: Kimi K3 es un modelo frontier con un punto fuerte clarísimo en programación visual, repositorios grandes y agentes. Compite de tú a tú con lo mejor en varios frentes, y en otros todavía tiene que demostrar que aguanta el ritmo de GPT-5.6 Sol o Fable 5.

Curso gratis · paso a paso

Un modelo así de potente rinde mejor con método

Antes de soltar a K3 sobre tu repo, dale un plan. En este curso recorres un ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto real y en modo asistido: lo ves funcionar entero antes de coger tú el volante.

Entra en el curso gratis →

Qué es Kimi K3 por dentro ¶

La documentación pública de K3 se centra en cómo integrarlo, así que empecemos por lo que la API deja claro.

K3 usa una arquitectura basada en Kimi Delta Attention, un mecanismo híbrido de atención lineal, acompañado de Attention Residuals. Trae comprensión visual nativa, acepta texto, imágenes y vídeo, y mantiene el modo de razonamiento activado siempre. Moonshot lo posiciona sin rodeos para tres cosas: ingeniería de software, knowledge work y razonamiento profundo.

Moonshot es parco con la letra pequeña de la arquitectura. No detalla cuántos parámetros se activan por token ni la topología exacta del MoE, y tampoco entra en datos de entrenamiento o coste computacional. Es lo habitual en esta casa: publican integración antes que interioridades. Si eres del club de los pesos descargables, esa es la pieza a vigilar, porque la serie K2 marcó precedente abriéndolos bajo licencia Modified MIT y aquí está el listón puesto. Ese mismo movimiento ya lo vimos con GLM-5, el open-weights de Z.ai que quiso sentarse en la mesa de los grandes.

Si vienes de las versiones anteriores, ya conoces el terreno. Lo conté cuando salió Kimi K2.5, el modelo open source que quería sentarse en la mesa de los grandes, y volví sobre la familia con Kimi K2.7 Code y cómo usarlo con tus agentes. K3 es el siguiente eslabón de esa cadena, y el que por fin apunta a generalista de primera línea.

Para qué sirve K3 como modelo ¶

Quitemos la lupa de la ficha técnica y miremos qué puede hacer. La API describe capacidades muy concretas, y varias son de las que cambian tu día a día.

Programación agéntica ¶

Aquí es donde Moonshot apunta con más fuerza. K3 está preparado para navegar por repositorios grandes, generar y modificar código, y depurar apoyándose en errores, logs y resultados de tests. También para encadenar herramientas en cadenas largas y sostener ejecuciones agénticas con historiales que no caben en un modelo pequeño.

Se integra con Codex, Claude Code, OpenCode, Cline, RooCode, OpenClaw y Hermes Agent. En OpenCode el flujo es tan simple como autenticar Moonshot AI y elegir el modelo:

# Autenticas el proveedor y seleccionas el modelo en OpenCode
opencode auth login moonshot
opencode --model kimi-k3

Como la API es compatible con el formato de OpenAI, también sirve en cualquier herramienta que te deje cambiar el endpoint y el identificador del modelo. Ese detalle, que parece menor, es lo que decide si un modelo se adopta o se queda en la estantería.

Tool calling que va en serio ¶

K3 trae lo que esperas de un modelo pensado para agentes: function calling, tool_choice="required", múltiples llamadas de herramientas y bucles de herramienta → resultado → nuevo razonamiento.

Pero hay una función que me parece la más interesante de todas: la carga dinámica de herramientas durante la conversación. En vez de mandarle al modelo cientos de definiciones en cada mensaje (con lo que eso engorda el contexto y la factura), puedes introducir la definición de una herramienta justo cuando hace falta.

💡 La carga dinámica de herramientas es de esas cosas que no salen en los titulares pero cambian el trabajo real. Un agente que solo conoce las herramientas que necesita en cada momento es más barato y más fácil de razonar. Menos ruido en el contexto, menos alucinaciones de «me invento una herramienta que no existe».

Un contexto enorme… con asterisco ¶

El millón de tokens permite meter dentro repositorios completos, documentación técnica extensa, historiales largos de ejecución, logs, especificaciones y bases de conocimiento enteras. La caché de contexto es automática: si mantienes intacto el prefijo largo, Moonshot lo reutiliza y te cobra la tarifa reducida de caché.

Suena de maravilla. Pero cuidado con confundir el tamaño de la caja con lo que cabe usable dentro.

Tener un millón de tokens no demuestra que el modelo use bien el millón de tokens. Lo que de verdad importa son las pruebas de needle-in-a-haystack, recuperación múltiple, seguimiento de dependencias y edición consistente de repos gigantes. Un modelo puede tragarse un codebase entero y aun así perder el hilo en el minuto 40. Ya lo hemos visto en otras familias, así que este es un punto para medir tú mismo con tu propio repo antes de fiarte.

Multimodalidad y salidas estructuradas ¶

K3 acepta imágenes en base64 y vídeos subidos a través de su sistema de archivos. Con eso puede interpretar interfaces, reproducir diseños, analizar capturas y diagramas, y convertir una demostración visual en código funcional. La pega práctica: la entrada visual de la API no acepta URLs públicas, hay que pasar por base64 o referencias ms://.

En salidas cubre lo esperable y algo más: JSON Schema con strict: true, JSON Mode, Partial Mode para obligarlo a continuar desde un prefijo, respuestas en streaming y separación entre reasoning_content y la respuesta final. Puede generar hasta 131.072 tokens de salida por defecto, y el máximo configurable llega a 1.048.576. Una barbaridad.

¿Cuál es el carácter más marcado de K3? ¶

Que solo sabe pensar a tope. Literalmente.

K3 admite un único valor de esfuerzo de razonamiento:

# Único modo disponible: no hay low, medium ni high
response = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    reasoning_effort="max",  # No puedes bajarlo
)

Ni low, ni medium, ni high. Solo max. Y por si fuera poco, Moonshot fija temperature=1.0, top_p=0.95, n=1 y los penalties. El desarrollador no toca nada de eso.

Piénsalo como un coche que solo tiene una marcha: la larga. Genial para autopista. Un suplicio para aparcar.

Las consecuencias son reales:

• Puede tardar de más en preguntas sencillas.
• Puede gastar un montón de tokens solo en razonar.
• No es el modelo ideal para pequeñas ediciones rápidas.
• El precio nominal engaña si necesita cinco veces más razonamiento que otro modelo.
• Tienes poco control sobre coste, velocidad y comportamiento.

⚠️ Ojo con la factura del razonamiento. En Hacker News, un experimento de generación de un SVG consumió 13.241 tokens de razonamiento y 16.658 tokens de salida total para una entrada de solo 95 tokens, con un coste de unos 0,25 dólares. Es un ejemplo aislado, sí. Pero apunta al riesgo práctico más claro de K3: que el «pienso siempre al máximo» te salga caro sin verlo venir.

Varios desarrolladores describen el mismo patrón: respuestas larguísimas, repeticiones y timeouts en tareas simples. No es un defecto irreparable —Moonshot puede añadir modos de razonamiento más adelante—, pero es el carácter del modelo tal y como se comporta.

¿Es K3 un modelo caro? ¶

Depende de con qué lo compares, y la respuesta corta es: ya no es barato.

Estos son los precios oficiales de la API:

No estamos ante el típico modelo chino ultraeconómico. Ese precio está mucho más cerca de los modelos frontier occidentales que del de sus propios hermanos.

Para que lo veas claro: Kimi K2.7 Code cuesta 0,19 / 0,95 / 4 dólares por millón (caché, entrada y salida). K3 es bastante más caro, sobre todo en salida, donde pasa de 4 a 15 dólares.

Y aquí viene la trampa mental. Un modelo a 15 dólares que resuelve la tarea con 10.000 tokens internos puede salirte más barato que uno «económico» que necesita 50.000. La comparación real no está en el precio por token, sino en cuántos tokens de razonamiento quema K3 para cerrar tu tarea concreta. Y como solo razona al máximo, ese número tiende a ser alto.

¿Qué dicen los benchmarks de K3? ¶

Buenos números, pero con pinzas. Y no porque sean malos, sino porque cuesta auditarlos.

Los resultados que ha mostrado Moonshot son dos:

• GDPval-AA v2: 1687 Elo, por detrás de Fable 5 Max y GPT-5.6 Sol Max, pero por delante de Opus 4.8 Max (que aparece con 1600).
• AA-Briefcase: 1527 Elo, por detrás de Fable 5 Max y por delante de GPT-5.6 Sol Max (que aparece con 1495).

Son cifras llamativas porque ambos tests miden tareas profesionales y trabajo agéntico prolongado, justo el terreno donde Moonshot dice que K3 brilla. Pero tienen tres pegas que no puedes ignorar:

1. Son cifras que la propia Moonshot ha ido moviendo en su documentación.
2. AA-Briefcase es un benchmark privado.
3. No conocemos la configuración, el presupuesto de cómputo, el harness, el número de intentos ni el coste por tarea.

Y falta el resto de la foto: no hay resultados públicos e independientes de K3 en SWE-bench Verified, SWE-bench Pro, Terminal-Bench, LiveBench, ARC-AGI, GPQA ni Aider Polyglot. Los números que hay apoyan la hipótesis de que K3 es frontier. No bastan para construir una clasificación general. Un benchmark propio nunca ha venido sin maquillaje, jamás.

Circula también un vídeo que prueba K3 en KingBench con tareas de frontend, Three.js, SVG, matemáticas y generación visual, con un resultado declarado de 62 sobre 80. El autor lo describe como un salto enorme respecto a los Kimi anteriores. Es una señal valiosa porque no se queda en preguntas académicas: comprueba si el código genera algo utilizable. Pero KingBench es el benchmark personal de un creador, sin saber cuántos intentos hubo, si se seleccionaron resultados o qué versiones de los rivales se usaron.

Mi lectura: hay pruebas convincentes de que K3 es excepcional en frontend generativo y prototipos visuales. Lo que ningún benchmark de este tipo demuestra por sí solo es que sea el mejor modelo para mantener un backend, resolver issues reales o ejecutar una migración delicada.

¿Qué se dice en los foros y en las fuentes chinas? ¶

Las opiniones están divididas, que suele ser buena señal de que hay algo real debajo del ruido.

Del lado positivo, la comunidad destaca un salto claro en diseño visual respecto a generaciones anteriores, buen gusto en interfaces, resultados ambiciosos en Three.js y SVG, y que conserva la buena escritura creativa de la serie K2. Muchos lo sienten cercano a la primera línea de modelos cerrados.

Del lado crítico, se repiten las mismas quejas: lentitud, razonamiento demasiado largo, repetición de ideas, timeouts y precio elevado.

La valoración más sensata que he leído en Reddit viene a decir esto: más rápido que Claude en algunos casos, menos preciso en otros, probablemente cercano a GPT-5.5, pero todavía no al nivel de GPT-5.6 o Fable. Su rasgo diferencial más evidente es la calidad visual.

En medios y comunidades chinas dominan las demos de frontend: clones jugables de Minecraft, juegos 3D en un único HTML, simuladores históricos, escenas con cámara, físicas, estado y controles. La comparación que más se repite es que Fable produce algo más limpio, estable y rápido, mientras que K3 genera resultados más complejos, espectaculares y visualmente arriesgados.

En V2EX el tono es más escéptico. Algunos desarrolladores interpretan la campaña como marketing muy bien orquestado, y las preguntas sobre experiencia real con repos grandes todavía reúnen pocas respuestas sólidas. Lo cual confirma algo importante: hay más demo espectacular que kilómetros reales con repositorios de producción.

Cómo se compara K3 con lo que ya usas ¶

Te dejo una tabla con mi lectura cualitativa. No son notas de examen, son impresiones para orientarte cuando toca elegir modelo.

Fíjate en la última fila. Es la que más pesa cuando lo que está en juego es tu producción y no una demo para un tuit.

Cuando está en juego tu producción

Cómo verificar lo que K3 escribe antes de fiarte de ello

Verás métodos reales para revisar y verificar lo que genera un agente: skills, pruebas en navegador con Playwright, casos Gherkin y adversarial review entre modelos. Justo la red que este post te pide poner tú.

Ver el método entero →

Masterclass Web Reactiva Premium · métodos en directo

Mi valoración para desarrollo de software ¶

Voy a mojarme.

Dónde K3 parece especialmente fuerte:

• Crear prototipos de frontend completos.
• Three.js, Canvas, SVG y experiencias interactivas.
• Interpretar una captura o un vídeo y reproducirlo.
• Trabajar con repositorios o documentación muy grandes.
• Investigar y ejecutar tareas largas apoyándose en herramientas.
• Entregar cosas completas, no fragmentos sueltos de código.

Dónde todavía no confiaría a ciegas:

• Migraciones delicadas de producción.
• Refactors extensos sin tests que te cubran las espaldas.
• Resolución autónoma de issues reales durante muchas horas.
• Cambios arquitectónicos donde importe mucho no inventarse cosas.
• Tareas pequeñas y frecuentes donde el coste y la latencia manden.

🛡️ Si vas a meter K3 en algo serio, ponle tests antes. La combinación de «razona siempre al máximo» y benchmarks todavía sin réplica independiente significa que la red la pones tú. Un test suite verde es la diferencia entre un ayudante brillante y un becario con acceso a producción y prisa.

¿Qué modelo elegiría yo para cada tarea? ¶

Para el trabajo de todos los días con OpenCode o Claude Code, seguiría tirando de K2.7 Code como modelo económico y rápido. Y reservaría K3 para lo que de verdad justifica su coste y su ritmo:

1. Repositorios grandes donde el millón de tokens marca la diferencia.
2. Planificación complicada que necesita razonamiento profundo.
3. Debugging difícil que se te resiste con otros modelos.
4. Implementaciones de frontend visual, que es donde más destaca.
5. Tareas que K2.7 no consigue cerrar por sí solo.

Piensa en K3 como el motor grande que enciendes cuando la tarea lo pide, no como el modelo que dejas en marcha para cada microedición.

Veredicto ¶

Kimi K3 es un salto grande y juega en la liga de los modelos frontier. Eso ya lo sostienen las demos, los foros y los primeros números. Para frontend generativo y prototipos visuales, es de lo más impresionante que vas a poder tocar.

Ahora bien, el relato de «modelo abierto que se merienda a Fable» corre por delante de las pruebas independientes. Y conviene tenerlo presente:

• Los benchmarks conocidos son propios y sin réplica externa.
• Solo permite razonamiento máximo, con lo que arrastra coste y latencia.
• El precio ya no es de modelo económico.
• La evidencia más contundente se concentra en frontend y demos visuales.

🔑 Mi estimación: K3 está por encima de los modelos open-weight anteriores en capacidad general y frontend, compite con Opus 4.8 en tareas concretas, y todavía tiene que demostrar que iguala de forma sostenida a GPT-5.6 Sol o Fable 5 en trabajo de backend y agentes de largo recorrido.

Así que la jugada es sencilla: úsalo donde brilla, mídelo donde dudas y no lo dejes tocar tu producción sin tests delante. Con esa regla ya juegas con ventaja frente a la mayoría, que anda pegando prompts en caliente y cruzando los dedos.

¿Por dónde vas a empezar a probarlo: un prototipo de frontend o un repo grande que se te haya atragantado con otros modelos?

Preguntas frecuentes sobre Kimi K3 ¶

¿Qué es Kimi K3?

Kimi K3 es el modelo generalista de la china Moonshot AI, sucesor de la familia K2. Cuenta con 2,8 billones de parámetros, una ventana de contexto de un millón de tokens y una orientación clara a programación, trabajo agéntico y frontend generativo.

¿Cuántos parámetros tiene Kimi K3?

Según la documentación de la API, Kimi K3 tiene 2,8 billones de parámetros totales. Moonshot no detalla cuántos se activan por token ni la topología exacta del MoE, así que el número de parámetros activos no está publicado.

¿Cuál es la ventana de contexto de Kimi K3?

Kimi K3 admite una ventana de contexto de 1.048.576 tokens, es decir, un millón. Conviene medir en tu propio repositorio si aprovecha bien todo ese contexto en tareas de recuperación múltiple o edición de codebases grandes.

¿Cuánto cuesta la API de Kimi K3?

La API oficial cuesta 0,30 dólares por millón de tokens de entrada con caché, 3 dólares por millón de entrada sin caché y 15 dólares por millón de salida. Es un precio de modelo frontier, no del típico modelo chino económico.

¿Se puede usar Kimi K3 con Claude Code y OpenCode?

Sí. Kimi K3 se integra con Codex, Claude Code, OpenCode, Cline, RooCode, OpenClaw y Hermes Agent. En OpenCode basta con autenticar Moonshot AI y seleccionar el modelo kimi-k3, y al ser compatible con el formato de OpenAI también funciona en herramientas que permitan cambiar el endpoint.

¿Por qué Kimi K3 es lento en tareas sencillas?

Porque solo admite reasoning_effort="max". No hay modos de razonamiento bajo, medio o alto, de modo que piensa siempre al máximo aunque la pregunta sea trivial. Eso provoca respuestas largas, más gasto de tokens y algún timeout en tareas simples.

¿Kimi K3 es mejor que Opus 4.8 o Fable 5?

En los benchmarks que ha mostrado Moonshot aparece por delante de Opus 4.8 en una prueba y por detrás de Fable 5 en varias. Como son benchmarks propios y sin réplica independiente, no se puede afirmar que supere de forma general a Opus 4.8, GPT-5.6 Sol o Fable 5.

¿En qué destaca Kimi K3 frente a otros modelos?

Su punto más fuerte, según demos y foros, es el frontend generativo: Three.js, SVG, Canvas y experiencias interactivas, además de interpretar capturas y vídeo para reproducir interfaces. Ahí es donde la comunidad ve una diferencia clara respecto a versiones anteriores.

¿Kimi K3 sirve para trabajo con repositorios grandes?

Sí, es uno de sus terrenos naturales gracias al contexto de un millón de tokens y a su enfoque agéntico. Puede navegar por repos extensos, encadenar herramientas y sostener ejecuciones largas, aunque conviene apoyarlo con tests en tareas críticas.

¿Debería usar Kimi K3 en producción?

Para producción delicada, lo prudente es reservarlo para prototipos, frontend visual y repos grandes, siempre con tests que cubran los casos críticos. Con benchmarks aún sin réplica independiente, es mejor validar su comportamiento en tu propio flujo antes de darle las llaves.

Fuentes ¶

• Kimi API Platform, “Kimi K3 Quickstart”
• Kimi API Platform, “Using Kimi Models in OpenCode”
• OpenRouter, “Kimi K3 — API Pricing & Providers”
• Hacker News, “Kimi K3 is now live”
• ExplainX, “Kimi K3 API Guide: 2.8T Model, Pricing, 1M Context”
• Reddit r/singularity, “Chinese Fable 5 is here, aka Kimi K3”
• 36kr, análisis y demos de frontend de K3

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter