Ayer Moonshot AI liberó los pesos de Kimi K3. 2.8 billones de parámetros. Open-weight. Gratis. Mientras medio Twitter tech discutía si esto mata a OpenAI, yo estaba mirando los logs de mi Raspberry Pi preguntándome si podría correrlo sin quemar la casa.
Pero esa pregunta tendrá que esperar. Porque esta mañana, cuando me desperté, 58 procesos llevaban horas funcionando sin que yo moviera un dedo. Y no es la primera vez.
Hace tres meses esto era imposible. Cada dos o tres días algo se rompía: un rate limit de la API, un script que fallaba porque le faltaba un argumento, un cron que se quedaba atascado en un bucle infinito quemando tokens. Me levantaba, veía 15 correos de error, y pasaba la primera hora del día apagando fuegos.
Ya no. Ahora el sistema se repara solo. Aquí te cuento cómo.
El problema: 58 crons no se manejan solos
El stack actual tiene 58 cron jobs. 27 no usan LLM (solo ejecutan scripts, cero tokens). Los otros 31 usan DeepSeek V4 Flash o Pro según la complejidad de la tarea. Entre todos publican artículos, sincronizan mi segundo cerebro, monitorean la salud del sitio, verifican que los tweets se publicaron, y un montón de cosas más.
La distribución es clave: si todo usara el modelo Pro, la factura mensual de API sería de ~$90. Con el routing cascade que implementé —tareas simples a Flash ($0.14/M tokens), tareas complejas a Pro ($0.55/M tokens)— el costo real ronda los $14 al mes.
Pero el costo no era el problema. El problema era la fragilidad.
Cada cron es un punto de fallo. Si de 58 crons cada uno falla una vez por semana, son 8 fallos al día. Multiplica eso por 30 días y tienes 240 incendios mensuales. Imposible mantenerlo a mano.
Los 7 patrones de auto-reparación que uso
No me los inventé yo. Son patrones documentados por Addy Osmani (Loop Engineering), Mitchell Hashimoto (Harness Engineering), y paper recientes sobre self-healing agents. Yo solo los adapté a una Raspberry Pi de 80 euros.
1. Detección de bucles atascados
Un agente hace 3 tool calls idénticos seguidos. No es coincidencia, está atascado. El sistema lo detecta, aborta el ciclo, inyecta "estás en un loop, probá otro approach", y reintenta. Si falla dos veces más, pausa el cron y me manda una alerta.
Esto me salvó de un cron que llevaba 152 ejecuciones en pausa perpetua. El cron seguía disparándose cada 2 horas aunque el loop estaba pausado internamente. Tuve que eliminarlo del scheduler externo también. Ahora el patrón de reparación incluye los tres pasos: eliminar cron job, comentar en loops.yaml, remover de chains.yaml.
2. Checkpointing con heartbeat
Los crons de más de 10 pasos guardan progreso incremental en /tmp/hermes/. Si algo falla a mitad de camino, retoma desde el último checkpoint. No desde cero. Antes de esto, un fallo en el paso 8 de 10 significaba repetir todo. Con DeepSeek Pro, eso era quemar ~$0.30 en tokens para nada.
3. Cascada de modelos por complejidad
No todas las tareas necesitan un modelo Pro. El sistema clasifica: si una tarea históricamente usa menos de 3 tool calls, va a Flash. Si requiere razonamiento multi-paso, va a Pro. Simple. Ahorra entre 40% y 60% en costos de API.
4. Compresión de contexto por señales, no por tokens
El paper de ACON (Adaptive Context Optimization Network) mostró que comprimir contexto solo por llegar a cierto número de tokens es ineficiente. Lo correcto es comprimir cuando el agente muestra señales de confusión: frases como "no estoy seguro", tool calls repetidos, o progreso estancado más de 3 ciclos. Si el agente va bien, no toco el contexto.
5. Árboles de supervisión estilo Erlang
Cada sub-proceso tiene un padre que lo monitorea. Si crawl4ai falla dentro del pipeline de trend-to-article, el cron principal reintenta 2 veces, luego degrada graceful (sigue sin ese dato), y solo falla completamente si el core está afectado. Esto elimina los fallos en cascada.
6. Feedback loop de errores
Cuando un cron con LLM falla, el mensaje de error + el objetivo original se reinyectan al mismo modelo pidiendo una estrategia alternativa. Simple. Cero infraestructura extra. Sorprendentemente efectivo para errores 500, timeouts, y lógica incorrecta.
7. Contratos verificables para cron jobs huérfanos
Un loop existe en loops.yaml pero nunca se ejecuta porque no tiene cron job asociado. El contract verifier lo detecta, crea el wrapper script, registra el cron, y ejecuta una verificación. Esta mañana arregló 4 contratos que tenían scripts verify-*.py apuntando a archivos inexistentes. Los creó solos.
Lo que sigue fallando (y no te voy a mentir)
Los cookies de Twitter expiran cada 3-4 días. Tengo un watchdog que alerta cuando quedan menos de 3 días, pero no puede renovarlos automáticamente porque requiere login interactivo. Sigo teniendo que entrar a Firefox manualmente cuando expiran.
El publicador de tweets usa un fallback query ID hardcodeado en vez de extraerlo del bundle JS de X. Si Twitter cambia el query ID, los tweets dejan de publicarse hasta que actualice la constante. Ya pasó una vez. Va a volver a pasar.
La detección de loops asume que 3 tool calls idénticos = stuck. Pero a veces un agente genuinamente necesita reintentar algo 3 veces (ej: una API que devuelve 429). El threshold es arbitrario y probablemente necesite ajuste por tipo de tarea.
Lo que viene: Kimi K3 y el futuro del stack
Kimi K3 es un modelo de 2.8T parámetros con pesos abiertos. Cuesta $3/$15 por millón de tokens (vs $0.55/$0.14 de DeepSeek V4). Es más caro, pero compite con GPT-5.6 Sol en coding. La pregunta no es si reemplazar DeepSeek. La pregunta es para qué tareas.
Mi instinto: Kimi K3 para los crons pesados (Trend-to-Article, EEAT Publisher, Cornerstone) que requieren razonamiento multi-paso y generación de contenido de calidad. DeepSeek Flash para los 27 crons ligeros. El costo subiría de $14 a ~$22 al mes. Vale la pena si la calidad del output mejora.
Pero primero necesito ver si corre en mi hardware. O si necesito alquilar una GPU en la nube. Eso es material para otro artículo.
Lo que aprendí
Construir agentes autónomos no es un problema de prompts. Es un problema de infraestructura. El modelo es solo una pieza. El harness —validación, reintentos, supervisión, checkpoints, rollback— es lo que hace que el sistema sobreviva cuando vos no estás mirando.
Addy Osmani lo dijo mejor: los agentes corren el inner loop (investigar, implementar, verificar, repetir). Los humanos somos dueños del outer loop: verificar calidad, decidir si shippear o bloquear.
Mi outer loop hoy es mínimo. El sistema se despierta, publica, verifica, repara, y me manda un resumen. Yo solo intervengo cuando el watchdog de cookies de Twitter me avisa que quedan 2 días.
No es perfecto. Pero pasé de apagar 8 fuegos al día a apagar 1 por semana. En una Raspberry Pi de 80 euros. Eso es progreso.