Mantenha o Mac acordado só enquanto ele está realmente trabalhando

Um app aberto não é um app trabalhando

Um wake lock comum não consegue distinguir entre um build que está moendo dados sem parar e um editor que está ocioso há uma hora. Para ele, os dois são só processos que existem, então ele mantém o Mac acordado do mesmo jeito — e continua mantendo muito depois que o trabalho já terminou de verdade.

Mas "o app está aberto" e "o app está trabalhando" não são a mesma coisa. Claude Code parado num prompt esperando você digitar não está consumindo CPU. Um daemon do Ollama sem nada carregado também não está consumindo CPU. Manter o Mac acordado por causa de qualquer um dos dois é só gastar bateria à toa.

O Auto Mode traça a linha na atividade, não na presença. Ele observa uma lista de ferramentas de dev e IA e faz uma pergunta mais precisa para cada uma: esse processo está realmente ocupado agora, ou só está rodando?

O caminho gratuito que as pessoas tentam primeiro: caffeinate e pmset

O macOS já vem com duas formas gratuitas de chegar perto disso, e vale a pena conhecê-las antes de sair atrás de qualquer app. caffeinate é uma ferramenta de linha de comando nativa: rode caffeinate -i npm run build e o Mac não vai entrar em modo de espera enquanto esse comando estiver rodando. No instante em que o build termina, o caffeinate encerra junto, e a assertion desaparece. Isso chega genuinamente perto de manter um Mac acordado só durante o trabalho, não custa nada e não exige nenhuma configuração.

Para uma configuração de tampa fechada, o recurso gratuito um nível abaixo é sudo pmset disablesleep 1 — ele diz ao macOS para ignorar completamente sua própria política de suspensão, tampa incluída. É o mesmo interruptor por trás de todo app de modo clamshell, incluindo o próprio Closed-Lid do LidRun. Basta ativar, fechar a tampa, e o Mac continua rodando.

Também existe um caminho sem nenhum software: conecte um monitor externo, teclado e mouse enquanto o Mac está na tomada, e o próprio comportamento clamshell da Apple permite rodar com a tampa fechada sem nenhum software extra. Só que isso funciona apenas preso a um monitor e à energia — não ajuda muito um notebook trabalhando sozinho, na bateria, num café.

Onde as ferramentas gratuitas param de dar conta

O caffeinate não tem a menor ideia se o comando que ele está envolvendo está realmente ocupado. Aponte-o para um REPL interativo do qual você se afastou, e ele mantém o Mac acordado a 0% de CPU enquanto o shell continuar aberto, porque ele nunca olha para a CPU — só checa se o processo ainda existe.

pmset disablesleep é arriscado de um jeito específico: não está atrelado a nada. Nada volta ele para 0 automaticamente. Ative uma vez para um build de madrugada, esqueça, e o Mac vai ficar ali acordado — tampa fechada, possivelmente dentro de uma mochila — pelo tempo que a configuração ficar ligada. É um jeito conhecido de as pessoas encontrarem depois um Mac quente e com a bateria zerada. É exatamente por isso que o próprio Closed-Lid do LidRun, que usa esse mesmo interruptor do pmset, sempre pareia o 1 com um 0 correspondente ao parar, ao sair do app e de novo ao reabrir — em vez de confiar que alguém vai lembrar.

Nenhuma das duas ferramentas observa a bateria ou o estado térmico. Elas mantêm o Mac acordado a 2% de carga ou com os coolers no máximo com a mesma facilidade que a 90% e frio, porque simplesmente não existe nenhum sinal embutido para isso — gerenciar essa troca é inteiramente responsabilidade sua.

Nenhuma das duas também tem consciência de processos ao longo de uma sessão inteira. Rode Claude Code numa aba do terminal, um dev server em outra e o Docker em segundo plano, e o caffeinate só sabe sobre o PID único com o qual você o iniciou — você precisaria envolver cada comando separadamente, e lembrar de fazer isso.

Como o Auto Mode mede a atividade

O LidRun observa ferramentas pelo nome do processo ou pelo app bundle, e para interpretadores de shell — python, node, ruby, perl, bun, deno, java, sh, bash, zsh, php — ele também lê a linha de comando, então um padrão como train.py é reconhecido mesmo que o processo que o executa se chame apenas "python". Mas a detecção é só metade do trabalho.

A CPU é o fator decisivo. Para um processo de linha de comando, o piso padrão é 20% de um núcleo, ajustável de 1% a 50% em Configurações. Um app de GUI precisa ultrapassar um piso fixo de 40% de um núcleo, não importa como esse controle esteja ajustado — uma janela do Cursor apenas aberta, ociosa na casa de um dígito, nunca conta; só conta uma que esteja de fato compilando ou indexando. Um processo de CLI recém-criado ganha o benefício da dúvida na primeira checagem, já que ainda não há uma variação de CPU para comparar e o LidRun prefere não perder o início de um trabalho de verdade; um app de GUI não recebe esse passe livre.

Agentes de codificação conhecidos — Claude Code, Codex, o agente do Cursor, Windsurf, Aider, Cline, Continue, Goose, OpenHands, Zed, além de runtimes locais como Ollama, LM Studio e vLLM — ganham uma camada extra depois que provam ter feito trabalho real pelo menos uma vez: a partir daí, passam a contar como ativos pela presença, não pelo %CPU, porque um agente esperando a resposta de um modelo pode ficar perto de 0% de CPU sem de fato ter terminado. Um agente recém-aberto que ainda não fez nada precisa conquistar essa confiança do jeito normal, pela CPU.

O tempo de espera, com números reais

Cargas de trabalho reais são irregulares — um build pausa entre etapas, um agente espera uma chamada de rede, a inferência recupera o fôlego entre tokens. Liberar a assertion no instante em que a CPU cai faria o Mac dormir no meio de um trabalho.

O tempo de espera padrão é 60 segundos, ajustável de 10 a 600 em Configurações: depois da última amostra ativa, o LidRun continua segurando por esse período antes de decidir que o trabalho realmente parou. Um agente conhecido que já provou ter trabalhado ganha um tempo de espera maior, de 30 minutos, porque ficar quase ocioso enquanto espera uma resposta de API é parte normal do trabalho, não um sinal de que terminou.

Com que frequência o LidRun checa é um ajuste separado de quanto tempo ele espera. O intervalo de verificação pode ser Rápido (5 segundos), Balanceado (10 segundos, o padrão) ou Economia de bateria (30 segundos) — ou qualquer valor exato de 1 a 60 segundos em Avançado. Uma checagem mais espaçada troca um pouco de responsividade por menos uso de CPU do próprio LidRun em segundo plano.

Auto Mode com Closed-Lid, e como ver o que ele está observando

Auto Mode e Closed-Lid são interruptores separados, não modos concorrentes, e funcionam juntos. O Auto Mode decide se uma tarefa está genuinamente ativa; o Closed-Lid, à parte, impede que fechar a tampa force o sono. Ative o Auto Mode, feche a tampa com o Closed-Lid ligado, e a mesma lógica de CPU e tempo de espera continua decidindo se a assertion se mantém — não vira um wake lock cego só porque a tela apagou.

Para ver o que ele está de fato observando, o menu suspenso da barra de menus tem um card "Cargas de trabalho ativas": todo processo reconhecido aparece ali, os ativos listados com %CPU ao vivo, e os ociosos-mas-dentro-do-tempo-de-espera resumidos logo abaixo. Se uma ferramenta que você esperava não aparece de jeito nenhum, esse é o sinal honesto para ir conferir a lista de observação, em vez de presumir que o Auto Mode está quebrado.

Por que deixar o Mac dormir é o objetivo

Um wake lock sempre ligado tem um custo, aconteça algo ou não: na bateria, ele drena a carga; na tomada, ainda assim impede o chip de descansar. O valor do Auto Mode está em terminar quando o trabalho termina — e, por padrão, se nada do que é observado esteve ativo por 20 minutos, o LidRun coloca o Mac para dormir proativamente, em vez de simplesmente liberar a assertion e esperar o próprio timer de inatividade do macOS. Tanto essa janela de 20 minutos quanto a opção de dormir ou não são ajustáveis em Configurações.

Toda decisão de manter o Mac acordado ainda passa pelos mesmos limites de segurança, não importa qual modo esteja ativo. Por padrão, o LidRun começa a reduzir em 20% de bateria, trata 5% como crítico, e força a liberação num piso rígido perto de 4%, independente do que ainda esteja rodando. O Auto Mode decide quando ficar acordado se justifica pelo trabalho; a camada de segurança decide quando isso deixa de ser seguro, ponto final.

Nada disso substitui os cuidados básicos. Configure o piso de CPU e o tempo de espera uma vez e esqueça na maior parte do tempo — mas mantenha o Mac ventilado em execuções longas de IA ou dev, e trate os limites de bateria como uma proteção extra, não como substituto de deixar na tomada durante um trabalho de várias horas.

Onde isso se encaixa, e quanto custa

O Auto Mode faz parte do plano pago do LidRun. Keep Awake, o Timer e o modo Charging-only são gratuitos e sem limite de sessão, mas a auto-detecção baseada em CPU descrita neste artigo é Pro. Se tudo que você precisa é "ficar acordado enquanto este comando roda", o caffeinate ou o próprio wrapper de CLI lidrun -- <command> do LidRun cobrem exatamente isso de graça, sem nenhum dos ajustes finos acima.

Comparando com as outras ferramentas de menu bar: o Amphetamine é gratuito e tem o motor de regras mais profundo do grupo — gatilhos por app, por rede e por bateria — mas suas regras são sobre qual app está rodando, não sobre se ele está realmente ocupado. KeepingYouAwake e Caffeine são toggles simples, gratuitos, de um clique, sem nenhuma lógica automática de liberação. Lungo é um toggle pago, limpo, baseado em timer. Nenhuma das cinco observa a CPU por processo como o Auto Mode faz; isso é um trabalho mais específico, não uma alegação de que ele supera qualquer uma delas naquilo que foram feitas para fazer.