Como os Agentes de IA Mudaram o Gerenciamento de Energia do Notebook

Por Que o Sono por Inatividade Fazia Sentido — Até os Agentes de IA Quebrarem essa Premissa

O gerenciamento de energia do notebook foi construído para ritmos humanos. Sem entrada de teclado por alguns minutos: a tela escurece. Um pouco mais: o Mac dorme. Os temporizadores de inatividade da Apple faziam sentido porque o trabalho da máquina era esperar por você, e esperar custava bateria. A assertion que um app mantém para impedir o sono está vinculada ao processo — no instante em que o app fecha ou trava, o macOS a libera automaticamente. Essa é uma escolha de design deliberada, e é exatamente por isso que esse modelo pôde ser construído com segurança assim por trinta anos.

Esse modelo se manteve firme por uma década de downloads em segundo plano, compilações longas e codificações de vídeo, porque essas tarefas ou terminavam rápido, ou mantinham uma assertion para sinalizar ao sistema operacional enquanto rodavam. Um renderizador de vídeo mantém uma assertion de mídia; o xcodebuild termina em minutos e encerra. A máquina sempre tinha algum sinal para trabalhar, e esse sinal sempre se limpava sozinho.

Nada nesse design previa uma carga de trabalho que roda por horas sem nenhuma entrada do usuário e sem um limite natural de conclusão. Esse cenário simplesmente não existia quando o modelo de energia foi escrito.

Por Que Seu Mac Dorme no Meio de uma Execução de Agente

Agentes de codificação de IA — Claude Code, o agente em segundo plano do Cursor, Aider, GitHub Copilot Workspace — funcionam encadeando dezenas de passos: ler um arquivo, planejar uma edição, escrever código, rodar um teste, interpretar o resultado, repetir. Uma única tarefa de refatoração pode rodar por duas ou três horas sem ninguém no teclado.

O macOS não enxerga nada disso como atividade. Não há evento de teclado, não há movimento de mouse, não há frame de tela sendo renderizado. O temporizador de inatividade chega a zero, a tela dorme, e o sistema segue o mesmo caminho pouco depois — encerrando a sessão do Terminal no meio do trabalho.

Se você não tem certeza se isso já aconteceu com você, não confie no Activity Monitor depois do fato — o processo simplesmente some da lista. A evidência mais clara está no Terminal: pmset -g log | grep -i sleep lista os eventos reais de sono e despertar com horário, então dá para comparar uma lacuna no próprio log do seu agente com um sono do sistema registrado pelo macOS no mesmo instante.

Isso não é um bug do macOS. O sono por inatividade é o comportamento correto para uma máquina genuinamente ociosa. O problema estrutural é que o sistema operacional não tem, por padrão, o conceito de um processo fazendo trabalho cognitivo em nome do usuário — um trabalho que o usuário realmente quer ver concluído.

A Solução Gratuita: caffeinate, pmset e Apps de Wake-Lock na Barra de Menu

A primeira coisa que vale a pena tentar não custa nada e já vem com o macOS. caffeinate -i mantém o mesmo tipo de assertion que o LidRun mantém para o caso de tampa aberta — a assertion de sono por inatividade do sistema — e o jeito mais limpo de usar é passar o comando do agente direto para ele: caffeinate -i your-agent-command. A assertion fica então vinculada àquele processo e se libera automaticamente no instante em que o agente termina, em vez de continuar rodando até você lembrar de encerrá-la.

Se você preferir não mexer no Terminal, a mesma ideia está a um clique de distância em um app de barra de menu. Amphetamine, KeepingYouAwake, Lungo e o aptamente batizado app Caffeine mantêm o mesmo tipo de assertion que o caffeinate mantém, só que com um botão de liga/desliga e um timer em vez de linha de comando. Para o cenário em que eles foram pensados — um Mac ligado na tomada, tampa aberta, alguém por perto para notar se algo parecer errado — qualquer um deles cumpre bem o papel.

Nada disso — nem o caffeinate — mantém um MacBook rodando com a tampa fechada, a menos que haja um monitor externo conectado. Fechar a tampa dispara um caminho de sono separado e de nível mais baixo, o clamshell sleep, que assertions de sono por inatividade não conseguem impedir; é um mecanismo diferente daquele que o caffeinate e o LidRun usam para o caso de tampa aberta. Se você tem uma estação de trabalho fixa, a solução gratuita é realmente gratuita: conecte um monitor externo (e um teclado ou mouse, se o Mac ainda não reconhecer nenhum), feche a tampa, e o macOS trata o Mac como um desktop — sem precisar de nenhuma ferramenta extra. Sem um monitor, a única alavanca pública é sudo pmset -a disablesleep 1, que pede uma senha de administrador e vem com uma pegadinha real, que a gente cobre a seguir.

Onde a Solução Gratuita Para de Funcionar: Bateria, Calor e uma Configuração pmset Travada

O caffeinate e os apps de wake-lock na barra de menu não têm um piso de bateria. Deixe um MacBook com uma wake assertion ativa em 40% de carga rodando um loop pesado de agente, e é perfeitamente possível voltar para uma bateria zerada, uma sessão perdida e um diff pela metade — a ferramenta fez exatamente o que prometeu, só não tinha como parar antes de a energia acabar. A velocidade com que isso acontece varia muito: um agente que fica basicamente esperando respostas de API mal exige da CPU, enquanto um rodando um modelo local pode manter todos os núcleos ocupados por horas. Essa imprevisibilidade é exatamente o motivo pelo qual um piso em porcentagem de bateria funciona melhor aqui do que um timer fixo — você não sabe de antemão quanto vão custar, de fato, quatro horas de "trabalho de IA".

O calor é o risco mais sutil, e é mensurável — não é só uma sensação. O próprio macOS só expõe um sinal grosseiro — ProcessInfo.thermalState, quatro categorias: Nominal, Fair, Serious, Critical — e esse sinal pode ficar atrás da realidade. Em um teste interno num MacBook Intel (i7-1068NG7), uma carga de trabalho normal com a tampa aberta se manteve em torno de 95°C com o throttle da CPU acima de 80%; lacrado dentro de uma bolsa sob a mesma carga, o throttle real caiu para cerca de 24%, enquanto o thermalState ainda marcava "Fair" — o chip já tinha começado a se proteger bem antes de o sinal no nível do sistema operacional acompanhar. Essa lacuna é o motivo pelo qual um wake lock que só verifica o thermalState, ou não verifica nada, não tem nenhuma proteção real em um espaço confinado: uma tampa quase fechada, uma superfície macia bloqueando as saídas de ar, ou uma bolsa.

O workaround do clamshell tem seu próprio jeito de dar errado. pmset -a disablesleep 1 é uma configuração global e persistente, sem nenhuma ligação com um processo específico. Se o que ligou essa configuração travar — um script, uma sessão de Terminal, um app — ela continua em 1, e o Mac não volta a dormir com a tampa fechada até que algo a coloque de volta em 0 explicitamente (sudo pmset -a disablesleep 0) ou você reinicie. É uma pegadinha real e documentada, não hipotética: a configuração simplesmente não tem como saber que o processo que a pediu já foi embora.

Um Workflow Mais Seguro para Execuções Longas de Agentes de IA

Para uma execução rápida durante o dia, com você na sua mesa e o Mac ligado na tomada, o caffeinate ou um app de barra de menu resolvem mesmo — não precisa de nenhuma ferramenta extra, e é honesto dizer isso.

Para sessões durante a noite, na bateria, ou com a tampa fechada, você precisa de três coisas que as ferramentas gratuitas não combinam: um piso de bateria para que a execução pare antes de a máquina morrer, e não depois; consciência real da pressão térmica, e não só o sinal grosseiro do sistema operacional; e, se a tampa estiver fechada, uma forma de se recuperar automaticamente caso o que estiver segurando o disablesleep trave, em vez de deixar o Mac preso naquele estado. É mais ou menos para isso que serve uma camada de runtime segura para trabalho com IA no Mac: não um wake lock mais forte, mas um que observa as condições que tornariam a continuidade da execução insegura e recua com cuidado, em vez de seguir rodando às cegas.

Se você preferir não gerenciar energia local de jeito nenhum, existe uma alternativa legítima: rodar o agente numa máquina remota — uma VM na nuvem, um GitHub Codespace, ou um Mac mini sempre ligado que você acessa via SSH — e deixar seu notebook dormir normalmente enquanto o trabalho roda em outro lugar. A troca é real: você perde a conveniência de trabalhar direto no seu checkout local, e passa a pagar por processamento que talvez nem precisasse. Para muitos workflows locais, com o repositório já no lugar, manter o próprio notebook acordado e protegido ainda é o caminho mais simples.

Onde o LidRun Entra

A regra do LidRun é simples: agente rodando, Mac acordado; agente terminado ou situação insegura, libera e deixa o Mac dormir. O mecanismo é um monitor de processos (Auto-Watch) que verifica a cada dez segundos os processos que você configurou para acompanhar, mantendo a wake assertion só enquanto pelo menos um deles está de fato usando CPU acima de um limite (20% por padrão) — com um período de tolerância de 60 segundos, para que um processo momentaneamente ocioso esperando a resposta de um modelo ou uma operação de disco não fique ligando e desligando a assertion. Quando nada do que está sendo monitorado continua rodando, a assertion se libera sozinha. Essa é a metade "agente terminado" da promessa, e não é um timer fixo nem algo que você precisa lembrar de desligar.

No lado da bateria, um limite de auto-stop que você define — 20% por padrão, ajustável entre 15% e 50% — libera a assertion para que o macOS possa dormir por inatividade normalmente, em vez de deixar a bateria descer até zero. Por baixo disso existe um piso não ajustável em torno de 4%: mesmo com o auto-stop configurado de forma bem agressiva, o LidRun ainda pede para o Mac dormir perto do fim, em vez de deixar a sessão rodar até um desligamento forçado. No lado térmico, o LidRun lê a temperatura real via SMC e a porcentagem de throttle da CPU, junto com o sinal do sistema operacional, recuando por volta de 98°C ou um throttle igual ou abaixo de 50% (nível sério) e 100°C ou um throttle igual ou abaixo de 30% (nível crítico) — mais próximo do estado real do hardware do que o thermalState sozinho.

O modo Closed-Lid usa a mesma alavanca pmset -a disablesleep descrita acima, aplicada por meio de um helper privilegiado aprovado uma única vez, para que não seja preciso digitar a senha de administrador toda vez. O modo "Sleep when done" faz o Mac dormir automaticamente depois de 10, 20 ou 30 minutos sem nada monitorado rodando, e um heartbeat de proteção contra travamentos detecta um valor de disablesleep preso em 1 por causa de uma sessão anterior que travou, e o reseta automaticamente na próxima vez que o app é aberto — o mesmo tipo de falha descrito acima, resolvido automaticamente em vez de ficar esperando você encontrar. Um Safety Governor continua se aplicando por baixo de tudo isso: ele pode parar ou pedir que o Mac durma quando a bateria ou o calor ficam em nível inseguro, com a tampa aberta ou fechada.

O Keep Awake, o auto-stop de bateria e o monitoramento de processos são gratuitos e sem limite de tempo — o LidRun não esconde o básico atrás de um teste grátis. Já o modo Closed-Lid, o recurso mais pesado e arriscado, te dá um número limitado de execuções gratuitas para experimentar antes de pedir o desbloqueio Pro. Se execuções de agentes de IA durante a noite e com a tampa fechada fazem parte regular do seu workflow, e não são só algo ocasional, vale a pena ler em seguida como manter agentes de IA rodando enquanto você dorme.