Mantenha os agentes de IA rodando enquanto você dorme

Por que o Mac interrompe seu agente de IA à noite

O macOS foi projetado para suspender quando não detecta nenhuma entrada do usuário — teclado, mouse, trackpad. Um agente de IA rodando num terminal não gera eventos de entrada, então o timer de suspensão da tela dispara primeiro, e a suspensão do sistema vem logo depois. No instante em que a máquina suspende, o agente perde o agendamento de CPU e o acesso à rede — a execução para no meio da tarefa sem uma recuperação limpa, nem mesmo um checkpoint salvo, a menos que a própria ferramenta tenha gravado um.

Fechar a tampa é um gatilho separado e mais rápido, e ele não liga para o que está rodando. Por padrão, um MacBook suspende em questão de segundos após a tampa fechar, não importa o que esteja em segundo plano. Uma ferramenta como caffeinate -i bloqueia a suspensão ociosa enquanto a tampa está aberta, mas na bateria ela não consegue impedir a suspensão de clamshell de nível mais baixo que o macOS dispara no instante em que a tampa fecha — nenhuma power assertion em nível de usuário consegue. Essa é uma limitação do macOS, não do caffeinate: toda ferramenta construída sobre o mesmo mecanismo IOPMAssertionCreateWithName, incluindo o próprio Keep Awake manual do LidRun, esbarra na mesma parede sem um mecanismo separado para tampa fechada.

A bateria acrescenta um terceiro modo de falha. O macOS tem seu próprio desligamento por bateria crítica, e pode forçar a suspensão antes desse ponto se decidir que as condições justificam. Um agente fazendo inferência pesada ou um build longo pode derrubar uma bateria de 50% em três a quatro horas. Sem um ponto de parada definido, é o sistema operacional quem decide quando a execução termina — e nem sempre ele escolhe um momento limpo.

As opções nativas e gratuitas — e onde cada uma falha

Antes de recorrer a qualquer app de terceiros, vale saber o que o macOS já oferece de graça, porque para um trabalho curto em primeiro plano isso costuma bastar. caffeinate -i impede a suspensão ociosa enquanto estiver rodando; acrescente -w <pid> e ele sai sozinho quando aquele processo termina — o padrão nativo mais limpo para um único comando que você está acompanhando, por exemplo caffeinate -i -w $(pgrep -f "python train.py"). caffeinate -d também bloqueia a suspensão da tela, e -s bloqueia a suspensão do sistema especificamente na energia AC. Ele vem em todo Mac, não precisa de instalação e é totalmente scriptável.

Só que nada disso sobrevive a uma tampa fechada na bateria. A única alavanca pública que impede a suspensão por fechamento de tampa sem um monitor externo é sudo pmset -a disablesleep 1 — uma configuração de todo o sistema, não uma assertion por processo, e que exige privilégios de administrador. É também o mesmo mecanismo por trás do próprio modo Closed-Lid do LidRun; não há API privada aqui, apenas o toggle documentado do pmset. O outro caminho nativo é o modo clamshell de verdade da Apple: conectar um monitor externo e ficar na energia AC, e o Mac roda de tampa fechada exatamente como previsto, sem precisar de comandos. Essa é a rota oficialmente suportada, mas significa ter e carregar um monitor — nada prático para uma execução durante a noite num quarto de hotel ou num quarto de hóspedes.

Apps de terceiros na barra de menu preenchem o espaço entre esses dois extremos. Amphetamine, KeepingYouAwake, Caffeine e Lungo são todos toggles de keep-awake sólidos e focados — interface polida, timers, alguns com janelas programadas de liga/desliga. São uma escolha justa se o que você quer é simplesmente "fique acordado até eu mandar parar". O que nenhum deles faz é vincular a trava a um processo específico em segundo plano, monitorar o estado de bateria ou térmico, ou liberar automaticamente no instante em que o processo de um agente termina — não é para isso que eles foram feitos.

O risco de fazer isso na mão

Os dois caminhos nativos têm uma aresta perigosa numa execução noturna sem supervisão. caffeinate -i sem -w simplesmente roda até você matá-lo — nada o interrompe automaticamente quando o trabalho termina, então é fácil deixar um Mac acordado gastando bateria por horas depois que o agente já terminou de verdade, e ele ainda é pego de surpresa por uma tampa fechada na bateria.

sudo pmset -a disablesleep 1 é arriscado de outra forma, porque é global e persistente — não fica restrito à sua sessão de terminal nem ao processo que você queria acompanhar. A configuração sobrevive depois que o comando que a definiu já terminou. Se você fechar o terminal, se o Mac travar, ou se simplesmente esquecer de rodar sudo pmset -a disablesleep 0 de manhã, o Mac não vai mais suspender sozinho — nem naquela noite, nem no dia seguinte — até você resetar manualmente ou reiniciar. Enquanto isso, nada está de olho num piso de bateria ou num teto térmico, e nada percebe que o agente na verdade terminou vinte minutos atrás.

Essa é a lacuna real — não que caffeinate ou pmset sejam ferramentas ruins, eles são exatamente certos para um trabalho em primeiro plano que você está acompanhando. A lacuna é que nenhuma das opções gratuitas, e nenhum dos toggles always-on de terceiros, sabe o que significa "o agente terminou". Eles mantêm o Mac acordado ou não; não existe o conceito de liberar ao sair do processo, recuar num piso de bateria, ou recuar por causa de calor.

O padrão mais seguro: vincular o keep-awake ao processo do agente

A solução é o que o LidRun chama de Auto Mode: keep-awake vinculado ao processo, o mecanismo central por trás da camada de runtime segura do LidRun para trabalho de IA no Mac. Ele mantém uma power assertion só enquanto um processo correspondente está rodando e a libera no instante em que esse processo termina — não é um wake lock cego que mantém o Mac acordado independentemente do que está realmente acontecendo. Seu catálogo embutido já reconhece Claude Code, Codex, Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, Ollama, LM Studio e vLLM pelo nome do processo, além de scripts de interpretador (python, node, ruby e outros) e qualquer coisa que você mesmo adicionar com lidrun watch <pattern>.

Ele também é mais cuidadoso do que uma simples correspondência de nome. Uma janela do Cursor apenas aberta e ociosa não mantém o Mac acordado — um app com interface gráfica precisa cruzar um piso real de CPU (acima de aproximadamente 40% de um núcleo) para contar como trabalho, então deixar um editor aberto durante a noite não bloqueia a suspensão sem motivo. E um agente conhecido que ficou quieto por um tempo — esperando uma resposta de API, "pensando" entre chamadas de ferramentas — também não é descartado de imediato: processos de agentes nomeados ganham uma paciência real, até 30 minutos quase ocioso, antes que o Auto Mode os trate como terminados, então uma resposta lenta do modelo não custa a execução inteira.

Para um trabalho pontual via SSH, ou numa máquina headless sem barra de menu para olhar, a CLI encapsula um único comando diretamente: lidrun -- claude-code run-task mantém uma assertion restrita exatamente pela vida daquele único processo, sem precisar configurar lista de observação. O próprio Auto Mode faz parte do LidRun Pro — o plano gratuito cobre execuções ilimitadas de Keep Awake manual, Timer e modo Somente-carregando; a detecção automática de processo é o que o upgrade acrescenta.

Para execuções de tampa fechada, o posicionamento do hardware ainda importa — uma detecção de processo mais inteligente não muda a física do calor. Coloque o Mac sobre uma superfície dura e plana, com ar circulando por baixo: uma mesa, um suporte, uma mesa sólida — não uma cama, não dentro de uma mochila, não num compartimento fechado. Uma tampa fechada elimina o caminho principal de ventilação, então o calor que normalmente escapa pelo teclado precisa ir para outro lugar. Prefira rodar na energia AC: a descarga sustentada da bateria sob carga gera calor adicional em comparação com rodar na tomada. A configuração específica de cada ferramenta está nos guias manter o Claude Code rodando com o MacBook fechado e manter o agente do Cursor rodando no Mac.

Nada disso é totalmente "configure e esqueça", também. Um trabalho com um ponto de parada definido — uma lista de tarefas, um timeout, um arquivo específico para escrever — é mais seguro do que um prompt aberto que pode entrar em loop em erros ou se re-promptar sozinho. Antes de fechar a tampa, confirme que o agente tem onde parar; uma execução que pode entrar em loop indefinidamente vai continuar consumindo energia e gerando calor sem fazer progresso, e o uso de CPU sozinho não consegue distinguir "ainda trabalhando" de "preso num loop".

Configurando os limites de bateria e térmicos

20% é um piso razoável para a maioria das cargas de trabalho noturnas — é também o padrão de fábrica do próprio LidRun, tanto para o auto-stop geral de keep-awake quanto para o piso de bateria do Auto Mode. Isso deixa uma margem real acima do piso rígido de sobrevivência do próprio LidRun (uma rede de segurança de suspensão forçada travada entre 4% e 8%, independentemente do que você configurar) e deixa carga suficiente para realmente usar o Mac de manhã. Para trabalhos mais leves e dependentes de API, em que o agente passa a maior parte do tempo esperando respostas de rede, 15% pode funcionar; para inferência local ou builds pesados, fique em 20% ou mais. O importante é definir um piso, seja qual for — sem um, é o sistema operacional quem decide quando parar, e nem sempre ele escolhe um momento limpo.

Vale a pena configurar limites térmicos mesmo se você confia nas proteções do próprio Mac. O macOS reduz o desempenho da CPU (throttling) antes que qualquer coisa crítica aconteça, mas o throttling significa que o agente vai a passos de lesma por horas a mais em vez de parar de forma limpa — e ficar lento e quente por mais tempo gera mais calor acumulado do que uma parada e reinício deliberados. O Safety Governor do LidRun monitora o estado térmico via API pública ProcessInfo.thermalState da Apple, e é deliberadamente unidirecional: ele nunca mantém o Mac acordado, só libera uma trava ou força uma suspensão quando as condições parecem inseguras. Em calor genuinamente crítico ele libera imediatamente, em qualquer modo e qualquer fonte de energia — mas só escala para uma suspensão forçada de verdade se você estiver longe do teclado ou a tampa estiver fisicamente fechada, então uma sessão ao vivo que você está acompanhando com a tampa aberta nunca é interrompida embaixo de você; ele libera a trava e deixa o próprio throttling do Mac fazer o trabalho.

No Apple Silicon, o software em espaço de usuário consegue ler o estado térmico, mas não controla diretamente a velocidade dos ventiladores — isso é território do kernel, então trate qualquer configuração térmica como um limite de segurança, não um controle ajustável. Combine o piso de bateria com o limite térmico e você tem duas condições independentes de auto-stop: a que a execução atingir primeiro puxa o freio, em vez de deixar o trabalho rodar até o hardware ou o sistema operacional intervir por conta própria. O guia do Safety Governor cobre em mais profundidade como os limites de bateria, térmico e tempo máximo interagem entre si.

Verificando se está realmente funcionando

Antes de fechar a tampa, uma checagem de cinco segundos vale mais do que descobrir às 7 da manhã. O ícone na barra de menu mostra se o LidRun está mantendo uma trava de keep-awake ou de clamshell no momento — dê uma olhada antes de sair. Via SSH, ou numa máquina headless sem barra de menu para consultar, rode lidrun status no terminal; ele mostra o modo atual, se a power assertion está ativa, se o Closed-Lid está ligado, a porcentagem de bateria e o estado de carregamento atuais, o nível térmico e — se o Auto Mode estiver ligado — quais processos monitorados ele está vendo no momento.

Se um processo que você esperava ver monitorado não aparece, lidrun patterns lista tudo que está atualmente na lista de observação, incluindo o catálogo embutido de agentes. Adicione o que estiver faltando com lidrun watch <pattern> — útil para um script wrapper personalizado ou uma ferramenta que não vem sob um dos nomes já reconhecidos.

Recebendo notificação quando o trabalho termina

Notificações push fecham o ciclo — sem elas, você fica checando manualmente ou apenas supondo. O LidRun suporta o ntfy.sh, um relay de notificação gratuito e aberto, para enviar um push ao seu telefone no instante em que a sessão de keep-awake termina; o Pushover também é suportado, se você preferir um app pago e dedicado. Essa sessão termina quando o processo do agente sai, então a notificação é um indicador direto de que o trabalho terminou ou parou — sem precisar de integração de webhook no servidor.

A notificação sinaliza o fim da sessão, não o sucesso do trabalho — se o agente concluiu, deu erro, ou parou porque um limite de bateria ou térmico disparou, aparece do mesmo jeito no seu telefone. Abra o Activity Log para ver o que realmente aconteceu; o LidRun registra o motivo específico da parada — um término normal de tarefa, um auto-stop por bateria ou calor, uma parada manual, ou o Safety Governor liberando a trava — e esse log é local e está sempre lá mesmo se o push nunca chegar. Uma notificação perdida pode acontecer: o ntfy.sh é um relay de terceiros e o Pushover precisa de uma conexão ativa no momento do envio, então, se a rede do Mac oscilou bem na hora em que a execução terminou, confira o log diretamente em vez de supor que nada aconteceu.

Para uma execução mais longa, uma camada opcional de Watchdog (um recurso pago) pode alertar no meio da execução se um agente monitorado ficar quieto por um tempo — possivelmente travado, não terminado — em vez de deixar você descobrir só no final. Trate isso como um aviso, não um veredito: distinguir um agente que travou de um que simplesmente terminou uma tarefa rápido exige mais sinal do que o LidRun tem hoje (duração esperada da tarefa, códigos de saída), então um alerta de agente travado significa "vá dar uma olhada", não "com certeza falhou".

"Meu agente parou mesmo assim" — lendo o motivo da parada

Se o keep-awake estava ligado e mesmo assim a execução parou, o Activity Log quase sempre explica o motivo, e geralmente é uma de três coisas. Se o registro mostra um evento normal de tarefa concluída ou saída de processo, isso não é uma falha — o processo do agente terminou e o Auto Mode liberou a trava exatamente como planejado.

Se for uma parada por bateria ou térmica, é o limite de segurança fazendo o trabalho dele, não um bug — todo o sentido de definir um piso é que ele às vezes dispara. Confira a porcentagem ou o nível térmico no log em comparação com o que você configurou; se estiver disparando antes do esperado, o piso pode estar mais alto do que a carga de trabalho exige, ou o Mac estava na bateria sob uma carga mais pesada do que o normal.

Se o log mostra que o Safety Governor liberou a trava por conta própria, isso só acontece na energia de bateria, quando o LidRun confirmou que nada está realmente rodando e você está longe do teclado há um tempo — um editor de código aberto sem atividade real de CPU é lido como ocioso confirmado, não como trabalho. Rode lidrun status enquanto o agente está ativo para checar se ele realmente aparece como uma tarefa correspondente com CPU real. Se não aparecer, o nome do processo provavelmente não corresponde a nada na lista de observação (confira lidrun patterns e adicione com lidrun watch <pattern>), ou a ferramenta é um app de interface gráfica abaixo do piso de CPU que o Auto Mode usa para distinguir "aberto" de "trabalhando".