Kimi Code CLI: guía práctica del agente de IA en la terminal

Kimi Code CLI es el agente de programación de Moonshot AI que vive en tu terminal: entras a tu proyecto, corres kimi y le describes la tarea en lenguaje natural. El agente lee y modifica archivos, ejecuta comandos de shell, busca en el código, consulta páginas web y planifica los siguientes pasos según lo que encuentra. Está escrito en TypeScript, se distribuye por npm y corre sobre Node.js, con la serie K2.7/K3 de Kimi como modelo por defecto cuando te autenticas con tu cuenta.

Esta guía cubre el flujo completo de la serie de agentes CLI del hub Construir agentes: instalación, primer arranque y autenticación, trabajo del día a día con sesiones, configuración multi-proveedor y el checklist para usarlo sin romper el repo. Si ya usas otro CLI, compáralo con Qwen Code, OpenCode o Aider; y si quieres que respete las reglas de tu proyecto, combínalo con AGENTS.md.

Instalación: dos caminos

La documentación oficial recomienda el instalador por script, que no exige Node preinstalado: descarga la última versión, verifica el checksum y deja el ejecutable kimi en tu PATH.

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

En Windows el instalador es de PowerShell (irm https://code.kimi.com/kimi-code/install.ps1 | iex), y además requiere Git for Windows: Kimi Code usa Git Bash como shell. Si Git Bash quedó en una ruta no estándar, apunta la variable KIMI_SHELL_PATH al bash.exe.

La alternativa es npm (o pnpm) sobre Node.js 22.19.0 o superior:

pnpm add -g @moonshot-ai/kimi-code

La TUI es interactiva y luce mejor en terminales con color verdadero; los docs sugieren Kitty o Ghostty. Verifica con kimi --version. Para actualizar: kimi upgrade (el CLI revisa y ofrece instalar) o pnpm add -g @moonshot-ai/kimi-code@latest; para desinstalar, pnpm remove -g @moonshot-ai/kimi-code si instalaste por paquetes, o borra el binario si usaste el script.

Primer arranque y /login

Dentro del proyecto, ejecuta kimi y se abre la sesión interactiva. Para una sola instrucción sin entrar a la TUI, usa kimi -p "instrucción", y kimi -c para continuar la última sesión.

El primer arranque pide configurar el origen del modelo con /login, que ofrece dos vías:

• Kimi Code (OAuth): flujo por código de verificación; abres el enlace en cualquier dispositivo, inicias sesión y autorizas. Es la vía si usas el plan de suscripción de Kimi Code.
• Kimi Platform API key: una llave de platform.kimi.com o platform.kimi.ai que el CLI guarda como credencial.

/logout limpia las credenciales cuando cambias de cuenta. Si en vez de la cuenta de Kimi quieres otros modelos, la autenticación de terceros no pasa por /login: se configura en ~/.kimi-code/config.toml, como veremos abajo.

Cómo trabaja: confirmaciones por defecto

El modelo de permisos es simple y seguro: las operaciones de solo lectura se ejecutan solas; escribir archivos o correr comandos de shell pide confirmación antes de actuar. Eso hace viable soltarle tareas de exploración y diagnóstico sin miedo, mientras las tareas de escritura quedan bajo tu control.

Un flujo típico de trabajo:

1. Contexto primero: "revisa la estructura del proyecto y explica qué hace cada directorio" — el agente llama a sus herramientas de lectura y responde con fundamento.
2. Tarea acotada: "agrega una función en src/utils para convertir strings a kebab-case, con test unitario" — planifica, edita, corre los tests y reporta cada paso.
3. Verificación: revisa el diff y los resultados de los tests como revisarías el trabajo de un junior; el agente reporta lo que hizo, pero el diff final es tuyo.

Sesiones y contexto: /new, /sessions, /compact, /fork

La sesión es la unidad de trabajo. Los comandos que conviene memorizar el primer día:

Comando	Para qué sirve
/new	Nueva sesión, limpia el contexto actual
/sessions	Navega el historial y retoma una sesión pasada
/model	Cambia el modelo activo
/compact	Comprime el contexto a mano para liberar tokens
/fork	Deriva la sesión actual en una copia con historial completo
/help	Panel de comandos y atajos

Atajos útiles: Esc interrumpe la salida en streaming; Shift-Tab alterna el modo Plan; Ctrl-S inserta un mensaje sin esperar a que termine el turno; Ctrl-O colapsa la salida de herramientas; Ctrl-C dos veces sale. El modo Plan es la vía para tareas grandes: primero acordar el plan, después dejar que ejecute.

Con sesiones largas, /compact es la válvula de presión: comprime el historial y libera presupuesto de contexto sin perder el hilo de la tarea. Y si quieres conservar la línea completa de trabajo antes de experimentar, /fork te da una copia derivada sin tocar la sesión original.

Multi-proveedor: config.toml y /provider

Kimi Code no está encerrado en Kimi: declara proveedores y encima modelos en ~/.kimi-code/config.toml. Los tipos de proveedor que soporta el CLI:

Tipo	Protocolo	Uso típico
kimi	OpenAI-compatible	Servicio gestionado de Kimi Code y API de Kimi Platform
anthropic	Anthropic Messages	Modelos Claude
openai	OpenAI Chat Completions	OpenAI y compatibles (DeepSeek, Qwen, gateways)
openai_responses	OpenAI Responses API	El endpoint nuevo de OpenAI
google-genai	Google GenAI	Gemini API
vertexai	Google GenAI en Vertex	Modelos Gemini vía Google Cloud

Un proveedor Anthropic se declara así, con el modelo y su contexto:

[providers.anthropic]
type = "anthropic"
api_key = "sk-ant-xxxxx"

[models."claude-opus-4-7"]
provider = "anthropic"
model = "claude-opus-4-7"
max_context_size = 200000

Dos reglas del CLI que evitan sorpresas: las credenciales tienen prioridad api_key del proveedor > subtabla [providers.<name>.env] > error al arrancar — el CLI no lee llaves de tus variables de shell por su cuenta; y si prefieres no editar TOML, /provider abre un gestor interactivo que importa proveedores desde el catálogo de models.dev o desde un registry propio (api.json). Las cuentas OAuth de Kimi no aparecen en /provider: se gestionan con /login y /logout. Para automatizarlo fuera de la TUI existe el comando no interactivo kimi provider.

El tipo openai trae un detalle práctico: maneja automáticamente los campos de razonamiento (reasoning_content, reasoning_effort) de proveedores compatibles como DeepSeek o Qwen, y si tu gateway usa nombres distintos, se cubre con reasoning_key en el alias del modelo.

Modo headless con kimi -p

kimi -p "instrucción" ejecuta una instrucción y termina, sin abrir la TUI. Es la pieza para automatización: tareas de una sola pasada, pipelines de pre-commit o jobs de CI donde un humano revisa el resultado después. Dos reglas sanas: cada tarea corre como su propio proceso de -p (no encadenes tareas dependientes en una sola llamada), y trata el código de salida como señal — si falla, revisa la sesión antes de relanzar.

Para tareas grandes y de larga duración, los docs de Kimi Code describen flujos de objetivos y control remoto; empieza simple con -p y sube de complejidad solo cuando el flujo manual ya te quede corto.

Dónde vive todo: ~/.kimi-code/

La configuración, sesiones, logs y caché de actualización quedan en ~/.kimi-code/. Para mover el home (por ejemplo a un disco aparte), exporta KIMI_CODE_HOME con la nueva ruta. Es también el primer lugar que mirar cuando algo se comporta raro: ahí viven las sesiones que puedes retomar con /sessions y los logs con la traza de lo que hizo el agente.

Comparativa rápida dentro de la serie CLI

CLI	Enfoque	Autenticación
Kimi Code CLI	Agente terminal de Moonshot, modelo K2.7/K3, multi-proveedor	OAuth Kimi Code o API key
Qwen Code	Fork multi-proveedor de la familia Gemini CLI, fuerte en Alibaba ModelStudio	Coding/Token Plan o API key
OpenCode	Cliente agnóstico con opencode.json y MCP	Proveedores por config
Aider	Pair programming con commits atómicos por cambio	API key del proveedor

La diferencia práctica: Kimi Code te da la experiencia gestionada con la suscripción de Kimi Code (OAuth, modelo por defecto, plugins del ecosistema) y al mismo tiempo acepta Claude, OpenAI o Gemini si tu stack ya vive ahí. Si tu criterio es "un CLI, muchos proveedores", los cuatro cumplen; elige por ecosistema y por qué modelo prefieres por defecto.

Checklist antes de soltarlo en tu repo

• kimi --version responde y la TUI abre con /help.
• /login hecho por OAuth o API key; /logout limpio si compartes máquina.
• Sabes qué es read-only (auto) y qué pide confirmación (writes y shell).
• Sesiones grandes: /compact antes de quedarte sin contexto; /fork antes de experimentar.
• Proveedores extra en config.toml con api_key en el bloque del proveedor, no en variables de shell sueltas.
• Trabajo aislado en worktrees si vas a correr varias tareas en paralelo.
• Reglas del proyecto escritas en AGENTS.md, no en prompts repetidos.

FAQ

¿Necesito Node.js para instalar Kimi Code CLI? No si usas el instalador por script (descarga un binario verificado). Solo lo necesitas (22.19.0+) para la vía npm/pnpm.

¿Puedo usar Claude o GPT dentro de Kimi Code? Sí: declara los proveedores anthropic, openai, openai_responses, google-genai o vertexai en config.toml, o importa desde el catálogo con /provider. Elige el modelo activo con /model.

¿Qué pasa con mis llaves si ya las tengo como variables de entorno? El CLI no las toma automáticamente: decláralas en la subtabla [providers.<name>.env] del config o usa la prioridad de api_key. Diseño deliberado para no depender del entorno de tu shell.

¿Cómo retomo el trabajo de ayer? kimi -c continúa la última sesión; /sessions lista el historial completo guardado en ~/.kimi-code/.

¿Sirve para CI? Con kimi -p puedes ejecutar tareas de una sola pasada sin TUI; deja la supervisión de diffs y pruebas al pipeline, y no encadenes tareas dependientes en una sola llamada.