Kimi K3: cómo integrarlo en OpenCode, Kimi Code y tus propias aplicaciones
De todos los modelos open weight que se están mencionando ahora mismo, Kimi K3 es probablemente el que más atención está llamando. Y la razón es simple: está compitiendo con modelos frontier como GPT 5.6 o Claude Fable 5, que son extremadamente potentes pero también extremadamente caros. Kimi te ofrece capacidades similares a un costo bastante más bajo, y al ser un modelo ya conocido, hay muchísimas herramientas que lo soportan desde el primer día.
En este artículo vamos a ver, de forma práctica, cómo integrarlo en OpenCode, en su propio harness Kimi Code, y cómo consumir la API directamente desde una aplicación propia.
Qué es Kimi K3
Kimi K3 es un modelo open weight, lo que significa que puedes acceder al modelo, descargarlo y ejecutarlo en tu propia máquina si tienes con qué. Ahora mismo es uno de los modelos más grandes que existen —alrededor de 2.8T de parámetros— y está diseñado específicamente para tareas de código y para delegarle tareas largas.
Lo que hace que se hable tanto de él últimamente no es su tamaño, sino el salto de capacidades. En versiones anteriores este modelo no competía con los frontier: Kimi K2.7 se medía contra Opus 4.7 o GPT 5.3. Con K3, la comparación pasó a ser directamente contra Fable 5 y GPT 5.6, que son los modelos más avanzados del momento. Si te interesa el aspecto de código, las referencias son el Kimi Code Bench (su medición interna) y el Terminal Bench, que mide qué tan bien se desempeña el modelo ejecutando herramientas de terminal, algo clave cuando hablamos de agentes.
El costo es la parte interesante
En la medición de costo por tarea —que básicamente mide cuántos tokens consume el modelo para completar una tarea real— Kimi K3 queda en 0.95, mientras que GPT 5.6 llega a 1.04. Y si lo comparas contra Fable 5, la diferencia es todavía mayor.
Ese es el verdadero valor del modelo: siendo mucho más accesible, ejecuta tareas midiéndose casi a la par de los frontier. Hoy por hoy es el open weight más capaz que hay disponible.
La contra: es lento
Hay que decirlo con claridad. Mientras muchos modelos actuales rondan los 200 tokens por segundo, Kimi K3 va normalmente a unos 34 tokens por segundo. Es de los modelos más lentos del mercado.
Esto no lo descalifica, pero sí condiciona cómo lo usas. Si vas a delegarle tareas largas, lo más sensato es aprovechar su modo swarm para paralelizar, que es justamente lo que vamos a ver más adelante.
Precios de la API
La API de Kimi está en $3 por millón de tokens de entrada y $15 por millón de tokens de salida. Bastante más barato que usar GPT 5.5 u Opus 4.8 para el mismo trabajo.
Configurando la API
El registro es directo: entras a la plataforma, te registras (yo usé Google) y llegas a un dashboard donde puedes ver tu consumo y recargar créditos. Los montos sugeridos son de $20, $50, etc., pero con la opción custom puedes empezar desde $5.
Luego vas a la sección de API Keys, creas una nueva, le pones un nombre (yo suelo nombrarlas según la herramienta donde la voy a usar: opencode, kimi-code, chat) y seleccionas el proyecto por defecto.
Importante: no compartas esa llave. Cualquiera que la tenga puede consumir tus créditos. No la subas a GitHub y elimínala cuando termines de probar.
Un dato útil: la plataforma te permite generar alrededor de 50 llaves distintas, así que puedes tener una por proyecto y revocarlas individualmente.
1. Kimi K3 en OpenCode
OpenCode es un agente de código abierto que funciona con cualquier modelo. La instalación es un comando:
npm install -g opencode-ai
Para autenticarte, en lugar de lanzar el agente directamente, ejecuta:
opencode auth login
Esto te lista los proveedores disponibles. Busca Moonshot AI, que es la empresa detrás de Kimi, dale enter y pega tu API key.
Ya dentro de OpenCode, con /models puedes buscar kimi-k3. Vas a ver varias formas de acceder al modelo, pero elige la que dice Moonshot AI, que es la que usa la API directamente.
Los modos de esfuerzo
Kimi K3 expone tres niveles: low, high y max.
- low: responde muy rápido, pero procesa menos.
- high: más lento, respuesta notablemente mejor.
- max: lo más lento, pero la respuesta es mucho más elaborada.
Para arrancar un proyecto desde cero, max es la opción correcta.
La prueba: un proyecto completo
Para evaluarlo no pedí una landing page. Ese tipo de prompts solo mide qué tan bonita queda una interfaz. En su lugar pedí algo con lógica real:
Crea una API REST de un sistema administrador de proyectos. Debe permitir registrar proyectos, tareas (que luego se verán en tablas y kanban), usuarios, equipos, presupuestos, facturas, reuniones y calendarios. Con autenticación, autorización, roles, testing unitario y end to end, Docker y documentación. Además, un CLI para interactuar con la API. Todo como monorepo con TypeScript, PostgreSQL y Express.
Antes de construir, cambié a modo plan. La ventaja es que el modelo te hace preguntas antes de escribir código. En mi caso definí:
- Prisma como ORM
- pnpm + Turborepo para los workspaces
- Supertest para testing
- JWT + refresh tokens para autenticación
El resultado fue un markdown resumido con todas las características a implementar y la organización del monorepo. Eso último importa mucho, porque después vamos a extender el proyecto con app web y app de escritorio.
Cambié a modo build, le dije "implementa", y después de un rato tenía el proyecto completo corriendo, con la documentación disponible en /docs y rutas para autenticación, usuarios, equipos y proyectos.
El CLI generado
Aquí viene la parte que más me gustó. Le pedí a OpenCode que instalara el CLI del proyecto, y generó un comando llamado kpm que consulta la API.
kpm --help
kpm projects --help
kpm projects list
Lo interesante es que ese CLI se puede usar desde cualquier lugar. Abrí otra instancia de OpenCode en otra terminal y le dije: "usando kpm, crea 10 proyectos de ejemplo y coloca varias tareas dentro". Mientras el agente llenaba datos por un lado, yo los iba viendo aparecer por el otro.
Esa es, en la práctica, una forma bastante buena de comprobar que tu API está realmente completa: si un agente puede operarla desde una herramienta de consola, funciona.
2. Kimi Code: el harness propio de Moonshot
Para la siguiente fase —la app web y la de escritorio— cambié a Kimi Code, el CLI oficial de Moonshot. Está enfocado exclusivamente en Kimi y tiene características que no encuentras en otros harness.
La instalación depende de tu sistema operativo; en Windows es un comando que descargas y pegas en la terminal. Después:
kimi
Dentro, ejecutas /login, eliges la opción de Kimi Platform, pegas tu API key (yo generé una nueva llamada kimi-code) y seleccionas Kimi K3.
/yolo — sin confirmaciones
Kimi Code te pide aprobar cada comando (approve once, approve for session). Si no quieres estar confirmando cada rato, ejecuta /yolo y los comandos se ejecutan sin pedir confirmación. Úsalo con criterio y de preferencia en proyectos aislados.
/swarm — subagentes en paralelo
Esta es la característica diferencial. El comando /swarm permite lanzar múltiples instancias de Kimi que avanzan en paralelo.
Le pedí dos planes: una web con Next.js y React, y una app de escritorio en Tauri, ambas consumiendo la API ya creada. Con swarm activado, arrastré ambos planes y le dije "implementa estos dos planes en paralelo".
El agente dividió la planificación en tareas individuales y las asignó a siete subagentes trabajando simultáneamente: uno en el dashboard, otro en la lógica de la app de escritorio, y así. Al terminar, incluso lanzó dos agentes adicionales para revisar tareas pendientes.
Ojo con esto: swarm avanza mucho más rápido, pero consume mucho más tokens. Aquí es donde el precio bajo de Kimi K3 se vuelve relevante: hace viable una estrategia que con un modelo frontier sería cara.
Si necesitas retomar una sesión anterior:
kimi --resume
Te lista el historial de sesiones y eliges la que quieras continuar.
3. Testing automatizado con el skill de Playwright
Antes de probar las interfaces manualmente, instalé el skill Playwright CLI, que permite al agente manipular el navegador directamente. Se instala para múltiples herramientas a la vez, incluyendo Kimi Code, y crea una carpeta .claw (o equivalente) con el skill dentro.
Para que Kimi Code lo detecte, sal de la sesión con Ctrl+C y vuelve con kimi --resume. Después, escribiendo /playwright y presionando Tab se autocompleta el skill.
Mi prompt fue:
Levanta la API y luego haz testing del frontend usando Playwright. En cada comando ejecuta la opción
--headed.
El flag --headed es solo para poder ver el navegador trabajando; en producción lo dejarías en background.
Algo que hace muy bien este modelo es armar un TODO antes de ejecutar. Detectó que le faltaba levantar la base de datos, migrarla y llenarla con datos de prueba antes de poder testear el frontend, y fue completando tarea por tarea en el orden correcto.
El reporte final cubrió login, dashboard, vista kanban, creación de proyectos, facturación y calendario. Falta profundizar módulo por módulo, pero como punto de partida es sólido. Y esto también combina bien con swarm: puedes lanzar varias instancias donde cada subagente controla un navegador distinto.
4. La app de escritorio con Tauri
Para cerrar el monorepo le pedí: "instala la aplicación de escritorio en este sistema".
Como la app estaba en Tauri —un framework para apps multiplataforma que funciona en Windows, Linux y Mac—, el proceso fue compilar el binario y generar el instalador. A diferencia de una app web, no se queda corriendo: obtienes un ejecutable.
Instalé, me registré desde cero con un usuario nuevo, y entré a la misma aplicación con los mismos datos de prueba. El board kanban mostraba las mismas tareas que la web. El agente incluso verificó dónde quedó instalada y la lanzó para confirmar que funcionaba.
Con esto el proyecto quedó completo: API + CLI + app web + app de escritorio, todo desde unos cuantos prompts y sin iterar sobre la interfaz.
5. Consumir la API desde tu propia aplicación
Hasta aquí usamos Kimi para generar código. Pero la misma API sirve para integrar inteligencia en tus aplicaciones.
Creé una carpeta nueva, lancé kimi, cambié a modo plan con Shift+Tab y pedí:
Crea un chat al estilo de ChatGPT usando Kimi K3 desde la API.
El punto aquí no era la interfaz, sino comprobar que la misma llave sirve para consultar el modelo desde una app propia. En la planificación elegí React con Vite, la API key en un archivo .env, y el endpoint api.moonshot.ai con Kimi K3.
Lo que más me gustó de esta parte: el modelo no generó solo un frontend bonito. Propuso un backend con Server-Sent Events para el streaming de respuestas y, sobre todo, para ocultar la API key del cliente. Si le pides "un chat" a un modelo mediocre, te da una interfaz que no es funcional o que expone tu llave en el navegador. Kimi previó eso solo.
Generé una tercera llave, le dije "añade esta llave de Kimi", ejecuté el proyecto y en el puerto 3001 tenía un chat funcional con streaming de datos y renderizado de markdown. Muy similar a la interfaz de ChatGPT, pero corriendo sobre la misma API con la que construí todo lo anterior.
Conclusión
Kimi K3 es de los modelos más versátiles que hay ahora mismo: sirve tanto para desarrollar como para integrarse en aplicaciones propias, y la mejora respecto a versiones anteriores se nota al usarlo, no solo en los benchmarks.
Mi recomendación concreta: cuando tengas tareas largas o una gran cantidad de tareas dentro de una planificación que quieras delegar, Kimi K3 es una opción muy fuerte. Es más barato, y puedes aprovechar los subagentes para avanzar en paralelo y compensar su velocidad de generación, que es su punto débil real.
Si tu caso es interacción rápida e iterativa, donde esperas respuestas en segundos, los 34 tokens por segundo se van a sentir. Ahí un frontier sigue teniendo sentido. Pero para planificaciones grandes, testing automatizado y trabajo en background, la relación capacidad/precio es difícil de superar.