Mantén tus agentes de IA funcionando mientras duermes

Por qué el Mac interrumpe a tu agente de IA por la noche

macOS está diseñado para suspenderse cuando no detecta entrada del usuario: teclado, mouse, trackpad. Un agente de IA que corre en una terminal no genera eventos de entrada, así que primero se dispara el temporizador de suspensión de pantalla y después la suspensión del sistema. En el momento en que la máquina se suspende, el agente pierde la asignación de CPU y el acceso a la red: la corrida se detiene a mitad de la tarea, sin una recuperación limpia, ni siquiera un checkpoint guardado, a menos que la propia herramienta haya escrito uno.

Cerrar la tapa es un disparador distinto, más rápido, y no le importa qué esté corriendo. Por defecto, un MacBook se suspende a los pocos segundos de cerrar la tapa, sin importar el trabajo en segundo plano. Una herramienta como caffeinate -i bloquea la suspensión por inactividad mientras la tapa está abierta, pero con batería no puede detener el sleep de clamshell de nivel más bajo que macOS dispara en el instante en que se cierra la tapa — ninguna power assertion a nivel de usuario puede hacerlo. Esa es una limitación de macOS, no de caffeinate: cualquier herramienta construida sobre el mismo mecanismo IOPMAssertionCreateWithName, incluido el Keep Awake manual del propio LidRun, choca con la misma pared sin un mecanismo separado para tapa cerrada.

La batería agrega un tercer modo de falla. macOS tiene su propio apagado por batería crítica, y puede forzar la suspensión antes de llegar a ese punto si decide que las condiciones lo justifican. Un agente haciendo inferencia pesada o un build largo puede consumir un 50% de batería en tres a cuatro horas. Sin un punto de corte definido, es el sistema operativo el que decide cuándo termina la corrida, y no siempre va a elegir un momento limpio.

Las opciones nativas y gratuitas, y dónde falla cada una

Antes de buscar una app de terceros, vale la pena saber qué te da macOS de forma gratuita, porque para un trabajo corto en primer plano suele bastar. caffeinate -i evita la suspensión por inactividad mientras se ejecuta; si le agregas -w <pid>, se cierra automáticamente cuando ese proceso termina — el patrón nativo más limpio para un solo comando que estás vigilando, por ejemplo caffeinate -i -w $(pgrep -f "python train.py"). caffeinate -d también bloquea la suspensión de pantalla, y -s bloquea específicamente la suspensión del sistema con corriente conectada. Viene incluido en todos los Mac, no requiere instalación y es totalmente scriptable.

Pero nada de eso sobrevive a una tapa cerrada con batería. La única palanca pública que evita la suspensión al cerrar la tapa sin un monitor externo es sudo pmset -a disablesleep 1 — un ajuste a nivel de todo el sistema, no una assertion por proceso, y requiere privilegios de administrador. Es también el mismo mecanismo de fondo que usa el propio modo Closed-Lid de LidRun; no hay ninguna API privada aquí, solo el toggle documentado de pmset. La otra vía nativa es el modo clamshell real de Apple: conectas un monitor externo, te quedas con corriente conectada, y el Mac funciona con la tapa cerrada exactamente como está pensado, sin necesidad de comandos. Esa es la ruta oficialmente soportada, pero implica tener y cargar un monitor — poco práctico para una corrida nocturna en un cuarto de hotel o una habitación de repuesto.

Las apps de terceros en la barra de menú llenan el hueco entre esos dos extremos. Amphetamine, KeepingYouAwake, Caffeine y Lungo son toggles de keep-awake sólidos y enfocados — interfaz cuidada, temporizadores, algunas con ventanas programadas de encendido/apagado. Son una opción razonable si lo que quieres es simplemente "mantente despierto hasta que yo diga lo contrario". Lo que ninguna hace es vincular el bloqueo a un proceso específico en segundo plano, vigilar el estado de la batería o la temperatura, o liberarse automáticamente en el momento en que el proceso de un agente termina — esa no es la tarea para la que fueron construidas.

El riesgo de hacerlo manualmente

Las dos vías nativas tienen un lado filoso en una corrida nocturna sin supervisión. caffeinate -i sin -w simplemente corre hasta que lo matas — nada lo detiene automáticamente cuando el trabajo termina, así que es fácil dejar un Mac despierto quemando batería durante horas después de que el agente ya terminó, y de todos modos lo agarra desprevenido una tapa cerrada con batería.

sudo pmset -a disablesleep 1 es riesgoso de otra manera, porque es global y persistente — no está limitado a tu sesión de terminal ni al proceso que te interesaba. El ajuste sobrevive después de que el comando que lo activó termina. Si cierras la terminal, si el Mac se crashea, o si simplemente olvidas correr sudo pmset -a disablesleep 0 por la mañana, el Mac no volverá a suspenderse por sí solo — ni esa noche, ni al día siguiente — hasta que lo reinicies manualmente o reinicies el equipo. Mientras tanto, nada está vigilando un límite de batería ni un techo térmico, y nada nota que el agente en realidad terminó hace veinte minutos.

Ese es el verdadero hueco — no que caffeinate o pmset sean malas herramientas, son exactamente lo correcto para un trabajo en primer plano que estás vigilando. El hueco es que ninguna de las opciones gratuitas, ni ninguno de los toggles siempre-activos de terceros, sabe qué significa "el agente terminó". Mantienen el Mac despierto o no lo mantienen; no existe el concepto de liberarse cuando el proceso termina, de ceder ante un límite de batería, o de ceder ante el calor.

El patrón más seguro: vincular el keep-awake al proceso del agente

La solución es lo que LidRun llama Auto Mode: un keep-awake vinculado al proceso, el mecanismo central detrás de la capa de runtime segura para trabajo de IA en Mac de LidRun. Mantiene una power assertion solo mientras un proceso coincidente está corriendo, y la libera en el instante en que ese proceso termina — no es un wake lock ciego que mantiene el Mac despierto sin importar qué esté pasando realmente. Su catálogo integrado ya reconoce a Claude Code, Codex, Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, Ollama, LM Studio y vLLM por nombre de proceso, además de scripts de intérpretes (python, node, ruby, entre otros) y cualquier cosa que agregues tú mismo con lidrun watch <pattern>.

También es más cuidadoso que una simple coincidencia de nombre. Una ventana de Cursor simplemente abierta e inactiva no mantiene al Mac despierto — una app con interfaz gráfica necesita cruzar un piso real de CPU (por encima de aproximadamente 40% de un núcleo) antes de contar como trabajo, así que dejar un editor abierto toda la noche no bloquea la suspensión sin motivo. Y un agente conocido que se queda callado por un rato — esperando una respuesta de la API, pensando entre llamadas a herramientas — tampoco se descarta de inmediato: los procesos de agentes reconocidos reciben paciencia real, hasta 30 minutos casi inactivos, antes de que Auto Mode los trate como terminados, así que una respuesta lenta del modelo no te cuesta toda la corrida.

Para un trabajo puntual por SSH, o una máquina headless sin barra de menú que revisar, la CLI envuelve directamente un solo comando: lidrun -- claude-code run-task mantiene una assertion acotada exactamente durante la vida de ese proceso, sin necesidad de configurar la watch-list. Auto Mode en sí es parte de LidRun Pro — el nivel gratuito cubre Keep Awake manual, Timer y corridas solo-mientras-carga sin límite; la detección automática de procesos es lo que agrega la actualización.

Para corridas con la tapa cerrada, la ubicación física sigue importando — una detección de procesos más inteligente no cambia la física del calor. Coloca el Mac sobre una superficie dura y plana donde el aire pueda circular por debajo: un escritorio, un soporte, una mesa sólida — no una cama, no dentro de una mochila, no dentro de un mueble cerrado. Una tapa cerrada elimina la vía principal de ventilación, así que el calor que normalmente sale por el teclado necesita otro lugar por dónde salir. Prefiere trabajar con corriente conectada: la descarga sostenida de batería bajo carga genera calor adicional comparado con correr enchufado. La configuración específica de cada herramienta está cubierta en las guías mantén Claude Code corriendo con el MacBook cerrado y mantén el agente de Cursor corriendo en Mac.

Nada de esto es totalmente "configúralo y olvídalo", tampoco. Un trabajo con un punto de parada definido — una lista de tareas, un timeout, un archivo específico que escribir — es más seguro que un prompt abierto que puede quedar en bucle por errores o volver a promptearse a sí mismo. Antes de cerrar la tapa, confirma que el agente tiene dónde detenerse; una corrida que puede repetirse indefinidamente va a seguir consumiendo energía y generando calor sin avanzar, y el uso de CPU por sí solo no puede distinguir "todavía trabajando" de "atascado en un bucle".

Configurar límites de batería y temperatura

20% es un límite razonable para la mayoría de las cargas de trabajo nocturnas — también es el valor por defecto que trae LidRun de fábrica, tanto para el auto-stop general de keep-awake como para el límite de batería de Auto Mode. Deja un margen real por encima del piso duro de supervivencia del propio LidRun (una red de seguridad de suspensión forzada fijada entre 4% y 8% sin importar lo que configures) y deja suficiente carga para realmente usar el Mac por la mañana. Para trabajo más liviano ligado a la API, donde el agente pasa la mayor parte del tiempo esperando respuestas de red, 15% puede funcionar; para inferencia local o builds pesados, mantente en 20% o más. Lo importante es fijar un límite, sea cual sea — sin uno, es el sistema operativo el que decide cuándo detenerse, y no siempre va a elegir un momento limpio.

Vale la pena configurar límites térmicos incluso si confías en las propias protecciones del Mac. macOS reduce el rendimiento de la CPU antes de que pase algo crítico, pero ese throttling significa que el agente se vuelve extremadamente lento por horas extra en lugar de detenerse de forma limpia — y estar lento y caliente por más tiempo genera más calor acumulado que un stop y reinicio deliberados. El Safety Governor de LidRun vigila el estado térmico a través de la API pública de Apple ProcessInfo.thermalState, y es deliberadamente unidireccional: nunca mantiene al Mac despierto, solo libera un bloqueo o fuerza una suspensión cuando las condiciones se ven inseguras. Ante calor genuinamente crítico se libera de inmediato, en cualquier modo y con cualquier fuente de energía — pero solo escala a una suspensión forzada real si estás lejos del teclado o la tapa está físicamente cerrada, así que una sesión en vivo que estás viendo con la tapa abierta nunca se te corta de golpe; en su lugar libera el bloqueo y deja que el propio throttling del Mac haga su trabajo.

En Apple Silicon, el software en espacio de usuario puede leer el estado térmico pero no controlar directamente la velocidad de los ventiladores — eso es territorio del kernel, así que trata cualquier ajuste térmico como un límite de seguridad, no como una perilla. Combina el límite de batería con el límite térmico y obtienes dos condiciones de auto-stop independientes: la que se cumpla primero durante la corrida es la que frena, en lugar de dejar que el trabajo siga hasta que el hardware o el sistema operativo intervengan por su cuenta. La guía del safety governor explica con más detalle cómo interactúan los límites de batería, temperatura y tiempo máximo.

Cómo verificar que realmente está funcionando

Antes de cerrar la tapa, una revisión de cinco segundos es mejor que enterarte a las 7am. El ícono de la barra de menú refleja si LidRun está manteniendo activamente un keep-awake o un bloqueo de clamshell — échale un vistazo antes de alejarte. Por SSH, o en una máquina headless sin barra de menú que mirar, corre lidrun status desde la terminal en su lugar; imprime el modo actual, si la power assertion está activa, si Closed-Lid está encendido, el porcentaje de batería actual y el estado de carga, el nivel térmico y — si Auto Mode está activado — qué procesos vigilados está viendo en ese momento.

Si un proceso que esperabas que estuviera vigilado no aparece, lidrun patterns lista todo lo que está actualmente en la watch-list, incluido el catálogo integrado de agentes. Agrega lo que falte con lidrun watch <pattern> — útil para un script wrapper personalizado o una herramienta que no viene bajo uno de los nombres ya reconocidos.

Cómo recibir una notificación cuando el trabajo termina

Las notificaciones push cierran el ciclo — sin ellas, o revisas manualmente o adivinas. LidRun es compatible con ntfy.sh, un relay de notificaciones gratuito y abierto, para enviar un push a tu teléfono en el instante en que termina la sesión de keep-awake; Pushover también es compatible si prefieres usar una app dedicada de pago. Esa sesión termina cuando el proceso del agente finaliza, así que la notificación es un indicador directo de que el trabajo terminó o se detuvo — sin necesidad de integrar webhooks del lado del servidor.

La notificación indica que la sesión terminó, no que el trabajo tuvo éxito — sea que el agente haya completado la tarea, se haya topado con un error, o se haya detenido porque se activó un límite de batería o temperatura, se ve igual en tu teléfono. Abre el Activity Log para ver cuál de esos fue realmente; LidRun registra el motivo específico de la detención — una finalización normal de tarea, un auto-stop por batería o calor, una detención manual, o el Safety Governor liberando el bloqueo — y ese registro es local y siempre está ahí, incluso si el push nunca llega. Una notificación perdida puede pasar: ntfy.sh es un relay de terceros y Pushover necesita una conexión activa en el momento del envío, así que si la red del Mac tuvo un corte justo cuando terminó la corrida, revisa el registro directamente en lugar de asumir que no pasó nada.

Para una corrida más larga, una capa opcional de Watchdog (una función de pago) puede avisarte a mitad de la corrida si un agente vigilado se queda callado por un rato — posiblemente atascado en lugar de terminado — en vez de dejar que te enteres solo al final. Trátalo como un aviso, no como un veredicto: distinguir un agente que se crasheó de uno que simplemente terminó una tarea rápido necesita más señales de las que LidRun tiene hoy (duración esperada de la tarea, códigos de salida), así que una alerta de agente atascado significa "ve a revisar", no "definitivamente falló".

"Mi agente igual se detuvo": cómo leer el motivo de la detención

Si el keep-awake estaba activado y la corrida se detuvo de todas formas, el Activity Log casi siempre explica por qué, y suele ser una de tres cosas. Si la entrada muestra un evento normal de tarea terminada o de salida del proceso, eso no es una falla — el proceso del agente terminó y Auto Mode liberó el bloqueo exactamente como está diseñado.

Si es una detención por batería o temperatura, eso es el límite de seguridad haciendo su trabajo, no un bug — el sentido de fijar un límite es justamente que a veces se active. Compara el porcentaje o el nivel térmico en el registro con lo que configuraste; si se está activando antes de lo esperado, puede que el límite esté puesto más alto de lo que la carga de trabajo necesita, o que el Mac haya estado con batería bajo una carga más pesada de lo habitual.

Si el registro muestra que el Safety Governor liberó el bloqueo por su cuenta, eso solo pasa con batería, cuando LidRun ha confirmado que en realidad no hay nada corriendo y llevas un rato alejado del teclado — un editor de código abierto sin actividad real de CPU se lee como inactividad confirmada, no como trabajo. Corre lidrun status mientras el agente está activo para verificar que efectivamente aparece como una tarea coincidente con uso real de CPU. Si no aparece, es probable que el nombre del proceso no coincida con nada en la watch-list (revisa lidrun patterns y agrégalo con lidrun watch <pattern>), o que la herramienta sea una app con interfaz gráfica por debajo del piso de CPU que Auto Mode usa para distinguir "abierto" de "trabajando".