Respuesta corta: si “programar durante 13 horas seguidas” se entiende como dejar a Kimi K2.6 con cualquier base de código grande, irse a dormir y esperar cambios listos para producción sin supervisión, la evidencia pública no llega tan lejos. Lo que sí está respaldado es más limitado: Kimi K2.6 se presenta en varias plataformas como un modelo para long-horizon coding y ejecución agentic, y existen relatos públicos de ejecuciones de 12 a 13 horas; pero esos materiales no equivalen a una prueba reproducible, auditable e independiente.^{[9][20][21][26][28][32]}

Veredicto: no es un bulo, pero tampoco una prueba definitiva

Conviene separar tres niveles de evidencia:

• El posicionamiento del producto está documentado. Microsoft Foundry describe Kimi K2.6 como un modelo multimodal y agentic diseñado para razonamiento de largo horizonte, programación y ejecución autónoma; SiliconFlow y Ollama también lo vinculan con long-horizon coding, orquestación autónoma de agentes, ejecución proactiva y flujos de trabajo tipo swarm.^[20][21][28]
• El caso de 12 a 13 horas existe como relato público. El anuncio del foro de Kimi menciona más de 4.000 llamadas a herramientas y más de 12 horas de ejecución continua; un artículo de DEV Community afirma, citando el blog de lanzamiento de Moonshot, que Kimi K2.6 dedicó 13 horas a reescribir partes de exchange-core, hizo más de 1.000 llamadas a herramientas y modificó más de 4.000 líneas de código.^[9][26]
• La capacidad estable, general y sin supervisión no está probada públicamente. Lo disponible son anuncios, páginas de plataformas, artículos de la comunidad y publicaciones sociales; sirven para rastrear de dónde sale la afirmación, pero no sustituyen un registro completo, repetible y revisado por terceros.^{[9][26][30][32]}

Qué sí sabemos sobre Kimi K2.6

Kimi K2.6 no se presenta simplemente como un chatbot. Microsoft Foundry lo ubica dentro de una nueva clase de modelos multimodales y agentic, pensados para razonamiento de largo recorrido, coding y ejecución autónoma.^[20]

SiliconFlow lo describe como un modelo multimodal de código abierto centrado en long-horizon coding, orquestación autónoma de agentes y diseño guiado por código; además publica cifras de benchmark como 58,6 en SWE-Bench Pro y 86,3 en BrowseComp Agent Swarm.^[21] Ollama, por su parte, lo define como un modelo agentic multimodal y de código abierto, orientado a programación de largo recorrido, diseño basado en código, ejecución autónoma proactiva y orquestación de tareas mediante enjambres de agentes.^[28]

Eso permite una conclusión prudente: Kimi K2.6 está claramente posicionado como un agente de programación de largo recorrido. Pero el posicionamiento comercial y los benchmarks no demuestran por sí solos que pueda encargarse de cualquier repositorio real durante horas, sin vigilancia y con resultados listos para integrar.

De dónde sale la cifra de las 13 horas

La pista pública más directa está en el anuncio del foro de Kimi, que habla de long-horizon coding, más de 4.000 tool calls —llamadas a herramientas externas—, más de 12 horas de ejecución continua y generalización entre lenguajes como Rust, Go y Python.^[9]

El relato más concreto de “13 horas” aparece en fuentes que resumen o comentan el lanzamiento de Moonshot. DEV Community afirma que Kimi K2.6 pasó 13 horas reescribiendo partes del motor open source exchange-core, con más de 1.000 llamadas a herramientas, más de 4.000 líneas modificadas y mejoras de throughput, y presenta el caso como realizado sin intervención humana.^[26] The Neuron también menciona una ejecución de 13 horas en la que K2.6 habría revisado exchange-core e iniciado más de 1.000 llamadas a herramientas.^[30] Una publicación en X de Kimi_Moonshot resume el caso como una ejecución de 13 horas con 12 estrategias de optimización y más de 1.000 tool calls.^[32]

Por tanto, la formulación más precisa es esta: sí hay fuentes públicas que sostienen que existió un caso de 12 a 13 horas; no hay, con lo disponible, una reconstrucción completa que cualquier lector externo pueda auditar y repetir.

Qué falta para convertir la demo en una prueba sólida

Para pasar de “caso anunciado” a “capacidad verificada”, haría falta algo más que una cifra llamativa. Como mínimo, el material público debería permitir responder preguntas como estas:

• ¿Cuál fue el prompt original y la definición exacta de la tarea?
• ¿Cuál era el commit inicial, cuál fue el diff final y qué cambios intermedios se hicieron?
• ¿Dónde está el registro paso a paso de las llamadas a herramientas?
• ¿Qué permisos tenía el agente, en qué sandbox corrió y con qué límites de hardware, coste, tiempo y reintentos?
• ¿Qué comandos de test, scripts de benchmark y criterios de evaluación se usaron?
• ¿Hubo pausas, reinicios, fallos descartados o intervención humana durante el proceso?
• ¿Algún tercero consiguió reproducir el resultado en las mismas condiciones?

Las fuentes consultables aportan números-resumen —duración, llamadas a herramientas, líneas modificadas y el caso exchange-core—, pero no ese paquete completo de evidencia.^[9][26][32] Eso no convierte automáticamente la afirmación en falsa; simplemente impide tratarla como una garantía de fiabilidad general.

No todo depende del modelo

Incluso si el modelo planifica mejor y usa herramientas con más soltura, un agente de programación de muchas horas es también un problema de ingeniería de sistemas. VentureBeat señala que muchos frameworks de orquestación fueron diseñados para agentes que corren durante segundos o minutos, y que los agentes de larga duración exponen límites en la orquestación empresarial y en la gestión de agentes con estado.^[8]

En otras palabras: que un sistema “aguante” 13 horas no depende solo del modelo. También importan el framework de agentes, las interfaces con herramientas, la gestión de estado, la recuperación ante errores, los tests, el monitoreo y las reglas para detener o rehacer una acción.

La disponibilidad del modelo se está ampliando: el changelog de Cloudflare indica que Moonshot AI Kimi K2.6 está disponible en Workers AI, y Microsoft Foundry, SiliconFlow y Ollama tienen páginas o entradas dedicadas al modelo.^{[1][20][21][28]} Pero que un modelo esté disponible en plataformas no equivale a que su supuesto rendimiento durante 13 horas haya sido validado de forma independiente.

Cómo decirlo sin exagerar

Una formulación prudente sería:

• Kimi K2.6 está descrito por varias plataformas como un modelo orientado a long-horizon coding, ejecución agentic y flujos de trabajo con múltiples agentes.^[20][21][28]
• Hay materiales públicos que hablan de ejecuciones autónomas de más de 12 horas o de 13 horas en tareas de programación.^[9][26][32]
• Uno de los casos citados gira en torno a exchange-core, con 13 horas de ejecución, más de 1.000 llamadas a herramientas y más de 4.000 líneas modificadas según fuentes secundarias.^[26][30]

Lo que conviene evitar es:

• Decir que Kimi K2.6 ya fue probado por terceros como capaz de programar 13 horas de forma estable y sin supervisión.
• Convertir un caso de demostración en una promesa para cualquier repositorio grande.
• Tratar una página de producto, un benchmark o una publicación social como si fueran una auditoría técnica completa.

Conclusión

La frase “Kimi K2.6 programó durante 13 horas” no debería descartarse como inventada: hay varias fuentes que apuntan a un caso público de 12 a 13 horas, y el propio posicionamiento de K2.6 gira alrededor de programación de largo recorrido y ejecución agentic.^{[9][20][21][26][28][32]}

Pero la afirmación más fuerte —que Kimi K2.6 ya demostró de forma independiente poder desarrollar software durante 13 horas, de manera estable, general y sin supervisión— todavía no queda probada. La lectura más responsable es: Kimi K2.6 está apostando claramente por agentes de programación de larga duración; las “13 horas” deben leerse como un caso anunciado, no como una garantía verificada de productividad.