Cómo los agentes de IA cambiaron la gestión de energía en laptops
Los agentes de IA cambiaron la gestión de energía en laptops al romper la única señal que macOS siempre usó para decidir cuándo entrar en reposo: la actividad del usuario. Un agente de programación que lee archivos, edita código y corre pruebas durante dos o tres horas no genera ni una tecla ni un movimiento de mouse, así que macOS interpreta todo eso como tiempo inactivo — y pone la máquina en reposo a mitad de la tarea, matando al agente y dejando atrás un diff a medio aplicar. Esa falla casi no existía hace cinco años, porque casi nada corría sin supervisión durante horas seguidas. Aquí te explicamos por qué pasa, qué hacen realmente las soluciones gratuitas y dónde se quedan cortas.
Por qué el reposo por inactividad tenía sentido — hasta que los agentes de IA rompieron el supuesto
La gestión de energía en laptops se diseñó para los ritmos humanos. Sin entrada de teclado durante unos minutos, se atenúa la pantalla. Un poco más, y entra en reposo. Los temporizadores de inactividad de Apple tenían sentido porque el trabajo de la máquina era esperarte, y esperar costaba batería. La power assertion que una app mantiene para no entrar en reposo está atada a su proceso: en el instante en que la app se cierra o falla, macOS la libera automáticamente. Es una decisión de diseño deliberada, y es justamente por eso que fue seguro construir el modelo así durante treinta años.
El modelo aguantó una década de descargas en segundo plano, compilaciones largas y codificaciones de video porque esas tareas o terminaban rápido, o mantenían una power assertion para avisarle al sistema mientras corrían. Un renderizador de video mantiene una media assertion; xcodebuild termina en minutos y se cierra. La máquina siempre tuvo alguna señal con la que trabajar, y esa señal siempre se limpiaba sola.
Nada en ese diseño anticipó una carga de trabajo que corre durante horas sin ninguna entrada del usuario y sin un límite natural de finalización. Ese escenario simplemente no existía cuando se escribió el modelo de energía.
Por qué tu Mac entra en reposo a mitad de una corrida del agente
Los agentes de IA para programar — Claude Code, el agente en segundo plano de Cursor, Aider, GitHub Copilot Workspace — funcionan encadenando docenas de pasos: leer un archivo, planear una edición, escribir código, correr una prueba, interpretar el resultado, y repetir. Una sola tarea de refactorización puede correr durante dos o tres horas sin nadie frente al teclado.
macOS no ve nada de eso como actividad. No hay evento de teclado, no hay movimiento de mouse, no se renderiza ningún frame en la pantalla. El temporizador de inactividad llega a cero, la pantalla entra en reposo, y el sistema la sigue poco después — terminando la sesión de Terminal a mitad de la tarea.
Si no estás seguro de si esto te pasó de verdad, no confíes en el Monitor de Actividad después del hecho: el proceso simplemente desaparece de la lista. La evidencia más clara está en Terminal: pmset -g log | grep -i sleep lista los eventos reales de reposo y despertar con marca de tiempo, así puedes comparar un vacío en el propio log de tu agente contra un reposo del sistema que macOS registró en ese mismo momento.
Esto no es un bug de macOS. El reposo por inactividad es el comportamiento correcto para una máquina que de verdad está inactiva. El problema estructural es que el sistema operativo no tiene ningún concepto integrado de un proceso haciendo trabajo cognitivo en nombre del usuario — trabajo que el usuario en realidad quiere que termine.
Guía relacionada¿Qué es una capa de ejecución segura para Mac?La solución gratis: caffeinate, pmset y las apps de barra de menú que evitan el reposo
Lo primero que vale la pena probar no cuesta nada y ya viene con macOS. caffeinate -i mantiene el mismo tipo de power assertion que LidRun mantiene para el caso de tapa abierta — la system idle-sleep assertion — y el patrón más limpio es pasarle directamente el comando del agente: caffeinate -i your-agent-command. Así, la assertion queda atada a ese proceso y se libera automáticamente en el momento en que el agente termina, en vez de seguir corriendo hasta que te acuerdes de matarla.
Si prefieres no tocar Terminal, la misma idea está a un clic de distancia en una app de barra de menú. Amphetamine, KeepingYouAwake, Lungo y la muy bien nombrada app Caffeine mantienen el mismo tipo de assertion que caffeinate, pero con un interruptor gráfico y un temporizador en vez de una línea de comandos. Para el caso para el que fueron pensadas — un Mac enchufado, con la tapa abierta, y alguien cerca que note si algo se ve raro — cualquiera de ellas cumple bien.
Nada de esto — ni siquiera caffeinate — mantiene un MacBook corriendo con la tapa cerrada, a menos que tengas un monitor externo conectado. Cerrar la tapa activa una vía de reposo por clamshell distinta y de más bajo nivel, que las assertions de idle-sleep no pueden detener; es un mecanismo diferente al que usan tanto caffeinate como LidRun para el caso de tapa abierta. Si tienes un setup de escritorio, la solución gratis lo es de verdad: conecta un monitor externo (y un teclado o mouse, si el Mac todavía no detecta ninguno), cierra la tapa, y macOS lo trata como una computadora de escritorio — sin necesidad de ninguna herramienta extra. Sin un monitor, la única palanca pública es sudo pmset -a disablesleep 1, que pide contraseña de administrador y viene con una trampa real que cubrimos a continuación.
Dónde se queda corta la solución gratis: batería, calor y un ajuste de pmset atascado
caffeinate y las apps de barra de menú que evitan el reposo no tienen un piso de batería. Deja un MacBook manteniendo una wake assertion con 40% de carga y un agente corriendo en un loop pesado, y es totalmente posible volver y encontrarte con la batería muerta, la sesión perdida y un diff a medio aplicar — la herramienta hizo exactamente lo que prometía, simplemente no tenía manera de detenerse antes de que se acabara la energía. Qué tan rápido pasa esto varía muchísimo: un agente que pasa la mayor parte del tiempo esperando respuestas de una API apenas exige al CPU, mientras que uno corriendo un modelo local puede mantener ocupados todos los núcleos durante horas. Esa imprevisibilidad es justo por qué un piso en porcentaje de batería funciona mejor aquí que un temporizador fijo: no sabes de antemano cuánto te van a costar en batería esas cuatro horas de "trabajo de IA".
El calor es el riesgo más sutil, y es medible, no solo una sensación. macOS por sí mismo solo expone una señal gruesa — ProcessInfo.thermalState, cuatro niveles: Nominal, Fair, Serious, Critical — y esa señal puede ir por detrás de la realidad. En una prueba interna en un MacBook Intel (i7-1068NG7), una carga de trabajo normal con la tapa abierta se mantuvo alrededor de 95°C con el throttle del CPU por encima de 80%; sellado dentro de una mochila bajo la misma carga, el throttle real cayó a más o menos 24% mientras thermalState todavía marcaba "Fair" — el chip ya había empezado a protegerse a sí mismo mucho antes de que la señal a nivel de sistema operativo se pusiera al día. Esa brecha es la razón por la que un wake lock que solo revisa thermalState, o que no revisa nada, no tiene una protección real en un espacio confinado: una tapa casi cerrada, una superficie blanda que tapa las rejillas de ventilación, o una mochila.
La solución alternativa del clamshell tiene su propio modo de falla. pmset -a disablesleep 1 es un ajuste global y persistente, sin ninguna conexión a un proceso específico. Si lo que sea que lo activó falla — un script, una sesión de Terminal, una app — el ajuste se queda en 1 y el Mac no va a volver a entrar en reposo con la tapa cerrada hasta que algo lo devuelva explícitamente a 0 (sudo pmset -a disablesleep 0) o reinicies. Es una trampa real y documentada, no algo hipotético: el ajuste simplemente no tiene forma de saber que el proceso que lo pidió ya no existe.
Un workflow más seguro para corridas largas de agentes de IA
Para una corrida rápida de día, mientras estás en tu escritorio y enchufado, caffeinate o una app de barra de menú están realmente bien — no hace falta ninguna herramienta extra, y es honesto decirlo así.
Para sesiones nocturnas, con batería, o con la tapa cerrada, quieres tres cosas que las herramientas gratis no combinan: un piso de batería para que la corrida se detenga antes de que la máquina muera y no después, conciencia de la presión térmica real en vez de solo la señal gruesa del sistema operativo, y — si la tapa está cerrada — una forma de recuperarse automáticamente si lo que sea que mantiene disablesleep falla, en vez de dejar el Mac atascado. Para eso, más o menos, sirve una capa de runtime segura para trabajo de IA en Mac: no un wake lock más fuerte, sino uno que vigila las condiciones que harían insegura la corrida y se retira con cuidado en vez de seguir corriendo a ciegas.
Si prefieres no manejar la energía local para nada, hay una alternativa legítima: correr el agente en una máquina remota — una VM en la nube, un GitHub Codespace, o una Mac mini siempre encendida a la que te conectas por SSH — y dejar que tu laptop entre en reposo con normalidad mientras el trabajo corre en otro lado. El trade-off es real: pierdes la comodidad de trabajar directamente en tu checkout local, y terminas pagando por cómputo que quizás no necesitarías de otra forma. Para muchos workflows locales, con el repo en su lugar, mantener la laptop despierta y vigilada sigue siendo el camino más simple.
Dónde encaja LidRun
La regla de LidRun es simple: si el agente está corriendo, el Mac se mantiene despierto; si el agente terminó o la situación no es segura, se libera la assertion y se deja que el Mac entre en reposo. El mecanismo es un vigilante de procesos (Auto-Watch) que consulta cada diez segundos los procesos que le digas que rastree, y mantiene la wake assertion solo mientras al menos uno de ellos esté usando de verdad el CPU por encima de un umbral (20% por defecto) — con un período de gracia de 60 segundos, para que un proceso que está momentáneamente inactivo esperando la respuesta de un modelo o una operación de disco no haga que la assertion se prenda y apague todo el tiempo. Cuando ya no queda nada rastreado corriendo, la assertion se libera sola. Esa es la mitad de la promesa que corresponde a "el agente terminó", y no es un temporizador fijo ni algo que tengas que acordarte de apagar.
Del lado de la batería, un umbral de auto-stop que tú defines — 20% por defecto, ajustable entre 15% y 50% — libera la assertion para que macOS pueda entrar en reposo con normalidad en vez de seguir gastando batería. Debajo de eso hay un piso no ajustable de alrededor de 4%: incluso con el auto-stop configurado agresivamente bajo, LidRun igual le pide al Mac que entre en reposo cerca de quedarse sin batería, en vez de dejar que una sesión llegue a un apagado por batería muerta. Del lado térmico, LidRun lee la temperatura real del SMC y el porcentaje de throttle del CPU junto con la señal a nivel de sistema operativo, y se retira alrededor de los 98°C o un throttle igual o menor a 50% (serious), y a los 100°C o un throttle igual o menor a 30% (critical) — más cerca del estado real del hardware que thermalState solo.
El modo Closed-Lid usa la misma palanca pmset -a disablesleep descrita arriba, aplicada a través de un helper privilegiado que se aprueba una sola vez, así no te pide la contraseña de administrador cada vez. Su modo "Sleep when done" pone el Mac en reposo automáticamente después de 10, 20 o 30 minutos sin nada rastreado corriendo, y un heartbeat de crash-guard detecta un valor de disablesleep que quedó atascado en 1 por una sesión anterior que falló, y lo restablece automáticamente la próxima vez que se abre la app — el mismo modo de falla específico descrito arriba, pero cerrado automáticamente en vez de dejarlo para que tú lo encuentres. Un Safety Governor sigue aplicándose por debajo de todo esto: puede detener la assertion o pedir que el Mac entre en reposo cuando la batería o el calor se vuelven inseguros, con la tapa abierta o cerrada.
Keep Awake, el auto-stop de batería y el rastreo de procesos son gratis y sin límite de tiempo — LidRun no pone lo básico detrás de una prueba. El modo Closed-Lid, la función más pesada y más riesgosa, te da un número limitado de corridas gratis para probar antes de pedirte un desbloqueo Pro. Si las corridas nocturnas y con la tapa cerrada de agentes de IA son una parte habitual de tu workflow, y no algo ocasional, vale la pena leer después mantener agentes de IA corriendo mientras duermes.
LidRun mantiene tu trabajo en marcha con la tapa cerrada, con protección de batería y temperatura integrada.
¿Ya tienes LidRun? Lee la guía de configuración →
¿Nuevo en LidRun? Consulta los precios →
Preguntas frecuentes
No siempre. Para una corrida corta mientras estás en tu escritorio y enchufado, caffeinate -i your-agent-command o una app de barra de menú para evitar el reposo resuelve el problema principal — el temporizador de idle-sleep — y no hace falta nada más. Para corridas más largas, sesiones nocturnas, o trabajo solo con batería, también quieres un piso de batería y algo de conciencia térmica, ya que ni caffeinate ni una app gráfica de wake-lock traen ninguna de las dos cosas incorporadas.
macOS mide el tiempo de inactividad a partir de la entrada del usuario — eventos de teclado, movimiento de mouse y actividad de pantalla. Un agente de IA no genera nada de eso; corre en segundo plano sin tocar ningún dispositivo de entrada. Una vez que el temporizador de inactividad llega a su umbral, el sistema entra en reposo y termina la sesión de Terminal del agente, o directamente suspende su proceso.
Para un Mac enchufado en un entorno estable, caffeinate por lo general funciona bien. Se vuelve un riesgo con batería, porque mantiene la wake assertion sin ningún piso de batería — una carga de 40% y un loop de agente de varias horas pueden terminar en 0% con la sesión perdida. Tampoco hace nada por una tapa cerrada sin un monitor externo o pmset -a disablesleep; cerrar la tapa activa una vía de reposo distinta que esa misma assertion no puede detener. Una herramienta que se auto-detiene en un umbral de batería baja, y que trata la tapa cerrada como un caso aparte, reduce ambos riesgos sin que tengas que estar pendiente de la corrida.
Un build largo corre durante minutos, se cierra limpiamente, y muchas herramientas de build mantienen una power assertion durante la compilación. Los agentes de IA son abiertos: hacen loops, llaman APIs externas, escriben y prueban código, y pueden correr durante horas sin un tiempo de finalización definido. Esa combinación de duración larga y final impredecible es lo que convierte la gestión de energía en una preocupación real — que un build termine antes de tiempo no te cuesta nada; que un agente muera durante la noche te cuesta la sesión entera.
El Monitor de Actividad no sirve de nada después del hecho: un proceso que fue matado simplemente desaparece. La señal más clara está en Terminal: corre pmset -g log | grep -i sleep para ver los eventos reales de reposo y despertar con marca de tiempo, y compáralos contra la última marca de tiempo en el log o la salida de tu propio agente. Un vacío que coincide con un evento de reposo registrado lo confirma.
Sí, pero no solo con caffeinate. Cerrar la tapa activa el reposo por clamshell, un mecanismo distinto que las assertions de idle-sleep normales no pueden detener. Las dos opciones gratis son conectar un monitor externo (macOS entonces trata el MacBook cerrado como una computadora de escritorio, sin necesidad de ninguna herramienta extra) o correr sudo pmset -a disablesleep 1, que pide contraseña de administrador y se queda activado hasta que algo lo desactive explícitamente. Una capa de runtime segura que ofrezca un modo dedicado de tapa cerrada — con un reinicio automático si el ajuste queda atascado por un fallo, más las mismas protecciones de batería y calor — te quita la necesidad de estar pendiente de esa segunda opción.