Claude Routines o cron locale: cosa gira sul Mac e cosa in cloud nelle 21 automazioni che orchestro

14 aprile 2026, ore 17:42. Anthropic ha appena pubblicato Routines: cron task che girano sull'infrastruttura cloud invece che sul mio Mac. Il primo pensiero è stato pratico, non entusiasta. Avevo 21 automazioni in produzione, tutte legate al laptop, e ogni viaggio mi obbligava a calcolare se la batteria avrebbe retto fino al ritorno. La domanda concreta non era se migrare, era cosa migrare.

Cinque settimane dopo, l'architettura è ibrida. Sei task girano in cloud su Routines, quindici restano locali su Cowork, un signals bus li tiene in sincronia. Non è la fotografia di un sistema finito: è la fotografia di un sistema che ha smesso di rompersi ogni volta che chiudo il MacBook. Questa è la mappa che ho usato per dividerlo, con i criteri concreti e gli errori che ho fatto provando ad applicarla male.

Lo stato di fatto prima di Routines

Tutte le 21 automazioni giravano su Claude Cowork, l'agente desktop Mac che orchestra cron locali via Chrome MCP, Python e API. Il vincolo strutturale era uno: Mac acceso, sessione Cowork attiva, network stabile. Se chiudevo il laptop alle 22:30, il task system-compliance-checker schedulato per le 22:30 saltava il run. Se andavo a Roma per due giorni, il linkedin-daily-post mattutino non partiva e perdevo la finestra ottimale 8:00-9:30.

Ho lavorato per nove mesi con questo vincolo. La produttività netta era altissima, il sistema era robusto, ma il punto di fallimento era sempre lo stesso oggetto fisico: un MacBook Pro che doveva restare acceso. Il costo reale dell'automazione zero-touch non è il setup iniziale, è il vincolo di disponibilità che ti costringe a riprogettare la tua vita intorno al laptop.

Le 21 automazioni erano divise così, per categoria:

1. LinkedIn quotidiani, sette task: daily-post, daily-engagement, engagement-lunch, engagement-evening, reply-to-replies, dm-prep, to-x-crosspost.
2. LinkedIn settimanali, quattro task: weekly-planner, weekly-report, weekly-article-opus, experiment-audit.
3. SEO e blog, sei task: weekly-blog-writer, blog-draft-publisher, gsc-weekly-monitor, seo-competitor-tracker, seo-outreach-resend, seo-autoresearch.
4. Periodici, quattro task: weekly-system-orchestrator, system-compliance-checker, content-intelligence, linkedin-pattern-learner.

Nessuna di queste girava in cloud. Il signals bus era un singolo file markdown system-signals.md letto e scritto da tutti i task in sequenza, mai concorrente, perché su Cowork i task non si sovrappongono per design.

Cosa è cambiato con Routines

Routines è la prima implementazione di Anthropic di task schedulati che girano sul cloud Claude, senza bisogno di un client desktop. Le specifiche tecniche sono semplici: definisci un prompt, definisci una pianificazione cron-like, scegli il modello (Haiku, Sonnet, Opus). Il task gira, produce output, scrive eventuali file, finisce. Niente browser, niente Chrome MCP, niente accesso al filesystem locale.

Questa è la differenza strutturale che cambia tutto. Cowork ha il vantaggio del Chrome MCP e dell'accesso al disco. Routines ha il vantaggio dell'affidabilità: non dipende dal mio Mac, non dipende dalla mia connessione, non dipende da me. Il prezzo è la perdita di accesso a strumenti che richiedono un browser controllato o file locali.

Ho impiegato dieci giorni a interiorizzare la distinzione concreta. Il primo istinto è stato migrare tutto quello che potevo, perché Mac sempre acceso è un debito mentale che pesa. Il secondo istinto, più ragionato, è stato chiedermi cosa effettivamente rompo migrando un task che funziona già. La risposta breve: rompo l'accesso a Chrome e al filesystem. La risposta lunga è il framework che spiego sotto.

Quattro criteri per decidere cloud o locale

Dopo tre settimane di esperimenti, le 21 automazioni si sono divise lungo quattro assi. Non sono criteri teorici, sono i quattro punti dove ho effettivamente sbagliato la migrazione e dovuto fare rollback.

1) Affidabilità requirement

La prima domanda è semplice. Se questo task NON gira per quattro ore, qualcosa di brutto succede? Se sì, va in cloud. Se no, può stare locale.

Esempi concreti dal mio sistema. Il linkedin-daily-post deve girare tra le 8:00 e le 9:30 ogni giorno, finestra ottimale algoritmo LinkedIn Italia. Se salta, perdo la finestra e il post viene visto da meno persone. Affidabilità requirement alto. Candidato cloud.

Il seo-competitor-tracker gira ogni mercoledì alle 11:00. Se salta, lo rieseguo giovedì. Affidabilità requirement basso. Resta locale.

Questo criterio da solo decide il 40% dei task.

2) Tool access requirement

La seconda domanda è strutturale. Questo task ha bisogno di Chrome MCP, accesso al filesystem locale, o tool che vivono solo sul mio Mac? Se sì, deve restare locale, punto. Routines non offre questi accessi.

Esempi. Il linkedin-daily-post apre Chrome, naviga al feed, scrive il post. Senza Chrome MCP non esiste. Resta locale, anche se affidabilità requirement è alto.

Il gsc-weekly-monitor chiama l'API di Google Search Console via service account, parsa JSON, scrive un report markdown. Niente browser, niente filesystem se non per output. Può girare in cloud.

Questo criterio è binario e decide il 35% dei task. La cosa importante: vince sul criterio 1. Se serve Chrome, niente cloud, anche se la disponibilità è critica.

3) Latency budget

La terza domanda è operativa. Questo task ha un tempo massimo di esecuzione, o può durare 8-15 minuti? Routines ha limiti più stringenti di Cowork sull'esecuzione continua, e i task lunghi vanno frammentati o tenuti locali.

Il weekly-blog-writer genera articoli di 2000+ parole con multi-step di pianificazione, scrittura, revisione, push su Sanity. Tempo medio: 6-8 minuti. Sta dentro il budget Routines, ma il margine è stretto. Locale per ora.

Il news-intelligence scansiona feed RSS, classifica, salva digest. Tempo medio: 90 secondi. Cloud senza problemi.

4) Privacy e data residency

La quarta domanda è di compliance. Questo task tocca dati cliente, dati personali, segreti che non voglio lasciare fuori dal mio Mac? Se sì, locale per default.

Il mio caso è specifico: lavoro da freelance, P.IVA in Italia, gestisco principalmente i miei dati e quelli pubblici (post LinkedIn, articoli blog). Per ora, zero task tocca dati di clienti B2B in modo sensibile. Quando inizierò a gestire pipeline di clienti via Build Day, questo criterio diventerà bloccante per task che processano email cliente, contratti, materiale riservato.

Come ho diviso le 21 automazioni in concreto

Ecco la mappa attuale, aggiornata al 19 maggio 2026. Cinque settimane di test, due rollback, sei task ora stabili in cloud.

Locale (Cowork, Mac acceso), 15 task:

1. linkedin-daily-post: Chrome MCP, finestra oraria critica
2. linkedin-daily-engagement: Chrome MCP, sessione lunga
3. linkedin-engagement-lunch: Chrome MCP
4. linkedin-engagement-evening: Chrome MCP
5. linkedin-reply-to-replies: Chrome MCP
6. linkedin-dm-prep: Chrome MCP, accesso DM
7. linkedin-to-x-crosspost: Chrome MCP, cross-platform
8. linkedin-weekly-planner: Chrome MCP, screenshot
9. linkedin-weekly-report: Chrome MCP, analytics
10. linkedin-experiment-audit: Chrome MCP, daily-audit
11. weekly-blog-writer: latency budget, push Sanity con filesystem
12. blog-draft-publisher: push Sanity con filesystem
13. seo-outreach-resend: Resend API + filesystem drafts
14. seo-autoresearch: multi-step, latency
15. weekly-system-orchestrator: orchestra altri locali, accesso file

Cloud (Routines, sempre on), 6 task:

1. news-intelligence: RSS scan, classifica, digest. Sonnet daily 06:00
2. blog-post-auditor: query Sanity, audit V-09/V-14/V-16. Sonnet daily 06:00
3. system-health-check: ping endpoint, status report. Haiku daily 22:00
4. outreach-feedback-loop: analisi reply email Resend. Sonnet daily 09:00
5. gsc-weekly-monitor: GSC API, report markdown. Sonnet weekly
6. repo-sync-metrics: sync repo GitHub, metriche. Haiku trigger push

Il signals bus resta un singolo file markdown, ora sincronizzato bidirezionalmente tra Mac e cloud via un task signals-sync dedicato che gira tre volte al giorno (05:45, 08:30, 21:30). Il file vive in GitHub come fonte di verità, sia Cowork locale sia Routines cloud lo pullano e ci scrivono. È il pezzo di infrastruttura che ha richiesto più progettazione: senza, i due ambienti sarebbero rimasti ciechi l'uno verso l'altro.

I tre errori che mi hanno fatto fare rollback

La parte interessante non è la mappa finale, è il percorso. Ho provato a migrare otto task, e tre sono tornati locali dopo poche giorni. Eccoli, con il motivo.

Errore 1: linkedin-weekly-report in cloud per due giorni. Il pensiero era logico: il report legge analytics LinkedIn, sintetizza, scrive markdown. Niente browser apparente. Ho scoperto in produzione che il report ha bisogno di screenshot dell'interfaccia analytics, non solo dei dati API, perché LinkedIn cambia layout ogni mese e gli screenshot servono come ground truth visuale. Senza Chrome, niente screenshot, niente report. Rollback in 48 ore.

Errore 2: seo-autoresearch in cloud per tre giorni. Il task fa autoricerca SEO multi-step: query GSC, ricerca competitor su Apify, generazione hypothesis test, scrittura findings. Tempo medio: 12 minuti. Su Routines, il limite di latency ha tagliato il task a metà al secondo run. Ho diviso il task in tre sotto-task più piccoli, ma la sincronizzazione tra di loro tramite signals bus aggiungeva complessità inutile per un task che gira una volta a settimana. Rollback a Cowork locale dove la sessione lunga non è un problema.

Errore 3: blog-draft-publisher in cloud per cinque ore. Pensavo: query Sanity per draft pronti, controlla campi, pubblica. Niente browser. Ho dimenticato che il task scrive log markdown sul filesystem locale come parte del flusso compliance. Senza filesystem, niente log. Senza log, niente audit trail. Rollback prima della fine del primo run produttivo.

Il pattern dei tre errori è lo stesso: ho sottovalutato un requisito secondario (screenshot, latency long-tail, filesystem write) perché il requisito primario sembrava soddisfatto. La lezione operativa: prima di migrare un task, listare TUTTI i side-effect, non solo l'output principale.

Cosa è successo dopo cinque settimane

I numeri sono semplici. Pre-Routines: ogni viaggio fuori casa di più di 24 ore aveva un costo operativo nascosto (post saltati, audit non eseguiti, report in ritardo). Post-Routines: i sei task critici girano comunque, e il signals bus mi mostra al ritorno cosa è stato fatto.

Il calcolo concreto: 4 giorni a Roma il 24-28 aprile. Pre-Routines avrei perso 1 audit, 1 GSC monitor, 4 news-intelligence digest. Post-Routines, zero perdite su quei task. I task LinkedIn quotidiani sono saltati perché restano locali, ma quelli erano già pianificati in anticipo nel weekly-planner del sabato precedente.

Costo computazionale Routines: stima 18-22 euro al mese per i sei task, distribuiti per modello (Haiku per i light, Sonnet per i medium, mai Opus per scheduled). Costo Cowork: zero marginale, è incluso nell'abbonamento Claude Pro che pago comunque per uso quotidiano.

L'aritmetica del valore è chiara: 20 euro al mese per non dover lasciare il Mac acceso quando viaggio è un buon trade. Non è un risparmio di tempo, è un risparmio di carico mentale, che è una valuta più scarsa.

Quando NON migrare a Routines

C'è un caso dove non vale la pena, anche se i quattro criteri dicono "cloud". È quando il task è centrale al tuo workflow e fai cambi frequenti. Ogni modifica a un task Routines richiede deploy, attesa, verifica del primo run. Su Cowork modifichi il prompt, salvi, il prossimo run lo prende. Per task che evolvono settimanalmente (tutto LinkedIn engagement), la velocità di iterazione locale batte la stabilità cloud.

Un secondo caso: task con costo computazionale alto. Se il prompt è lungo (5000+ token di system prompt) e il task gira 10 volte al giorno, il costo Routines sale rapidamente. Su Cowork, lo stesso prompt usa la mia quota Claude Pro senza incremento marginale. Per task multi-volume bassi-medi, locale resta competitivo.

Terzo caso: dipendenze da altri task locali. Se il task A in cloud ha bisogno di output del task B locale, devi orchestrare la sincronizzazione via signals bus. Funziona, ma aggiunge un punto di fallimento. Per coppie task strettamente accoppiate, tenerle entrambe locali semplifica.

La checklist che uso prima di migrare un task

Quando un nuovo task entra in produzione, lo passo attraverso questa lista in 90 secondi. Se passa tutti e quattro, va in cloud. Se ne fallisce uno, locale.

1. Affidabilità. Se salta per 4 ore, qualcuno se ne accorge negativamente? Se sì → cloud (criterio attivo).
2. Tool. Serve Chrome MCP, filesystem write, accesso a tool desktop-only? Se sì → locale (criterio bloccante).
3. Latency. Tempo medio singolo run < 4 minuti, p99 < 8 minuti? Se no → locale (criterio bloccante).
4. Dati. Tocca dati cliente sensibili, segreti rotanti, materiale riservato? Se sì → locale (criterio bloccante per ora).

I criteri bloccanti vincono sempre. Il criterio attivo (affidabilità) determina se vale la pena migrare quando i bloccanti sono passati. Se nessuno è critico, lascio locale per default, perché lo zero-touch ha un valore di per sé (niente da gestire).

Il signals bus come collante

Il pezzo che spesso viene saltato nei post sulle architetture ibride è il signals bus. Senza, hai due silos: cloud che fa cose, locale che fa cose, nessuno sa cosa fa l'altro. Con, hai un sistema operativo distribuito.

Il mio bus è un file markdown unico, system-signals.md, con sezioni dedicate per ogni task (es. ## seo-performance, ## blog-audit, ## linkedin-content-patterns). Ogni task scrive nella sua sezione l'output strutturato (data, evento, payload), e legge le sezioni degli altri task per coordinare. Esempio concreto: il weekly-blog-writer legge ## blog-audit scritto dal blog-post-auditor cloud per sapere se ci sono violazioni V-09/V-14 da risolvere prima di pubblicare.

La sincronizzazione bidirezionale tra cloud e locale è gestita dal task signals-sync, che gira tre volte al giorno e usa GitHub come transport. Il file vive nel repo, Cowork locale fa pull/push, Routines cloud fa pull/push. Race condition gestite con commit atomici (un task scrive solo la sua sezione, mai due task scrivono la stessa sezione contemporaneamente perché lo scheduling lo previene). Funziona da cinque settimane, zero conflitti merge.

Il signals bus è anche il motivo per cui posso aggiungere task in cloud senza rompere nulla locale, e viceversa. È il punto di disaccoppiamento.

Cosa farei diversamente partendo da zero

Se dovessi rifare il setup oggi, sapendo quello che so, l'ordine sarebbe diverso. Partirei dal signals bus, non dai task. Il bus è l'infrastruttura abilitante. Senza bus, ogni task è un'isola, e quando arriva il momento di migrare metà su cloud ti ritrovi a fare retrofit di un'orchestrazione che doveva esserci dal giorno uno.

Secondo: partirei dal task più affidabilità-critico prima ancora di avere dieci task locali. Il primo task in cloud insegna molte cose sulla sincronizzazione, gestione errori, monitoring. Meglio impararle su un task isolato che su un sistema già complesso.

Terzo: documenterei i side-effect prima di migrare. Tutti gli errori di rollback che ho fatto venivano da side-effect non documentati. Una pagina markdown "Cosa fa esattamente questo task, incluso quello che non si vede dall'output" risparmia ore di debug.

Questo è il pattern operativo che insegno nel Build Day AI e che trovi spiegato in dettaglio per Cowork in particolare nella guida definitiva all'agente desktop. L'architettura ibrida non è un upgrade, è una decisione strutturale che cambia come progetti il sistema dal giorno uno.

Il punto è questo

Routines non sostituisce Cowork. Le due piattaforme hanno design intent diversi e coprono use case complementari. La scelta non è cloud o locale, è quale parte del tuo sistema beneficia di cosa.

Per chi sta partendo ora con automazioni Claude, il consiglio operativo è semplice: la guida operativa Claude Mastery ha un modulo dedicato proprio a questa decisione, ma il punto di partenza non cambia. Non scegliere a priori. Costruisci il primo task dove è più semplice (probabilmente Cowork, perché hai accesso al tuo Mac e a Chrome), poi quando il task numero cinque o sei entra in produzione, fermati e applica i quattro criteri. La scelta ibrida emerge naturalmente, non è da forzare in anticipo.

Per chi ha già un setup tutto-locale: non migrare tutto in una settimana. Sei migrazioni in cinque settimane è la cadenza che mi ha permesso di imparare senza rompere. Una migrazione, una settimana di osservazione, decisione keep/rollback. Ripeti.

Il sistema funziona. Tu fallo partire.