Un agente hosted gira nel cloud di un provider. Gli fornisci una copia dei tuoi repository e una serie di credenziali, e lavora da lì. Un agente local-first gira sulla tua macchina, con runtime, abbonamento, file e chiavi già presenti al suo interno, e solo la conversazione esce all'esterno.
Entrambi sono approcci legittimi. Collocano il tuo codice, la tua identità e la tua fattura in posti diversi, e le differenze contano ancora di più quando inizi a condividere l'agente con altre persone.
I punti di forza dell'approccio hosted e i suoi costi
Gli esempi concreti nel 2026 sono Claude Code on the web e OpenAI’s Codex cloud tasks. Entrambi eseguono l'agente nella sandbox del provider a fronte di un clone del tuo repository e si autenticano su git con token rilasciati al provider tramite l'integrazione OAuth di GitHub, in modo che l'agente non abbia mai accesso alle tue credenziali locali, alle chiavi SSH o alle variabili d'ambiente. Questa è una vera proprietà di sicurezza: un laptop compromesso di uno sviluppatore non può contaminare l'ambiente dell'agente, e un task con un perimetro mal definito non può toccare file esterni alla sandbox.
Un agente hosted è sempre attivo. Non c'è alcun laptop da tenere sveglio e nulla da installare. Per flotte non presidiate, attive 24 ore su 24, questo è determinante.
I costi sono strutturali anziché risolvibili.
- Una seconda copia di tutto. Il provider detiene i tuoi repository, e spesso il tuo ambiente, affinché l'agente possa lavorare. Quella copia ha i propri controlli di accesso, policy di retention e superficie di violazione.
- Un secondo set di credenziali. I token per GitHub, gli account cloud e le API interne vengono rilasciati al provider. Eseguire la rotazione significa ruotarli anche lì.
- Una seconda fattura. Paghi per il runtime hosted in aggiunta a, o al posto di, l'abbonamento che hai già.
- La scelta dei modelli altrui. L'host decide quali modelli sono disponibili e quando cambiano.
I punti di forza del local-first e i suoi costi
Un agente local-first usa ciò che è già sulla tua macchina: l'abbonamento a Claude Code o Codex per cui paghi, i repository che hai già clonato localmente, le chiavi già presenti nel tuo portachiavi. Nulla viene copiato da nessuna parte. Quando condividi l'agente, l'altra persona può fare richieste; la tua macchina continua a svolgere il lavoro.
Il costo è la disponibilità. Se la macchina è in sospensione, l'agente dorme.
Le mitigazioni sono pratiche anziché architetturali: registrare il daemon come servizio in modo che si avvii al login e si riavvii dopo un crash, tenere la macchina sveglia durante l'orario di lavoro e accodare le richieste in una inbox affinché nulla vada perso mentre è offline. Le richieste vengono eseguite in ordine al suo ritorno.
Due posizioni in cui collocare il confine di fiducia: attorno alla sandbox del provider, oppure attorno alla tua macchina con una stanza all'esterno.
Quanto può essere sottile il livello cloud
muti è local-first, e la questione di progettazione interessante è stata cosa sia consentito custodire al cloud. La risposta è: la stanza, e nulla che possa permettere alla stanza di impersonare la macchina.
Tre meccanismi rendono possibile questo approccio.
Solo in uscita. Il daemon sulla tua macchina effettua il polling delle attività tramite una connessione in uscita. Non ci sono porte aperte, né tunnel né percorsi in ingresso. Se il cloud di muti venisse compromesso, l'attaccante potrebbe accodare richieste che le tue regole sui permessi e le approvazioni continuerebbero a regolare; non potrebbe raggiungere i tuoi file.
Eventi, non file. Il daemon emette eventi della timeline che descrivono ciò che è accaduto. Non carica il working tree e non legge mai le variabili d'ambiente o i file di chiavi per inviarli altrove.
Approvazioni nel mezzo. Poiché la macchina è tua, le quattro tipologie di azioni pericolose si mettono in pausa per te su ogni richiesta proveniente da qualcun altro. Un agente hosted con le tue credenziali non ha nessuno a cui chiedere.
Una tabella decisionale
Perché muti non ospita runtime
Sarebbe facile aggiungere un pulsante "esegui nel nostro cloud". Non l'abbiamo fatto, ed è una scelta deliberata. Nel momento in cui il runtime si sposta, le credenziali e i repository lo seguono, e il proprietario smette di essere colui che approva. Ogni garanzia descritta nelle quattro azioni che richiedono sempre conferma dipende dal fatto che la macchina appartenga al proprietario.
muti ospita stanze. Il tuo agente rimane dove si trova.
Domande frequenti
"Local-first" equivale a "offline"? No. L'agente ha bisogno della rete per raggiungere il proprio model provider, e muti ne ha bisogno per recapitare i messaggi. Local-first descrive dove risiedono il lavoro e i segreti, non se la macchina sia connessa o meno.
Posso eseguire il cloud di muti in autonomia? Il self-hosting del livello delle stanze è nella roadmap come modalità per utente singolo con supporto offline. Il daemon e il cloud comunicano già tramite una normale API.
Cosa succede se ho più macchine? Connetti ciascuna di esse. Gli agenti sono legati a una macchina e a una working directory, e puoi distinguere le tue macchine dagli indirizzi segnalati dal daemon.
Se paghi già per un buon agente e vuoi mantenerlo dov'è, dagli una stanza.
Pubblicato il · Aggiornato il