Chi cerca "opencode" finisce su due percorsi diversi che portano allo stesso repository GitHub. Alcuni cercano un agente non legato a un solo vendor di modelli, da puntare su Anthropic, OpenAI, Gemini, un modello locale, o su qualunque cosa la policy di procurement del cliente permetta quella settimana. Altri cercano un agente che non debba mai far uscire il codice dall'infrastruttura che controllano. OpenCode risponde a entrambi, e la SERP sul termine è dominata dal sito del progetto, dal suo repository GitHub e da tutorial su come installarlo e configurarlo. Quasi nessuno si chiede cosa un team rinuncia ad avere, in termini di record da mostrare a qualcun altro, scegliendo l'opzione che nessuno gestisce al posto suo.
Cos'è OpenCode, e perché i team lo scelgono al posto di un agente chiuso
OpenCode è un agente di coding open source costruito per il terminale, con un'app desktop per macOS, Windows e Linux, e integrazioni IDE sopra. È sotto licenza MIT, mantenuto da Anomaly su github.com/sst/opencode, e ha superato i 200.000 stelle su GitHub, il che lo mette davanti alla maggior parte dei concorrenti chiusi sull'adozione grezza. Si connette a più di 75 provider di modelli tramite Models.dev in un unico file di configurazione, quindi un team non resta legato al modello di un solo vendor come succede con i default propri di Claude Code o Cursor. Per progettazione, non conserva il codice né i dati di contesto: una ragione reale per un team che non può far uscire il codice sorgente dal proprio ambiente, per scegliere OpenCode al posto di un prodotto ospitato.
Quella combinazione, agnostico rispetto al modello, licenza MIT, niente conservato dallo strumento stesso, è proprio il motivo per cui OpenCode entra nelle conversazioni di procurement delle software house che lavorano sotto contratti cliente rigidi. Non è una versione più piccola o più economica di un agente chiuso. È un accordo diverso: si ottiene il codice e la libertà di farlo girare ovunque, e si ottiene tutto ciò che viene incluso nel possedere la cosa che si fa girare.
L'open source cambia chi possiede l'infrastruttura, non solo la licenza
La licenza MIT significa che il codice è ispezionabile e modificabile, ed è un valore vero, a sé stante. È una domanda separata chi lo fa girare giorno per giorno. Un agente di coding chiuso arriva come prodotto ospitato: il vendor gestisce il backend, conserva i dati di sessione nel proprio formato, e risponde di uptime, retention e, nella misura in cui i suoi termini lo permettono, di cosa succede a quei dati. Ospitare OpenCode in proprio significa che è il team a gestire quel livello, sulla propria infrastruttura, con le proprie scelte su cosa viene conservato e per quanto tempo.
Non è uno svantaggio dell'open source. È lo scambio che un team fa esplicitamente, e vale la pena nominarlo con precisione perché gran parte della copertura tratta "open source" e "niente lock-in di vendor" come una vittoria senza condizioni, senza seguire fino in fondo cosa "niente vendor" toglie anche.
Cosa dà per default un agente di coding chiuso
Un agente ospitato, Claude Code, Cursor, Copilot, dà a un'organizzazione alcune cose senza che nessuno nel team debba costruirle: un backend persistente che registra le sessioni da qualche parte controllata dal vendor, una console amministrativa che mostra l'utilizzo su tutti i seat, un supporto da chiamare quando qualcosa si rompe, e un'unica azienda che risponde se il prodotto si comporta male. Niente di tutto questo è di per sé prova di consegna, e lo stesso limite esiste anche dentro quegli strumenti: il log di sessione di un vendor resta comunque un log in un formato che solo il prodotto di quel vendor può leggere, non un record firmato che un cliente può verificare in modo indipendente. Ma è un livello di default, persistente, problema di qualcun altro, che esiste dal giorno in cui un team accende il prodotto.
Cosa lascia OpenCode da costruire al team
Togliere quel default e non compare nulla al suo posto in automatico. Siccome OpenCode non conserva codice né dati di contesto e gira ovunque il team lo installi, una sessione sul laptop di uno sviluppatore e una sessione in CI su una build machine non vengono correlate da nessuna parte a meno che il team non costruisca quella correlazione da solo. Non c'è una console amministrativa che mostra, su tutta l'organizzazione tecnica, quale repository ha toccato una data sessione, chi l'ha lanciata, o su quali istruzioni. Non c'è un supporto vendor da chiamare quando un cliente chiede una prova sei mesi dopo la consegna. Non c'è una policy di retention integrata, un controllo degli accessi sui log che il team stesso produce, né protezione dalle manomissioni, perché non c'è un livello di log di default a cui applicare nessuna di queste cose fin dall'inizio.
È lo stesso limite tra istruzione e record già visto per gli hook dentro Claude Code, raddoppiato. Un log da hook in un prodotto chiuso è almeno un punto di partenza appoggiato su un'infrastruttura che qualcuno sta già gestendo. Con un agente self-hosted che per default non conserva nulla, un team non eredita un log incompleto da rafforzare. Non eredita niente, e deve costruire l'intero livello di prova, dalla chiamata al modello fino al rilascio firmato, da zero, sopra uno strumento pensato esplicitamente per non conservare quei dati al posto suo.
Una checklist prima di far girare OpenCode su lavoro cliente
- Dove girano davvero le sessioni. Laptop, un server condiviso, runner CI effimeri, un mix. Ognuno ha bisogno di un proprio piano per catturare cosa è successo, perché OpenCode non lo fa centralmente al posto vostro.
- Chi possiede il log, una volta che esiste. Se il team costruisce un log di sessione sopra OpenCode, qualcuno deve possederne retention, controllo degli accessi e integrità, le stesse responsabilità che altrimenti porterebbe un vendor.
- Quale provider è autorizzato per quale cliente. Agnostico rispetto al modello è un vantaggio finché il contratto di un cliente non limita quale modello può toccare il suo codice; va imposto dalla configurazione del team, non dato per scontato dai default di OpenCode.
- Cosa succede quando un cliente chiede una prova. Non "cosa ha fatto l'agente" in generale, ma una risposta specifica e verificabile per una modifica specifica, collegata a chi l'ha autorizzata e chi l'ha revisionata, sei mesi dopo la chiusura della sessione.
- Chi firma prima che qualcosa venga rilasciato. Il livello che trasforma un record in prova sta sopra l'agente, open source o chiuso: qualcuno deve firmare, e quel passaggio non arriva installato con nessun agente di coding, OpenCode compreso.
Niente di tutto questo è un motivo per evitare OpenCode. È un motivo per essere onesti su cosa "open source" compra a un team e cosa no. La licenza toglie una dipendenza da un solo vendor di modelli e da una sola infrastruttura di vendor. Non toglie la domanda su cosa una software house possa mostrare a un cliente quando la sessione è finita da tempo, e per uno strumento che per default non conserva nulla, quella domanda non ha nemmeno una risposta di default.