Mantén tu Mac despierta solo mientras realmente está trabajando

Una app abierta no es una app trabajando

Un bloqueo de suspensión simple no distingue entre un build que sigue trabajando a fondo y un editor que lleva una hora inactivo. Para él, ambos son solo procesos que existen, así que mantiene la Mac despierta en cualquier caso, y sigue haciéndolo mucho después de que el trabajo realmente terminó.

Pero "la app está abierta" y "la app está trabajando" no son lo mismo. Claude Code esperando en un prompt a que tú respondas no está usando CPU. Un daemon de Ollama sin nada cargado tampoco está usando CPU. Mantener la Mac despierta por cualquiera de los dos solo gasta batería sin ningún motivo.

Auto Mode traza la línea en la actividad, no en la presencia. Vigila una lista de herramientas de desarrollo e IA y se hace una pregunta más precisa para cada una: ¿este proceso está realmente ocupado ahora mismo, o simplemente está corriendo?

La forma gratuita que la gente prueba primero: caffeinate y pmset

macOS ya trae dos formas gratuitas de acercarse a esto, y vale la pena conocerlas antes de instalar cualquier app. caffeinate es una herramienta de línea de comandos integrada: ejecuta caffeinate -i npm run build y la Mac no entrará en suspensión por inactividad mientras ese comando siga corriendo. En el momento en que el build termina, caffeinate se cierra con él, y la aserción desaparece. Eso está genuinamente cerca de mantener una Mac despierta solo mientras trabaja, no cuesta nada, y no requiere ninguna configuración.

Para una configuración con la tapa cerrada, el recurso gratuito un nivel más abajo es sudo pmset disablesleep 1: le dice a macOS que ignore por completo su propia política de suspensión, tapa incluida. Es el mismo interruptor de fondo que termina usando cualquier app de modo clamshell, incluido el propio Closed-Lid de LidRun. Lo activas, cierras la tapa, y la Mac sigue corriendo.

También existe una ruta sin ningún software: conecta un monitor externo, teclado y mouse mientras la Mac está enchufada a la corriente, y el propio comportamiento clamshell de Apple le permite funcionar con la tapa cerrada sin software adicional. Eso sí, solo funciona atada a un monitor y a la corriente, así que no ayuda mucho a una laptop trabajando sola con batería en una cafetería.

Dónde se les acaba el camino a las herramientas gratuitas

caffeinate no tiene forma de saber si el comando que está envolviendo realmente está ocupado. Apúntalo a un REPL interactivo del que ya te alejaste y mantendrá la Mac despierta al 0% de CPU mientras la shell siga abierta, porque nunca revisa la CPU en absoluto: solo comprueba si el proceso sigue existiendo.

pmset disablesleep es más riesgoso de una manera específica: no está atado a nada. Nada lo vuelve a poner en 0 automáticamente. Lo activas una vez para un build nocturno, te olvidas, y la Mac se queda despierta —tapa cerrada, tal vez dentro de una mochila— durante todo el tiempo que ese ajuste siga encendido. Es una forma bien conocida de terminar encontrándose una Mac caliente y sin batería más tarde. Por eso mismo el propio Closed-Lid de LidRun, que usa ese mismo interruptor de pmset, siempre empareja el 1 con un 0 correspondiente al detener, al salir, y otra vez al volver a abrir la app, en lugar de confiar en que alguien se acuerde.

Ninguna de las dos herramientas vigila la batería ni el estado térmico. Mantienen la Mac despierta al 2% de carga o con los ventiladores al máximo con la misma facilidad que al 90% y fría, porque no tienen ninguna señal integrada para eso: manejar esa disyuntiva depende enteramente de ti.

Tampoco ninguna de las dos tiene conciencia de los procesos a lo largo de toda una sesión. Corre Claude Code en una pestaña de terminal, un servidor de desarrollo en otra, y Docker en segundo plano, y caffeinate solo sabe del único PID contra el que lo lanzaste: tendrías que envolver cada comando por separado y acordarte de hacerlo.

Cómo mide la actividad Auto Mode

LidRun vigila las herramientas por nombre de proceso o app bundle, y para los intérpretes de shell —python, node, ruby, perl, bun, deno, java, sh, bash, zsh, php— también lee la línea de comandos, así que un patrón como train.py coincide aunque el proceso que lo ejecuta se llame simplemente "python". Pero detectar es solo la mitad del trabajo.

La CPU es el factor decisivo. Para un proceso de línea de comandos, el piso por defecto es 20% de un núcleo, ajustable de 1% a 50% en Settings. Una app con interfaz gráfica tiene que superar un piso fijo del 40% de un núcleo sin importar cómo esté ese control deslizante: una ventana de Cursor simplemente abierta e inactiva en un solo dígito de CPU nunca cuenta, solo cuenta una que realmente está compilando o indexando. Un proceso de CLI recién nacido recibe el beneficio de la duda en su primera revisión, porque todavía no hay una variación de CPU con la cual compararlo y LidRun prefiere no perderse el inicio de un trabajo real; una app con interfaz gráfica no recibe ese pase gratis.

Los agentes de código conocidos —Claude Code, Codex, el agente de Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, además de runtimes locales como Ollama, LM Studio y vLLM— reciben una capa adicional en cuanto demuestran que hicieron trabajo real al menos una vez: después de eso, cuentan como activos por presencia en lugar de por CPU%, porque un agente esperando la respuesta de un modelo puede quedarse cerca del 0% de CPU sin haber terminado en absoluto. Un agente recién abierto que todavía no hizo nada tiene que ganarse esa confianza de la forma normal, por CPU.

El tiempo de espera, con números reales

Las cargas de trabajo reales son irregulares: un build hace una pausa entre etapas, un agente espera una llamada de red, la inferencia toma aire entre tokens. Si se suelta la aserción en el instante en que baja la CPU, la Mac podría quedarse dormida en medio de un trabajo.

El tiempo de espera por defecto es de 60 segundos, ajustable de 10 a 600 en Settings: después de la última muestra activa, LidRun sigue sosteniendo la Mac despierta durante ese tiempo antes de decidir que el trabajo realmente se detuvo. Un agente conocido que ya demostró trabajo recibe en cambio un tiempo de espera más largo, de 30 minutos, porque quedarse casi inactivo mientras espera una respuesta de API es parte normal del trabajo, no una señal de que terminó.

Con qué frecuencia revisa LidRun es un ajuste distinto de cuánto tiempo espera. El intervalo de sondeo puede ser Fast (5 segundos), Balanced (10 segundos, el valor por defecto) o Battery saver (30 segundos), o cualquier valor exacto de 1 a 60 segundos en Advanced. Una revisión más espaciada cambia algo de capacidad de respuesta por usar menos CPU en segundo plano.

Auto Mode con Closed-Lid, y cómo ver qué está vigilando

Auto Mode y Closed-Lid son interruptores separados, no modos que compiten entre sí, y funcionan juntos. Auto Mode decide si una tarea está realmente activa; Closed-Lid, por su parte, evita que cerrar la tapa fuerce la suspensión. Activa Auto Mode, cierra la tapa con Closed-Lid encendido, y la misma lógica de CPU y tiempo de espera sigue decidiendo si la aserción se mantiene: no se convierte en un bloqueo de suspensión ciego solo porque la pantalla se apagó.

Para ver qué está vigilando en realidad, el menú desplegable de la barra de menú tiene una tarjeta "Active workloads": ahí aparece cada proceso detectado, los activos listados con su CPU% en vivo, y los inactivos-pero-dentro-del-tiempo-de-espera resumidos debajo. Si una herramienta que esperabas ver no aparece ahí en absoluto, esa es la señal honesta para ir a revisar la lista de vigilancia, en lugar de asumir que Auto Mode está fallando.

Por qué dejarla dormir es todo el punto

Un bloqueo de suspensión siempre encendido tiene un costo pase lo que pase: con batería drena la celda, y enchufada igual evita que el chip descanse. El valor de Auto Mode está en que termina cuando termina el trabajo, y por defecto, si nada de lo vigilado ha estado activo durante 20 minutos, LidRun pone la Mac a dormir de forma proactiva en lugar de solo soltar la aserción y esperar el temporizador de inactividad propio de macOS. Tanto esa ventana de 20 minutos como si llega a dormir la Mac o no son ajustables en Settings.

Toda decisión de mantener la Mac despierta pasa por los mismos umbrales de seguridad, sin importar qué modo esté activo. Por defecto, LidRun empieza a reducir la protección al 20% de batería, trata el 5% como crítico, y suelta la aserción por la fuerza en un piso fijo cercano al 4%, sin importar qué siga corriendo. Auto Mode decide cuándo el trabajo justifica mantenerse despierta; la capa de seguridad decide cuándo ya no es seguro hacerlo, punto.

Nada de esto reemplaza el cuidado básico. Configura el piso de CPU y el tiempo de espera una vez y prácticamente olvídate de ellos, pero mantén la Mac bien ventilada durante corridas largas de IA o desarrollo, y trata los umbrales de batería como una barrera de protección, no como un sustituto de enchufarla durante un trabajo de varias horas.

Dónde encaja esto, y cuánto cuesta

Auto Mode forma parte del nivel de pago de LidRun. Keep Awake, el Timer y el modo Charging-only son gratis y sin límite de sesión, pero la detección automática basada en CPU que describe este artículo es Pro. Si lo único que necesitas es "quédate despierta mientras corre este comando", caffeinate o el propio wrapper de CLI de LidRun, lidrun -- <command>, cubren exactamente eso gratis, sin nada del ajuste fino descrito arriba.

Frente a las demás herramientas de la barra de menú: Amphetamine es gratis y tiene el motor de reglas más profundo del grupo —disparadores por app, por red y por batería— pero sus reglas se basan en qué app está corriendo, no en si realmente está ocupada. KeepingYouAwake y Caffeine son interruptores simples, gratis, de un clic, sin ninguna lógica de liberación automática. Lungo es un interruptor de pago basado en temporizador, limpio y directo. Ninguna de las cinco vigila la CPU por proceso como lo hace Auto Mode; ese es un trabajo más específico, no una afirmación de que le gana a cualquiera de ellas en lo que fueron construidas para hacer.