Cómo los agentes de IA transformaron la gestión de energía en laptops
Lanzas un agente de IA para codificación antes de cenar — una refactorización multi-archivo que tardará dos horas. Vuelves y encuentras tu MacBook dormido, el trabajo muerto y un diff parcialmente aplicado en tu árbol de trabajo. Ese modo de falla no existía hace cinco años, y señala una brecha real entre cómo macOS maneja la energía y cómo los desarrolladores realmente usan sus máquinas hoy.
Cómo las laptops fueron diseñadas para dormir (y por qué funcionó)
La gestión de energía en laptops fue construida para ritmos humanos. Sin teclado durante unos minutos: oscurece la pantalla. Un poco más: duerme. Los temporizadores de inactividad de Apple tenían sentido porque el trabajo de la máquina era esperarte, y esperar costaba batería.
El modelo se mantuvo durante una década de descargas en segundo plano, compilaciones largas y codificaciones de video porque esas tareas se terminaban rápidamente o mantenían aserciones IOKit para indicar al SO. Un renderizador de video mantiene una aserción de medios; xcodebuild se completa en minutos y sale. La máquina siempre tenía una señal con la que trabajar.
Nada en ese diseño anticipó una carga de trabajo que se ejecuta durante horas sin intervención del usuario y sin límite de finalización natural. Ese escenario simplemente no existía cuando se escribió el modelo de energía.
Qué cambió en las cargas de trabajo con agentes de IA sobre las necesidades del desarrollador
Los agentes de codificación de IA — Claude Code, el agente en segundo plano de Cursor, Aider, GitHub Copilot Workspace — funcionan encadenando docenas de pasos: leer un archivo, planificar una edición, escribir código, ejecutar una prueba, interpretar la salida, iterar. Una sola tarea de refactorización puede ejecutarse durante dos o tres horas.
macOS no ve nada de eso como actividad. No hay evento de teclado, no hay movimiento del mouse, no hay fotograma de pantalla siendo renderizado. El temporizador de inactividad cuenta hacia cero. La pantalla se duerme. El sistema la sigue poco después, terminando la sesión de terminal en medio del trabajo.
Esto no es un error de macOS. El reposo por inactividad es correcto para una máquina que está realmente inactiva. El problema estructural es que el SO no tiene un concepto integrado de un proceso haciendo trabajo cognitivo en nombre del usuario — trabajo que el usuario realmente quiere que se termine.
Guía relacionada¿Qué Es una Capa de Ejecución Segura para Mac?Por qué un simple bloqueo de vigilia crea nuevos riesgos
La solución obvia es un bloqueo de vigilia: caffeinate, Amphetamine o un cambio de pmset. Estos mantienen una aserción de energía IOKit y suspenden el temporizador de inactividad. El agente sigue ejecutándose. Para una sesión corta durante el día mientras estás conectado y cerca, esto es a menudo todo lo que necesitas.
La imagen cambia para el trabajo durante la noche o con batería. Un bloqueo de vigilia ciego no tiene piso de batería. Deja un MacBook ejecutando caffeinate con un 40% de carga con un bucle de agente pesado, y cuatro horas después podrías encontrar la batería en cero, la sesión perdida y un commit parcial en un estado inconsistente. La herramienta hizo su trabajo — mantuvo la máquina despierta — pero no tuvo forma de parar gracefully antes de que se acabara la energía.
El calor es la preocupación más sutil. Un MacBook bajo carga sostenida con flujo de aire limitado se acelera, y un bloqueo de vigilia que nunca verifica el estado térmico no tiene protección. Este riesgo crece en espacios confinados — una tapa casi cerrada, una superficie suave que bloquea las ventilaciones, o una bolsa. El agente se ejecuta; la máquina se ejecuta caliente sin mecanismo para retroceder.
El patrón de tiempo de ejecución seguro para trabajo impulsado por IA
Una capa de tiempo de ejecución segura mantiene la aserción de vigilia y observa las condiciones que harían que la ejecución continua sea insegura. La diferencia es aproximadamente: un bloqueo de vigilia mantiene una puerta abierta; una capa de tiempo de ejecución la mantiene abierta hasta que el sistema señala problemas, luego la cierra gracefully. Entender qué hace una capa de tiempo de ejecución segura es útil contexto si ejecutas cargas de trabajo de IA largas regularmente.
En la práctica esto significa un piso de batería baja — auto-detener a 15 o 20 por ciento para que la máquina pueda despertar cleanly después. Significa verificar la señal térmica que expone el SO y retroceder cuando el sistema reporta presión de calor. Un observador de procesos opcional agrega otra protección: detener la sesión cuando el proceso del agente sale en lugar de ejecutarse hasta que la batería llegue a cero.
Para una ejecución rápida durante el día en energía de CA, caffeinate está bien — no se necesita herramienta extra. Para sesiones durante la noche, con batería, o con tapa cerrada, una capa que monitorea condiciones junto con la aserción de vigilia ayuda a reducir el riesgo de despertar a una máquina muerta o un trabajo que murió en un estado malo.
Una función de LidRun's keep-awake engine.
LidRun mantiene tu trabajo en marcha con la tapa cerrada, con protección de batería y temperatura integrada.
Preguntas frecuentes
No siempre. Para una ejecución corta mientras estás en tu escritorio y conectado, un comando caffeinate simple o una app de mantener vigilia maneja el problema principal: el temporizador de reposo por inactividad. Para ejecuciones más largas, sesiones durante la noche o trabajo solo con batería, también quieres un piso de batería baja y algo de conciencia térmica. Sin eso, la máquina puede drenarse o calentarse sin forma de parar gracefully antes de que algo se rompa.
macOS mide el tiempo de inactividad por intervención del usuario — eventos de teclado, movimiento del mouse y actividad de pantalla. Un agente de IA no genera ninguno de estos; se ejecuta en segundo plano sin tocar dispositivos de entrada. Una vez que el temporizador de inactividad alcanza su umbral, el sistema se duerme y termina la sesión de terminal del agente o suspende completamente su proceso.
Para una máquina conectada en un ambiente estable, caffeinate generalmente funciona bien. Se convierte en un riesgo con batería: caffeinate mantiene la aserción de vigilia pero no tiene piso de batería, así que la máquina puede drenarse a cero en medio del trabajo. Si la batería comienza al 40% y el trabajo toma cuatro horas, la sesión puede no sobrevivir. Una herramienta que auto-detiene a un umbral de batería baja reduce ese riesgo sin requerirte vigilar la ejecución.
Una compilación larga se ejecuta durante minutos, sale cleanly, y muchas herramientas de compilación mantienen aserciones IOKit durante la compilación. Los agentes de IA son abiertos: hacen loops, llaman APIs externas, escriben y prueban código, y pueden ejecutarse durante horas sin tiempo de finalización definido. La combinación de duración larga y finalización impredecible es lo que hace la gestión de energía una preocupación real — una compilación que termina temprano no te cuesta nada; un agente que muere durante la noche te cuesta toda la sesión.