O Que É uma Camada de Execução Segura no Mac?

O que uma camada de execução segura realmente faz

Uma camada de execução segura combina três coisas: uma asserção anti-suspensão, monitoramento ativo e um gatilho de liberação automática. A parte da asserção é a metade fácil — qualquer ferramenta pode chamar IOPMAssertionCreateWithName e manter um bloqueio kIOPMAssertionTypePreventUserIdleSystemSleep; o macOS simplesmente obedece. A metade difícil é decidir quando esse bloqueio deve ser liberado: quando a bateria fica baixa demais, quando o chip esquenta, quando a tarefa que justificava manter o Mac ligado já terminou.

O LidRun é uma implementação desse padrão. Ele mantém essa asserção, acompanha o percentual de bateria e o estado de energia (na tomada ou não), lê um sinal térmico do macOS e observa o estado dos processos — depois libera a asserção assim que um limite configurado é ultrapassado. O Mac suspende quando deve, seguindo uma regra que você define (ou os padrões do próprio app) — não por sorte, e não nunca.

Ajuste a necessidade ao tamanho da tarefa. Uma compilação de 20 minutos em um Mac de mesa ligado na tomada quase não precisa de nada disso — a suspensão nunca chegaria a disparar de qualquer jeito. Uma execução de agente de IA de seis horas em um notebook na bateria, que pode esquentar, pode ser desconectado, e que ninguém está observando às 2h da manhã, é uma situação completamente diferente — e é exatamente para ela que esse padrão existe.

Por que o Mac suspende no meio da execução

O macOS não sabe diferenciar "nada está acontecendo" de "um processo de agente em segundo plano está pensando em silêncio há 40 minutos sem nenhuma entrada de teclado ou mouse". Para o temporizador de suspensão por inatividade — que existe justamente para economizar bateria nesse tipo de situação — as duas coisas parecem idênticas. Deixado nos padrões de fábrica, ele vai disparar no meio da execução.

Fechar a tampa é um gatilho separado e ainda mais agressivo. Sem um monitor externo conectado — ou sem algo dizendo explicitamente ao macOS para ignorar o sensor da tampa — fechá-la coloca o Mac para suspender quase que imediatamente, não importa o que ainda esteja rodando por baixo.

E se nenhum dos dois pegar antes, um Mac esquecido na bateria acaba batendo no próprio desligamento por energia crítica quando a carga está quase no fim — não é uma parada limpa, é só o estado em que a tarefa estava quando a energia acabou.

A solução gratuita já embutida: caffeinate e pmset

O macOS já vem com uma resposta de verdade para o primeiro caso. caffeinate -i python train.py envolve um comando, mantém uma asserção anti-suspensão exatamente pelo tempo em que esse comando roda, e libera automaticamente assim que o comando termina — sem instalar nada, sem configurar nada. O próprio wrapper de CLI do LidRun toma emprestado esse mesmo formato: lidrun -- python train.py --epochs 100 envolve um comando do mesmo jeito; a diferença está no que o LidRun faz com esse bloqueio enquanto ele está ativo, explicado mais abaixo.

Para o caso de tampa fechada, o caminho gratuito é sudo pmset -a disablesleep 1 com um monitor externo conectado — o truque clássico do modo clamshell — e depois sudo pmset -a disablesleep 0 para desligar de novo quando terminar. É a mesma configuração de base que o próprio modo Closed-Lid do LidRun usa; a diferença é que o LidRun sempre pareia o 1 com um 0 correspondente, ao parar, ao sair do app, e de novo na próxima abertura, para reconciliar qualquer coisa que tenha ficado pendente de uma queda.

Os dois são legítimos, e para trabalhos curtos, acompanhados de perto e na tomada, qualquer um dos dois costuma ser tudo o que você precisa. Não use uma ferramenta maior do que a tarefa pede.

Onde a solução gratuita chega ao limite

O caffeinate não faz a menor ideia do que está acontecendo com sua bateria. Envolva uma tarefa de várias horas, saia de perto, e se a bateria cair para 2% às 3h da manhã, o caffeinate continua segurando a asserção — ele nunca foi feito para saber que deveria soltar.

O pmset disablesleep é mais arriscado de uma forma bem específica: é uma configuração global e persistente do sistema, não algo restrito a uma sessão. Precisa de sudo. E não se despareia sozinho de volta para 0 — se o que ligou essa configuração travar, ou você simplesmente esquecer, o Mac fica preso se recusando a suspender, drenando a bateria em silêncio, até alguém rodar o comando de reversão manualmente.

Nenhuma das duas ferramentas lê pressão térmica. Nenhuma sabe se o processo que justificava o bloqueio ainda está fazendo trabalho útil ou travou silenciosamente. Elas seguram; não observam. Essa lacuna — que não é um defeito de nenhuma delas, só está fora do que foram feitas para fazer — é o que uma camada de execução segura adiciona por cima.

Os três sinais que uma camada de execução segura realmente observa

O estado da bateria é escalonado, não um corte único. Os padrões do LidRun: abaixo de 15% sem estar na tomada, um aviso; abaixo de 5%, um alerta mais forte; abaixo de aproximadamente 4% — um piso rígido que não pode ser configurado para menos de 4%, seja qual for sua configuração — o LidRun libera todo bloqueio anti-suspensão e pede ao Mac para suspender, em vez de deixar que ele desligue à força no meio de uma escrita. Esse piso existe para deixar o macOS com margem suficiente para gravar o estado em disco e suspender de forma limpa.

O sinal térmico vem de ProcessInfo.thermalState — uma API pública (nominal / fair / serious / critical), sem entitlement especial, disponível desde o macOS 12. É esse sinal que efetivamente comanda a decisão de parar automaticamente. Só que ele pode atrasar em relação à realidade: nos próprios testes do LidRun, ele reportou "fair" enquanto um Mac dentro de uma mochila já tinha caído para 24% de desempenho por throttling. Por isso, em outros pontos — nos Macs onde o sensor SMC pode ser lido — o LidRun também cruza a temperatura real do SoC e o percentual de throttling da CPU com limites calibrados, como uma segunda opinião que a categoria genérica do sistema sozinha nem sempre consegue dar. Quando o SoC realmente chega a "critical", o LidRun libera o bloqueio na hora; se o estado crítico persiste por dois minutos enquanto você está longe do teclado há cinco minutos ou mais, ou a tampa está fisicamente fechada, o LidRun escala a situação e coloca o Mac para suspender de fato, já que um Mac na tomada não necessariamente entra em suspensão por inatividade sozinho.

O estado do processo amarra o bloqueio à própria tarefa. O Auto Mode observa um processo específico — uma sessão do Claude Code, um agente do Cursor, um build — e libera assim que o último processo observado termina. Por baixo disso, um Safety Governor independente pode liberar qualquer sessão anti-suspensão, mesmo uma iniciada manualmente, se o Mac estiver na bateria, offline, e sem nenhuma carga de trabalho ativa confirmada por 15 minutos, ou parado sem carga de trabalho confirmada por 20 minutos. Ele é deliberadamente à prova de falhas em apenas uma direção: essas liberações disparam com uma ausência de trabalho CONFIRMADA, nunca com um estado desconhecido — uma versão anterior também liberava em "desconhecido", e isso colocou o Mac para suspender no meio de uma execução do Claude Code; hoje essa é uma regra aprendida da forma difícil, não um palpite.

O que uma camada de execução segura não faz

Ela não reduz o consumo real de bateria. Manter um Mac ligado e rodando sempre custa mais energia do que deixá-lo suspender — isso vale para qualquer ferramenta anti-suspensão, LidRun incluído. O objetivo não é consumo zero; a suspensão continua sendo o estado mais eficiente que um Mac pode ter. O objetivo é que a execução pare num piso escolhido por alguém, em vez de drenar sem supervisão até 0%.

Ela não resgata um processo travado. O Auto Mode e o wrapper de CLI liberam quando o processo termina, não quando ele "parou de progredir". Um script que congelou mas não caiu ainda aparece como em execução. Para uma tarefa longa sem supervisão, combine a observação de processo com um piso de bateria ou um temporizador como reforço — não conte só com a observação de processo para perceber que algo realmente deu errado.

E ela não controla o resfriamento. O sinal térmico é somente leitura do ponto de vista dessa camada: ela pode decidir parar de manter o Mac ligado para que o macOS faça throttling e esfrie — mas, no Apple Silicon em particular, ela não consegue acelerar as ventoinhas para esfriar a máquina mais rápido. Mantenha o Mac em um lugar ventilado; uma camada de execução segura é uma barreira sobre quando parar, não um substituto para circulação de ar.

Camada de execução segura vs. caffeinate vs. Amphetamine vs. pmset

O caffeinate já vem com o macOS, envolve um comando e mantém uma asserção de energia por uma duração fixa ou até um processo filho terminar. Por design, ele não tem nenhuma noção de bateria, temperatura ou estado offline — nunca foi essa a função dele. Para trabalho curto, acompanhado de perto e na tomada, ele cumpre exatamente o que promete.

O pmset disablesleep é o único caminho gratuito para um Mac de fato com a tampa fechada e um monitor externo. É uma configuração bruta, restrita a administrador, para o sistema inteiro, sem noção alguma de sessão — não sabe o que a acionou, e não vai se desligar sozinha.

O Amphetamine é um app de barra de menu bem polido, com agendas, gatilhos e listas de apps permitidos — ele consegue iniciar e parar sessões por horário do dia ou por qual app está em primeiro plano. O que ele não faz é monitorar o percentual de bateria ao vivo como barreira de segurança nem reagir à pressão térmica do macOS no meio da sessão; isso simplesmente está fora do que ele foi feito para acompanhar.

Uma camada de execução segura adiciona a camada de observação por cima de qualquer uma dessas: piso de bateria, sinal térmico, saída de processo e as verificações de offline/sem supervisão, tudo alimentando a decisão de manter o bloqueio ativo. Para um build de 20 minutos na tomada, o caffeinate ou o Amphetamine já bastam de verdade — não use mais do que isso. O padrão se justifica em execuções longas e sem supervisão, em hardware que pode mudar de estado — bateria, temperatura, rede — de formas que ninguém está observando em tempo real.

Onde o LidRun se encaixa

Keep Awake, Timer e Charging-Only são gratuitos no LidRun — sem limite, sem teste, sem limite de sessões — e já rodam o ciclo principal: manter a asserção, observar a escalada gradual de bateria (15% / 5% / ~4%), ler o sinal térmico, parar automaticamente em qualquer um dos dois. Essa é a camada de execução segura básica, disponível desde a instalação.

O Auto Mode (que amarra o bloqueio a um processo observado, como Claude Code ou Cursor) e o modo Clamshell de tampa fechada fazem parte do Pro, junto com a possibilidade de ajustar os limites padrão de bateria e temperatura em vez de usar os padrões embutidos do LidRun.

Se seu uso cabe na faixa gratuita — uma sessão anti-suspensão, na tomada ou acompanhada manualmente — isso já é o suficiente de verdade; use assim. Se for uma execução de agente de várias horas sem supervisão, amarrada a um processo específico, ou se a tampa precisa ficar fechada, é aí que o restante do padrão (e o plano pago) começa a se justificar. Veja o detalhamento de preços, ou leia como o Safety Governor decide liberar uma sessão que ele mesmo não iniciou, para entender o mecanismo por trás de tudo isso.