Da última vez que perdi uma execução de agente durante a noite, nada rebentou. Nem um erro. Tinha lançado uma migração longa num repositório que andava a evitar há meses, vi-a moer a parte chata do início e fechei o portátil porque já tinha acabado o dia. Voltei a abri-lo na manhã seguinte num café. A sessão tinha desaparecido. Não falhou. Parou, algures a meio, com um branch feito pela metade e sem qualquer registo do que estava prestes a fazer a seguir.
E eu já tinha aplicado a solução. É essa a parte que me apanhou.
Portanto isto é sobre porque é que aquela solução nunca iria funcionar, e sobre a máquina alugada, extremamente aborrecida, que faz o trabalho em vez dela. É o que uso agora para correr agentes de IA 24/7, e deixei por completo de pensar nas definições de energia do meu portátil.
A solução que toda a gente recomenda
caffeinate -dimsu. Ou uma app na barra de menus com um ícone de chávena de café. Ou, se foi escavar, sudo pmset -a disablesleep 1, que é a opção nuclear e aquela que aparece nos conselhos que soam mais seguros de si. Foi essa que executei. Deu a sensação de estar a resolver o problema.
O macOS tem mais do que uma maneira de adormecer, e as duas que aqui interessam são independentes uma da outra: a suspensão por inatividade é um temporizador que corre quando nada acontece, enquanto fechar a tampa desencadeia normalmente uma suspensão forçada por um caminho separado. Aquilo que caffeinate o cria é um conjunto de power assertions, e a referência do caffeinate no ss64 mostra que as suas flags cobrem a suspensão do ecrã, a suspensão por inatividade, a suspensão do disco e a suspensão do sistema. Já a documentação de gestão de energia da Apple faz a distinção importante: uma assertion de suspensão por inatividade continua a não anular um fecho normal da tampa, o menu Apple ou bateria fraca.
Portanto, as ferramentas contra a suspensão funcionam mesmo nas condições de suspensão que foram feitas para controlar. Mas fechar a tampa normalmente é outro problema, e caffeinate não é uma estratégia de servidor com a tampa fechada.
Nota:
disablesleepé o caso estranho. Não aparece de todo na referência de opções do pmset . A solução a que as pessoas recorrem é uma definição não documentada. Não é uma power assertion. Consegue manter um MacBook acordado com a tampa fechada, inclusive com bateria, até voltar a desligá-la ou a bateria acabar.
Um portátil tem a forma errada para um trabalho 24/7
Houve uma altura nos anos noventa em que as pessoas corriam servidores web de produção em torres de secretária debaixo da mesa de alguém, e toda a gente no edifício aprendia a não dar um pontapé na extensão. Não resolvemos isso com um aviso colado na extensão. Resolvemos movendo a carga de trabalho para uma máquina cujo único trabalho era ficar parada e continuar com energia.
A mesma forma de problema, trinta anos depois. Um MacBook é uma máquina concebida em torno de ser fechada e levada. Isso não é um bug na gestão de energia. É o produto. Cada solução para o manter acordado é uma discussão com uma decisão de design que alguém tomou de propósito, e essa discussão consegue ganhar-se durante um tempo, ao custo de pensar nela para sempre.
Pode ir mais longe e desativar a suspensão por completo. Parabéns: agora tem um servidor a correr permanentemente com uma bateria lá dentro, mais uma definição de sistema que tem de se lembrar de desfazer antes de o portátil ir para a mochila. A primeira arrumação à pressa não interrompe a execução. Deixa a máquina acordada, a gastar bateria e a acumular calor precisamente onde não o quer.
E nada disto é novo. Os daemons de agentes auto-alojados batem na mesma parede pela mesma razão: têm de estar de pé quando não está na secretária, o que exclui o portátil antes sequer de configurar seja o que for. Isto é verdade nesta categoria há já algum tempo. Só ainda não me tinha custado uma noite de trabalho.
O seu agente não está a pensar nessa máquina
Os próprios requisitos de sistema do Claude Code pedem 4 GB or more of RAM and an x64 or ARM64 processor. É esta a linha de hardware, na íntegra. Nenhuma linha de GPU. Nenhuma linha de VRAM. Nada sobre um modelo, porque não existe nenhum na sua máquina.
Levei um tempo embaraçoso a interiorizar isto, e é por isso que o preço deixa de soar suspeito. O processo do agente na sua máquina faz três coisas: monta o contexto e envia-o como chamadas de API, guarda o estado da conversa entre turnos e corre as ferramentas que o modelo pedir. Isso é trabalho de coordenação. (Andei sempre à procura da GPU nesta história. Não há GPU nenhuma nesta história.) A parte cara, a que quer um bastidor cheio de aceleradores, acontece no centro de dados de outra pessoa.
O agente não está a pensar nessa máquina. Está a fazer chamadas a algo que pensa.
É por isso que uma máquina capaz de fazer isto custa o que custa. No final de agosto de 2026, o Basic Droplet mais barato da DigitalOcean custa $4 por mês por 512 MiB e um vCPU, e a escada Cloud Compute da Vultr começa em $2,50 para uma instância de 512 MB apenas com IPv6 e chega a $5 com 1 GB. Dois fornecedores, a mesma forma de chão. Ambos os degraus mais baixos ficam abaixo dos 4 GB daquela linha de requisitos, e os planos da classe $5 também. Se estiver a correr especificamente o Claude Code, 4 GB é o mínimo publicado. A ponta barata só funciona quando o agente que realmente corre tem requisitos mais baixos.
Uma fronteira, porque enganar-se nisto custa dinheiro: isto vale para agentes que chamam um modelo alojado. Se o que quer é um modelo a correr localmente em hardware seu, nada disto se aplica. Uma máquina com um gigabyte de RAM não corre um modelo com que quisesse programar.
A máquina é barata porque a parte cara está a acontecer noutro sítio.
Quanto custa um Mac mini, e o que é que compra
Um Mac mini custa agora $899, e só o poderá ter a partir de 22 de setembro. A configuração M6 base (CPU de 12 núcleos, GPU de 12 núcleos, 16 GB de memória, 256 GB de armazenamento) está em pré-encomenda, com envio nesse dia; o artigo de lançamento da TechCrunch traz o número. A Apple não lista nada abaixo disso.
Esse número merece que se fique um bocado com ele. Os mesmos 16GB, os mesmos 256GB: essa configuração de memória e armazenamento saiu por $599 em outubro de 2024. Metade a mais para o Mac mini base, em menos de dois anos. Pelo meio houve um degrau de $799, quando a Apple deixou de vender a configuração de 256GB em maio de 2026 e o preço de entrada subiu com ela. É este o chão em que assenta o argumento de comprar de vez, e esse chão não para de se mexer.
O outro lado tem mais a seu favor do que eu gostaria. A máquina é sua por inteiro, com valor de revenda e sem uma linha mensal. A eletricidade quase não se nota em repouso: a Apple publica 4 W em repouso para a configuração M4, o que dá cerca de $6,40 por ano ao preço médio da eletricidade residencial nos EUA em junho de 2026. As cargas reais consomem mais, por isso não vou fingir que 4 W é o número de funcionamento. E computação alugada só é barata no fundo da escada. A mesma lista da DigitalOcean que abre nos $4 acaba nos $96 por mês para uma máquina de 16 GB, e três anos disso custam várias vezes o preço do Mac mini.
Portanto, sim. Se a pergunta é quanto custa possuir versus alugar uma dada quantidade de computação ao longo de três anos, compre o Mac mini. Essa pergunta tem resposta e não é aquela que estou a defender.
Duas coisas que um Mac mini compra e que mudam a equação. A primeira é o próprio macOS: um agente a correr ali pode ser ligado às Notas, Mensagens, Atalhos, Calendário e Lembretes através da automação do macOS e das permissões de apps. Uma máquina Linux sem ecrã não tem essas apps locais. Se o trabalho do seu agente é lidar com elas, o Mac mini é a máquina certa e não vou fingir o contrário.
A segunda é a inferência local, onde muita memória rápida ao lado de um chip rápido é realmente uma boa relação qualidade-preço e nenhum VPS barato compete. Os comentadores de um tópico do Hacker News sobre exatamente isto defendem bem esse ponto e acho que têm razão. Só que é uma pergunta diferente da minha.
Nenhuma dessas coisas resolve o problema de um portátil que se fecha. Comprar um computador de secretária para impedir que um portátil adormeça é comprar hardware para resolver um problema de topologia.
O que mudou depois de o ter mudado
Esqueci-me de que existia durante umas duas semanas. É essa a análise.
Liguei-o, mudei o agente para lá, verifiquei umas quantas vezes porque ainda não confiava, e depois deixei de verificar. As execuções terminam. A tampa deixou de ter que ver com o que quer que seja. O meu Mac agora dorme, que é o que quero que um portátil faça.
O atrito é real, portanto aqui vai. Perdi a máquina local: tudo o que o agente fazia tocando no meu próprio ambiente de trabalho, já não consegue fazer, e isso partiu dois pequenos fluxos que eu tinha montado sem pensar. Agora há um servidor, com SSH em cima, uma firewall à frente e uma distribuição que quer atualizações, o que é um pequeno imposto permanente sobre a minha atenção. Quem lhe diga que uma máquina alugada é zero manutenção está a saltar um passo. E é barata porque a inferência é remota: no dia em que quiser algo a correr localmente nela, o escalão barato deixa de ser o número.
Um agente iniciado diretamente dentro de uma shell SSH pode morrer quando essa ligação cai. Inicie-o primeiro dentro de uma sessão persistente. tmux é a resposta padrão, e manter sessões vivas numa máquina remota tem os pormenores.
Depois vem a objeção mais afiada que fazem a isto: uma máquina alugada não é uma casa pior para um agente do que hardware que possui fisicamente? Para um agente do tipo operador com acesso aos seus ficheiros pessoais, é justo. Para um agente de programação, um VPS que controla com acesso root e uma firewall que configurou é um perfil de risco diferente de um serviço de agente que expõe amplamente à internet pública. Continua a ser uma máquina virtual em hardware de outra pessoa, e tudo o que deixar acessível a partir da internet continua a fazer parte da sua superfície de ataque. E a parte que sai do seu controlo, a chamada de API que leva o seu código para um fornecedor de modelos, sai de qualquer forma. Mac ou Linux, essa fronteira de confiança é a mesma.
O que eu queria era uma máquina com que pudesse deixar de me preocupar. Arrancar, endurecer, pôr-lhe o agente em cima, esquecer. Se está a montar uma, um VPS Linux simples é tudo o que esta carga de trabalho pede, e o nosso entrega-lhe root por SSH um minuto depois de escolher uma região e uma distribuição. Mais ou menos a cerimónia que isto merece.
Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.
Ver planos LinuxO que eu diria a alguém que começa hoje
Três coisas, e acabei.
O que corro agora: uma pequena máquina Linux alugada, um ou dois gigabytes de RAM, um único vCPU, armazenamento NVMe, numa região perto de mim. É isso que a minha carga precisa; se o seu agente publica um mínimo mais alto, use esse. Nela: a CLI do agente, tmux, uma firewall, atualizações automáticas. Recebe mais ou menos tanta atenção minha como o meu router.
O conselho, tal como é: ponha o agente na máquina mais barata que cumpra os requisitos publicados antes de comprar seja o que for. Não como decisão permanente. Como teste. Numa semana saberá se a sua carga é orquestração de API, e nesse caso está feito e acabou de guardar $899, ou se precisa mesmo de hardware próprio.
A única coisa que não voltaria a fazer: passar semanas a afinar a gestão de energia. Experimentei o caffeinate, depois uma app na barra de menus, depois o disablesleep, depois um despertar agendado, e tratei cada falha como um erro de configuração que ainda não tinha encontrado. Não era. A pista estava mesmo ali: cada solução tornava a máquina um pouco pior como portátil. Perder uma noite de trabalho foi uma forma cara de dar por isso.
Perguntas frequentes
O Caffeinate mantém um Mac acordado com a tampa fechada?
Não. caffeinate usa power assertions para segurar condições de suspensão como a suspensão por inatividade e a do ecrã. A própria documentação da Apple para essa assertion diz que o sistema pode suspender-se à mesma por fecho da tampa, menu Apple ou bateria fraca. Fechar a tampa normalmente desencadeia uma suspensão forçada, que essas assertions não impedem, e é por isso que as ferramentas contra a suspensão funcionam de forma fiável até ao instante exato em que a tampa se fecha.
Quanta RAM precisa um agente de programação com IA num servidor?
Menos do que a maioria espera, porque o modelo não corre nela. Os requisitos de sistema publicados do Claude Code pedem 4 GB de RAM ou mais e um processador x64 ou ARM64, sem qualquer requisito de GPU, já que a inferência acontece no hardware do fornecedor do modelo. O mínimo é definido pelas ferramentas do próprio agente (o seu checkout, os seus passos de build, o runtime da sua linguagem), não pelo modelo.
Um Mac mini sai mais barato do que alugar um servidor durante três anos?
Depende de quanta máquina precisa. No fundo do mercado de aluguer, três anos de uma máquina pequena custam uma fração de um Mac mini, que agora começa nos $899 para a configuração M6 base, com envio a 22 de setembro. Suba na escada e o hardware próprio ganha, porque o preço de compra acaba e a fatura mensal não. De qualquer forma, isso responde a uma pergunta de custo, não à pergunta de onde deve viver a carga permanente de uma máquina portátil.
O que mantém uma sessão de agente a correr depois de me desligar do servidor?
Um multiplexador de terminal. Inicie o agente dentro de uma sessão tmux (ou screen) no servidor e destaque-se; continua a correr depois de a sua ligação SSH cair, e volta a ligar-se mais tarde a partir de qualquer sítio. Sem isso, fechar o terminal pode matar um processo agarrado diretamente a essa shell, reproduzindo num servidor exatamente o problema de que fugiu ao deixar o portátil.
Discussão
Comentários
Inicie sessão para participar na discussão.