L'ultima volta che ho perso un'esecuzione notturna di un agente, non è andato in crash niente. Nessun errore. Avevo lanciato una lunga migrazione su un repo che evitavo da mesi, l'ho vista macinare la noiosa parte iniziale e poi ho chiuso il portatile perché per quella sera avevo finito. L'ho riaperto la mattina dopo in un bar. La sessione non c'era più. Non era fallita. Si era fermata, da qualche parte a metà, con un branch lasciato a metà e nessuna traccia di cosa stesse per fare dopo.
E la soluzione l'avevo già applicata. È questa la parte che mi ha steso.
Quindi si parla del perché quella soluzione non poteva funzionare, e della macchina in affitto, noiosissima, che fa il lavoro al suo posto. È quella su cui ora faccio girare gli agenti IA 24/7, e ho smesso del tutto di pensare alle impostazioni di risparmio energetico del portatile.
La soluzione che tutti consigliano
caffeinate -dimsu. Oppure un'app nella barra dei menu con l'icona di una tazza di caffè. Oppure, se hai scavato, sudo pmset -a disablesleep 1, ovvero l'opzione nucleare e quella che spunta nei consigli dal tono più sicuro di sé. Ho eseguito quella. Sembrava di aver risolto il problema.
macOS ha più di un modo per addormentarsi, e i due che contano qui sono indipendenti l'uno dall'altro: la sospensione per inattività è un timer che scorre quando non succede nulla, mentre chiudere il coperchio innesca normalmente una sospensione forzata attraverso un percorso separato. Quello che caffeinate crea è un insieme di power assertion, e il riferimento caffeinate di ss64 mostra che i suoi flag coprono la sospensione dello schermo, quella per inattività, quella del disco e quella di sistema. La documentazione sulla gestione dell'alimentazione di Apple fa la distinzione decisiva: un'assertion di sospensione per inattività continua a non prevalere su una normale chiusura del coperchio, sul menu Apple o sulla batteria scarica.
Quindi gli strumenti anti-sospensione funzionano davvero sulle condizioni di sospensione per cui sono stati costruiti. Ma una normale chiusura del coperchio è un altro problema, e caffeinate non è una strategia da server a coperchio chiuso.
Nota:
disablesleepè il caso strano. Non compare affatto nel riferimento delle opzioni di pmset . La soluzione a cui la gente ricorre è un'impostazione non documentata. Non è una power assertion. Può tenere un MacBook sveglio a coperchio chiuso, anche a batteria, finché non la disattivi di nuovo o la batteria non si esaurisce.
Un portatile ha la forma sbagliata per un lavoro 24/7
C'è stato un periodo negli anni Novanta in cui la gente faceva girare server web di produzione su tower da scrivania sotto il tavolo di qualcuno, e tutti nell'edificio imparavano a non prendere a calci la ciabatta. Non abbiamo risolto la cosa con un cartello sulla ciabatta. L'abbiamo risolta spostando il carico su una macchina il cui unico compito era stare ferma e restare alimentata.
Stessa forma di problema, trent'anni dopo. Un MacBook è una macchina progettata attorno all'idea di essere chiusa e portata via. Non è un bug nella sua gestione dell'alimentazione. È il prodotto. Ogni trucco per tenerlo sveglio è una discussione con una scelta progettuale fatta di proposito, e quella discussione puoi vincerla per un po', al prezzo di pensarci per sempre.
Puoi spingerti oltre e disattivare del tutto la sospensione. Congratulazioni: ora possiedi un server sempre acceso con una batteria dentro, più un'impostazione di sistema che devi ricordarti di annullare prima che il portatile finisca in borsa. La prima volta che chiudi tutto di fretta, l'esecuzione non si ferma. Lascia la macchina sveglia, a consumare batteria e ad accumulare calore proprio dove non lo vuoi.
Del resto, nulla di tutto questo è nuovo. I daemon di agenti self-hosted sbattono contro lo stesso muro per la stessa ragione: devono essere attivi quando non sei alla scrivania, il che esclude il portatile prima ancora che tu abbia configurato qualcosa. Per questa categoria è vero da un pezzo. Solo che a me non era ancora costato una notte di lavoro.
Il tuo agente non sta pensando su quella macchina
I requisiti di sistema di Claude Code chiedono 4 GB or more of RAM and an x64 or ARM64 processor. Questa è la riga sull'hardware, per intero. Nessuna riga sulla GPU. Nessuna riga sulla VRAM. Niente di niente su un modello, perché sulla tua macchina non ce n'è uno.
Mi ci è voluto un tempo imbarazzante per interiorizzarlo, ed è il motivo per cui il prezzo smette di sembrare sospetto. Il processo dell'agente sulla tua macchina fa tre cose: assembla il contesto e lo spedisce come chiamate API, conserva lo stato della conversazione tra un turno e l'altro, ed esegue gli strumenti che il modello richiede. È lavoro di coordinamento. (Continuavo a cercare la GPU in questa storia. In questa storia non c'è nessuna GPU.) La parte costosa, quella che vuole un rack di acceleratori, avviene nel data center di qualcun altro.
L'agente non sta pensando su quella macchina. Sta facendo chiamate a qualcosa che pensa.
Ecco perché una macchina in grado di fare questo costa quel che costa. A fine agosto 2026 il Basic Droplet più economico di DigitalOcean è 4 $ al mese per 512 MiB e una vCPU, mentre la scala Cloud Compute di Vultr parte da 2,50 $ per un'istanza da 512 MB solo IPv6 e arriva a 5 $ con 1 GB. Due fornitori, stessa forma di pavimento. Entrambi i gradini più bassi stanno sotto i 4 GB di quella riga di requisiti, e lo stesso vale per i piani della classe 5 $. Se fai girare Claude Code nello specifico, 4 GB è la soglia pubblicata. La fascia economica funziona solo quando l'agente che stai davvero eseguendo ha requisiti più bassi.
Un confine, perché sbagliare qui costa soldi: tutto questo vale per gli agenti che chiamano un modello ospitato. Se quello che vuoi è un modello che gira in locale su hardware tuo, non si applica niente di tutto ciò. Una macchina con un gigabyte di RAM non fa girare un modello con cui vorresti scrivere codice.
La macchina costa poco perché la parte costosa avviene da un'altra parte.
Quanto costa un Mac mini, e cosa ci si compra
Un Mac mini ora costa 899 $, e non potrai averne uno prima del 22 settembre. La configurazione M6 base (CPU a 12 core, GPU a 12 core, 16 GB di memoria, 256 GB di archiviazione) è in preordine, con spedizione quel giorno; l'articolo di lancio di TechCrunch riporta la cifra. Apple non elenca nulla al di sotto.
Su quel numero vale la pena soffermarsi. Stessi 16GB, stessi 256GB: quella configurazione di memoria e archiviazione è uscita a 599 $ nell'ottobre 2024. Una volta e mezza tanto per il Mac mini base, nel giro di due anni. In mezzo c'è stato uno scalino a 799 $, quando nel maggio 2026 Apple ha smesso di vendere la configurazione da 256GB e il prezzo di partenza si è alzato di conseguenza. È questo il terreno su cui poggia l'argomento del comprarlo e basta, e quel terreno continua a spostarsi.
L'altra parte ha più frecce al proprio arco di quante ne vorrei. La macchina è tutta tua, con valore di rivendita e nessuna voce mensile. L'elettricità è quasi impercettibile a riposo: Apple pubblica 4 W a riposo per la configurazione M4, il che equivale a circa 6,40 $ l'anno al prezzo medio dell'elettricità residenziale negli Stati Uniti di giugno 2026. I carichi reali consumano di più, quindi non pretenderò che 4 W sia il numero operativo. E il calcolo in affitto costa poco solo in fondo alla scala. Lo stesso listino DigitalOcean che parte da 4 $ arriva fino a 96 $ al mese per una macchina da 16 GB, e tre anni di quello costano diverse volte il prezzo del Mac mini.
Quindi sì. Se la domanda è quanto costi possedere invece che affittare una data quantità di calcolo su tre anni, compra il Mac mini. Quella domanda ha una risposta e non è quella che sto sostenendo.
Due cose che un Mac mini ti compra e che cambiano l'equazione. La prima è macOS stesso: un agente che gira lì può essere collegato a Note, Messaggi, Comandi rapidi, Calendario e Promemoria tramite l'automazione di macOS e i permessi delle app. Una macchina Linux headless non ha quelle app locali. Se il lavoro del tuo agente è operare con esse, il Mac mini è la macchina giusta e non pretenderò il contrario.
La seconda è l'inferenza locale, dove tanta memoria veloce accanto a un chip veloce è davvero un ottimo rapporto qualità-prezzo e nessun VPS economico regge il confronto. Chi commenta in un thread di Hacker News proprio su questo sostiene bene quella tesi e credo abbia ragione. Solo che è una domanda diversa dalla mia.
Nessuna delle due cose risolve il problema di un portatile che si chiude. Comprare un desktop per impedire a un portatile di addormentarsi significa comprare hardware per risolvere un problema di topologia.
Cosa è cambiato dopo lo spostamento
Per un paio di settimane mi sono dimenticato che esistesse. Questa è la recensione.
L'ho avviato, ci ho spostato l'agente, ho controllato qualche volta perché ancora non mi fidavo, poi ho smesso di controllare. Le esecuzioni arrivano in fondo. Il coperchio non c'entra più con niente. Il mio Mac adesso dorme, che è quello che voglio faccia un portatile.
L'attrito è reale, quindi eccolo. Ho perso la macchina locale: tutto quello che l'agente faceva toccando la mia scrivania non lo può più fare, e questo ha rotto due piccoli flussi di lavoro che avevo costruito senza pensarci. Ora c'è un server, con SSH sopra, un firewall davanti e una distribuzione che vuole aggiornamenti, il che è una piccola tassa permanente sulla mia attenzione. Chiunque ti dica che una macchina in affitto è a manutenzione zero sta saltando un passaggio. Ed è economica perché l'inferenza è remota: il giorno in cui vorrò qualcosa che gira in locale su di essa, la fascia economica smetterà di essere quella cifra.
Un agente avviato direttamente dentro una shell SSH può morire quando quella connessione cade. Avvialo prima dentro una sessione persistente. tmux è la risposta standard, e tenere vive le sessioni su una macchina remota ne riporta i dettagli.
Poi arriva l'obiezione più affilata che si fa a tutto questo: una macchina in affitto non è una casa peggiore per un agente rispetto a hardware che possiedi fisicamente? Per un agente in stile operatore con accesso ai tuoi file personali, è giusto. Per un agente di codice, un VPS che controlli con accesso root e un firewall che hai configurato tu è un profilo di rischio diverso da un servizio di agente che esponi ampiamente all'internet pubblico. Resta comunque una macchina virtuale sull'hardware di qualcun altro, e tutto ciò che lasci raggiungibile da internet fa ancora parte della tua superficie d'attacco. E la parte che esce dal tuo controllo, la chiamata API che porta il tuo codice a un fornitore di modelli, esce comunque. Mac o Linux, quel confine di fiducia è lo stesso.
Quello che volevo era una macchina di cui potessi smettere di preoccuparmi. Avviarla, irrobustirla, metterci sopra l'agente, dimenticarla. Se ne stai mettendo su una, un semplice VPS Linux è tutto ciò che questo carico richiede, e il nostro ti consegna root via SSH un minuto dopo che hai scelto una regione e una distribuzione. Più o meno la cerimonia che questa cosa merita.
Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.
Vedi piani LinuxCosa direi a chi comincia oggi
Tre cose, poi ho finito.
Cosa faccio girare adesso: una piccola macchina Linux in affitto, un giga o due di RAM, una singola vCPU, storage NVMe, in una regione vicina a me. È quello che serve al mio carico; se il tuo agente pubblica una soglia più alta, usa quella. Sopra: la CLI dell'agente, tmux, un firewall, aggiornamenti automatici. Riceve all'incirca la stessa attenzione che riservo al mio router.
Il consiglio, per quel che vale: metti l'agente sulla macchina più economica che soddisfi i requisiti pubblicati, prima di comprare qualsiasi cosa. Non come decisione definitiva. Come test. Nel giro di una settimana saprai se il tuo carico è orchestrazione di API, e allora hai finito e ti sei appena tenuto 899 $, oppure se ha davvero bisogno di hardware proprio.
L'unica cosa che non rifarei: passare settimane a mettere a punto la gestione dell'alimentazione. Ho provato caffeinate, poi un'app nella barra dei menu, poi disablesleep, poi un risveglio programmato, e ho trattato ogni fallimento come un bug di configurazione che non avevo ancora trovato. Non lo era. L'indizio era lì davanti: ogni soluzione rendeva la macchina un po' peggiore come portatile. Perdere una notte di lavoro è stato un modo costoso per accorgermene.
Domande frequenti
Caffeinate tiene sveglio un Mac a coperchio chiuso?
N. caffeinate usa power assertion per trattenere condizioni di sospensione come quella per inattività e quella dello schermo. La documentazione di Apple su quella assertion dice che il sistema può comunque sospendersi per chiusura del coperchio, menu Apple o batteria scarica. Una normale chiusura del coperchio innesca una sospensione forzata, che quelle assertion non impediscono, ed è per questo che gli strumenti anti-sospensione funzionano in modo affidabile fino esattamente al momento in cui il coperchio si chiude.
Quanta RAM serve a un agente di coding IA su un server?
Meno di quanto la maggior parte delle persone si aspetti, perché il modello non gira lì. I requisiti di sistema pubblicati di Claude Code chiedono 4 GB di RAM o più e un processore x64 o ARM64, senza alcun requisito di GPU, dato che l'inferenza avviene sull'hardware del fornitore del modello. La soglia è fissata dagli strumenti dell'agente stesso (il tuo checkout, i tuoi passaggi di build, il runtime del tuo linguaggio), non dal modello.
Un Mac mini costa meno che affittare un server per tre anni?
Dipende da quanta macchina ti serve. In fondo al mercato dell'affitto, tre anni di una piccola macchina costano una frazione di un Mac mini, che ora parte da 899 $ per la configurazione M6 base, in spedizione dal 22 settembre. Sali la scala e l'hardware di proprietà vince, perché il prezzo d'acquisto finisce e la bolletta mensile no. In ogni caso questo risponde a una domanda di costo, non alla domanda su dove debba vivere il carico sempre attivo di una macchina portatile.
Cosa tiene in esecuzione una sessione dell'agente dopo che mi disconnetto dal server?
Un multiplexer di terminale. Avvia l'agente dentro una sessione tmux (o screen) sul server e poi staccati; continua a girare dopo che la tua connessione SSH cade, e ti riattacchi più tardi da ovunque. Senza, chiudere il terminale può uccidere un processo agganciato direttamente a quella shell, riproducendo su un server esattamente il problema da cui sei scappato lasciando il portatile.
Discussione
Commenti
Accedi per partecipare alla discussione.