Historial de conversaciones de Kimi Code: encontrar y reanudar sesiones

La respuesta rápida: reanuda con --continue o --session

El historial de conversaciones de Kimi Code es el registro de todo lo que contuvo una sesión: qué pediste, qué hizo el agente y el contexto que se fue construyendo por el camino. Como el contexto es la parte cara de trabajar con un agente de código, poder reabrir una sesión en vez de re-explicar un módulo desde cero vale tiempo y tokens de verdad.

Si todavía estás montando el CLI, empieza por la guía de cómo usar Kimi Code. Todo lo de abajo asume que ya tienes sesiones a las que merece la pena volver.

Reanudar: los flags y sus trampas

# Reabrir la sesión más reciente del directorio actual
kimi --continue    # forma corta: -c

# Reabrir una sesión concreta por id
kimi --session <session-id>

Aquí importan dos detalles. Primero, --continue va ligado al directorio desde el que lo lanzas: reabre la última sesión de ese proyecto, no la última sesión global. Lánzalo en el repo equivocado y te sale la conversación equivocada. Segundo, -r y --resume existen como alias ocultos de --session, así que los hábitos de Claude Code casi se transfieren, pero la forma documentada es --session.

Ponles nombre con /title mientras aún te acuerdas

Dentro de una sesión, /title <texto> le pone nombre, y ese nombre se persiste en disco con la sesión. Es el hábito más útil para el historial de Kimi Code: una sesión llamada "migración de auth a JWT" se encuentra en una semana; un id anónimo, no. Titular cuesta cinco segundos con el contexto fresco y ahorra minutos cada vez que buscas después.

Dónde guarda Kimi Code las sesiones en disco

Kimi Code es inusualmente transparente con su historial: las sesiones son ficheros planos, organizados por proyecto, sin base de datos de por medio. Todo vive bajo ~/.kimi-code/sessions/, con un directorio por proyecto y un subdirectorio por sesión:

~/.kimi-code/
  session_index.jsonl              # indice global: id de sesion -> directorio + proyecto
  sessions/
    <workDirKey>/                  # un bucket por proyecto (derivado de su ruta)
      <sessionId>/
        state.json                 # titulo, timestamps, estado de la sesion
        agents/main/wire.jsonl     # el transcript real, un evento por linea

Las piezas encajan así: el workDirKey se deriva de un hash de la ruta normalizada del proyecto, así que cada proyecto tiene su propio bucket. Dentro de una sesión, state.json guarda el título (incluido lo que fijes con /title) y los timestamps, mientras que agents/main/wire.jsonl es el transcript en sí, un stream JSONL de todo lo que pasó. El session_index.jsonl global de arriba mapea cada id de sesión a su directorio y su proyecto, que es la forma más barata de enumerar todas las sesiones de todos los proyectos.

Como todo es JSONL plano, puedes inspeccionarlo con herramientas estándar. Un grep rápido sobre los wire.jsonl responde "qué sesión mencionaba el webhook de pagos" sin tooling especial, aunque llegado a ese punto te estás construyendo tu propio buscador comando a comando.

Dónde empieza a doler el historial nativo

La reanudación nativa borda el caso común: tu última sesión en el proyecto actual, a un flag de distancia. La fricción empieza en cuanto la sesión que quieres no es esa:

• Sin búsqueda de texto completo. No hay forma nativa de buscar entre sesiones "aquella conversación de la migración de la semana pasada". Tus opciones son acordarte, titular con disciplina o grepear JSONL a mano.
• Los ids de sesión no se recuerdan. Cualquier cosa anterior a la última sesión necesita un id para --session, y primero tienes que ir a buscar ese id.
• El historial es por proyecto. El layout por proyecto mantiene el orden, pero implica que encontrar trabajo de otro repo empieza por hacer cd allí.
• Sin vista entre agentes. Si también usas Claude Code, Codex u opencode, cada uno guarda su historial en su formato y en su sitio. Cuatro agentes son cuatro sitios donde mirar.

Un uso ocasional no choca nunca con estos muros. Un uso diario entre varios repositorios choca con todos, normalmente en la misma semana.

Historial de Kimi Code buscable con CodeAgentSwarm

CodeAgentSwarm corre Kimi Code como agente de primera clase y lee el historial de sesiones que ya guarda en local. Ese historial se convierte en un archivo buscable que abarca todos los proyectos y todos los agentes: tus conversaciones de Kimi Code, Claude Code, Codex, Antigravity CLI y opencode, juntas en una vista.

• Búsqueda de texto completo. Escribe lo que recuerdes (un módulo, un bug, una librería) y busca dentro del contenido de cada conversación, mostrando los mensajes que coinciden para confirmar la sesión antes de abrirla. Sin ids de por medio.
• Filtro por proyecto. Las conversaciones se agrupan por proyecto, cada uno con su color, así que el historial se mantiene legible aunque crezca.
• Vista entre agentes. Busca "refactor de auth" y ve la sesión de Kimi Code donde lo exploraste al lado de la de Claude Code donde lo terminaste.
• Reanudar desde cualquier terminal. Abre una conversación encontrada en un terminal con su contexto, sin navegar al directorio correcto ni copiar un id de sesión.

El flujo dentro de la app es un clic: el botón de History en cualquier terminal abre la vista buscable, y el modo resume al abrir un proyecto lista sus conversaciones pasadas para que elijas exactamente dónde continuar. Es el mismo flujo para todos los agentes, y esa es la gracia: una memoria, no cuatro.

Si corres varios agentes de Kimi Code a la vez, el historial importa el doble, porque "qué hizo ese terminal mientras miraba el otro" pasa a ser pregunta diaria. La guía de múltiples sesiones de Kimi Code cubre ese flujo.

Reanudación nativa vs historial buscable: cuándo basta cada una

Las dos vías reabren una conversación pasada de Kimi Code con su contexto. La diferencia está en cómo la encuentras:

• Volver a tu última sesión: el kimi --continue nativo es perfecto. Nada que mejorar.
• Una sesión antigua bien titulada: lo nativo funciona si encuentras el id; lo difícil era el título y ya lo hiciste.
• Una sesión antigua por contenido: lo nativo no tiene búsqueda; CodeAgentSwarm la encuentra por palabra clave con vista previa de mensajes.
• Trabajo de otro proyecto: lo nativo implica ir allí primero; CodeAgentSwarm busca entre proyectos estés donde estés.
• Trabajo de otro agente: el historial nativo va en silos por herramienta; CodeAgentSwarm los junta todos en una vista.

El resumen honesto: si Kimi Code es tu único agente y titulas sesiones con disciplina, lo nativo te lleva lejos. En cuanto mezclas agentes o proyectos, un único historial buscable deja de ser un lujo. Y si quieres el mismo truco para otros CLIs, las guías hermanas de historial de Claude Code y de historial de opencode cubren sus equivalentes nativos.