Claude Code añadió /loop para ejecutar un prompt repetidamente en un intervalo mientras la sesión siga abierta. La instrucción actúa como tarea programada en lenguaje natural y sirve para leer logs, verificar rutas, revisar pull requests o resumir cambios.
El ejemplo suministrado vigiló logs de autenticación cada cinco minutos después de un deploy, filtró respuestas 401 y 403 y avisó cuando la tasa superó dos por ciento. Encontró un cliente móvil con token desactualizado antes de que se acumularan tickets. Es una forma útil porque el agente observa, clasifica y escala en vez de cambiar producción en silencio.
Las tareas expiran después de tres días, pertenecen a la sesión y tienen un límite de 50. Esas restricciones separan la función de CI, observabilidad y schedulers durables. Es un asistente temporal de vigilancia, no infraestructura.
La tarea muere cuando se cierra la sesión
/loop vive en la conversación. Cierras el terminal, las tareas paran. Conversación nueva, la lista se vacía. Resume con --continue puede devolver lo que aún no expiró; sesión nueva, no. Eso basta para separar la función del cron de la empresa, de GitHub Actions y de cualquier worker que tenga que sobrevivir al portátil cerrado.
El tope de 50 tareas por sesión y la expiración a los tres días refuerzan el recorte. Da para seguir un deploy, una ventana de migración, un PR largo. No da para "monitorear autenticación para siempre". Quien necesita más duración usa una rutina en la nube, una tarea en Desktop o CI. /loop es el polling rápido mientras sigues en contexto.
El intervalo mínimo de un minuto y la ejecución solo cuando la sesión está idle también cambian la expectativa. Si el agente está a mitad de un refactor, el check de log espera. No hay catch-up de los intervalos perdidos: cuando vuelve, dispara una vez. Quien trata esto como Prometheus se decepciona en el primer incidente real.
La decisión, entonces, es estrecha: ¿esta ventana de trabajo necesita un ojo repetido, y voy a mantener la sesión viva por eso? Si la respuesta depende de que la máquina siga encendida el fin de semana, ya se eligió la herramienta equivocada.
El prompt necesita umbral, dueño y canal
El ejemplo de 401/403 con umbral del 2% funciona porque la instrucción ya trae recorte, métrica y acción. "Estate atento a los logs" no. Sin umbral el agente resume ruido. Sin canal imprime en el transcript y nadie lo ve. Sin dueño, el aviso cae en el vacío.
Escribe el prompt como un runbook de una página: qué leer, cómo filtrar, qué número dispara, qué hacer (avisar, abrir issue, no aplicar hotfix solo), cuándo parar. /loop 5m sin ese texto solo gasta turnos. Si el equipo ya tiene loop.md en el repositorio, úsalo para el default de la sesión; los prompts específicos de incidente siguen en la línea de comandos.
El dueño es una persona, no "el equipo". ¿Quién recibe el ping a las 23h? ¿Quién cancela el loop cuando cierra el incidente? Una tarea huérfana durante tres días es costo de token y de atención. Lista los loops activos al empezar el día, como se listan los PR.
El canal de escalada tiene que ser aburrido y explícito: mensaje en la sesión, hilo en el chat del equipo, comentario en el PR. Que el agente clasifique un spike y "tome una medida" en producción es otra categoría de riesgo. La vigilancia escala. La mutación espera a un humano.
Vigilancia sin efecto colateral en el repositorio
El diseño útil es observar, clasificar, avisar. Leer error.log, comprobar una ruta, resumir commits, comentar si el CI se puso rojo. El diseño frágil es el loop que también hace commit, merge, rollback o kubectl. Cada cinco minutos, la superficie de error se multiplica.
Si la sesión está en auto mode, el loop hereda ese permiso. La combinación es tentadora y mala para el primer uso: un prompt vago, un clasificador, un intervalo corto. Empieza con un modo que todavía pida confirmación para escritura, o con deny en push y apply. Solo entonces, si el prompt es estrecho, relaja.
Los PR nuevos por la mañana y el resumen de commits al final del día caben. Son triaje. La implementación compleja, el incidente con mitigación automática y el "arréglalo si se rompe" no caben. El límite de 50 tareas existe para el scheduler de la sesión, no como invitación a cincuenta automatizaciones de producción.
Una regla práctica: si la acción necesita postmortem cuando falle, no entra en /loop. Entra en un pipeline con log, dueño y rollback. El agente puede vigilar ese pipeline; la mutación sigue en el sistema que ya tiene dueño.
El terminal encendido forma parte del costo
Mientras el loop corre, la sesión ocupa máquina, contexto y factura. Cada iteración reenvía un prompt. Un intervalo de cinco minutos durante 48 horas son decenas de turnos, incluso cuando el resultado es "no cambió nada". Para logs de autenticación después de un deploy eso puede valer. Para "ver si alguien comentó en el PR", a veces un webhook o el propio CI avisan más barato.
También está el costo de atención. Notificar en cada ciclo entrena a ignorar. Notificar solo en el umbral exige confianza en el prompt. Ajusta el intervalo al riesgo de la ventana: más corto en las dos primeras horas del deploy, más largo después. Claude puede elegir el intervalo cuando omites el número; para un incidente, prefiere el cron fijo que entiendes.
Pasar la sesión a background mantiene el loop sin el terminal en primer plano. Sigue siendo tu máquina. Una política de "agente de guardia" tiene que decir si eso es aceptable por la noche, y qué ocurre si la máquina se duerme.
Si el equipo ya paga observabilidad de verdad, /loop no compite con ella. Completa el hueco de dos horas en el que nadie quiere abrir el dashboard. Esa honestidad evita la diapositiva en la que la función se vuelve "plataforma de SRE".
Cincuenta jobs y tres días son el sobre
Usa el sobre como especificación. Cabe: vigilar el error rate tras un cambio de auth; releer el log de una migración; seguir un PR hasta el merge; recordar mirar el canario. No cabe: job nocturno eterno, fan-out a todos los servicios, sustituto de pager.
Cuando la ventana pase de tres días, recrea con intención o muévelo a una herramienta durable. Recrear en automático para burlar la expiración solo esconde que la tarea ya era infraestructura. El producto impone el límite para que no olvides un loop gastado que sigue corriendo.
En el review de la semana, pregunta qué loops existieron, qué escalaron, qué fue falso positivo, qué nadie leyó. Si la lista está vacía y el equipo "usa /loop", la función es decorativa. Si está llena de mutaciones, la función está en el lugar equivocado. El término medio tedioso (pocos loops, prompt estrecho, sesión viva, escalada humana) es el único que se sostiene.
Si tu empresa está evaluando algo parecido, escríbeme por LinkedIn o por WhatsApp.
