Programma
Nozioni di base sull'intelligenza artificiale nel mondo degli affari
12 h
OpenCode è pensato per svolgere un compito. È un agente open source che collega un modello di IA al tuo repository, al terminale e agli strumenti di sviluppo. Chiedigli di correggere un bug: può trovare i file rilevanti, elaborare un piano, modificare il codice, eseguire i test e rispondere agli errori. L’autocomplete da solo non può farlo.
Questo ruolo più ampio ha attirato attenzione. Al momento della stesura, il repository attivo di OpenCode contava circa 189.000 stelle su GitHub. Non prenderei le stelle come prova della qualità del codice, ma mostrano l’interesse che il progetto ha suscitato.
La realtà è meno ordinata. OpenCode ti offre una scelta di modelli, poi ti chiede di gestirla. Un cambio di policy di un provider nel gennaio 2026 ha mostrato quanto rapidamente queste opzioni possano cambiare. Ne parlerò insieme a come funziona OpenCode e dove si colloca.
Una rapida nota sui nomi prima di proseguire: se cerchi OpenCode, potresti trovare l’archiviato repository in Go opencode-ai/opencode. Quel progetto ha smesso di essere mantenuto a settembre 2025. Ci concentreremo sul progetto attivo su github.com/anomalyco/opencode, sviluppato dal team dietro al framework Serverless Stack (SST).
Che cos’è OpenCode?
OpenCode è un agente di coding con IA open source rilasciato sotto licenza MIT. È model-agnostic, cioè non limitato a un solo provider di modelli. Gli utenti possono leggere il codice sorgente e modificarlo. Possono anche auto-ospitare lo strumento. Il software è gratuito. La fatturazione del modello è separata, come spiegherò nella sezione sulle funzionalità.
OpenCode non è un modello linguistico di grandi dimensioni (LLM). Il modello scelto legge i prompt e produce le risposte. OpenCode fornisce gli strumenti per i file, l’accesso alla shell, la cronologia di sessione, le regole di permesso e l’interfaccia attorno a quel modello. Trovo utile questa distinzione perché cambiare modello non richiede di cambiare il resto dello strumento.
È sviluppato da Anomaly, in precedenza SST, e gira principalmente su TypeScript e Bun.
Confronto tra repository archiviati e attuali di OpenCode. Immagine dell’autore.
OpenCode non è vincolato a una sola famiglia di modelli. Tramite il registro Models.dev, si connette a più di 75 provider, tra cui Anthropic, OpenAI, Google, DeepSeek, Groq e modelli locali tramite Ollama. Alcuni account in abbonamento esistenti possono essere collegati, come spiegherò nella sezione delle funzionalità.
Sessione terminale di OpenCode con modifiche ai file. Immagine dell’autore.
Sebbene OpenCode sia nato nel terminale, oggi include un’interfaccia testuale (TUI), un’app desktop beta per macOS, Windows e Linux, ed estensioni per editor come VS Code. L’ultima release stabile al momento della scrittura è la v1.18.8.
Perché è stato creato OpenCode
Come accennato, OpenCode supporta modelli di molti provider. È stato costruito così perché qualità e prezzi dei modelli cambiano, e uno strumento legato a un solo provider offre meno opzioni agli utenti.
La documentazione afferma che OpenCode non è accoppiato a nessun provider. Il registro Models.dev citato sopra fornisce i dettagli e i prezzi dei modelli che OpenCode utilizza.
Questa scelta influisce oltre la fatturazione. Modelli diversi hanno limiti di contesto, formati delle chiamate agli strumenti e tipi di input differenti. OpenCode usa un’unica interfaccia per gestire queste differenze. Uno sviluppatore può cambiare il modello selezionato nello stesso progetto senza spostare la sessione su un altro strumento.
Il team preferisce anche strumenti terminal-first che gli utenti possano ispezionare. Le istruzioni del progetto vivono in un semplice file chiamato AGENTS.md. Spiegherò più avanti come OpenCode crea e usa questo file.
Il progetto ufficiale annota tre scelte di design. La prima è il supporto ai provider, già trattato. La seconda mantiene i controlli principali nel terminale. La terza separa client e server. Questa divisione è la prossima.
A gennaio 2026, Anthropic ha bloccato l’uso di abbonamenti consumer di Claude tramite canali non ufficiali da parte di strumenti di terze parti. OpenCode ha quindi aggiunto altre opzioni di abbonamento e ha utilizzato un proprio gateway. Gli utenti potevano comunque connettersi tramite altri provider.
Questo episodio spiega perché la scelta del provider riceve così tanta attenzione in OpenCode. Per vedere cosa ci fanno gli utenti, il passo successivo è osservare una sessione.
Come funziona OpenCode
OpenCode gira come client e server locale. La TUI, l’app desktop, le estensioni IDE e l’SDK comunicano tutte con quel server via HTTP. Lo stesso server supporta l’aggancio remoto con opencode attach <url> e l’uso headless con opencode serve.
Dentro una sessione, l’agente legge i file rilevanti, può redigere un piano, modifica il codice ed esegue comandi quando necessario. La sua integrazione con il Language Server Protocol (LSP) rimanda poi al modello le diagnostiche di compilatore e linter per rispondere agli errori di tipo e sintassi.
Per esempio, un’attività può iniziare con glob o grep per individuare i file. L’agente può usare read per ispezionarli e edit per cambiare righe selezionate. Può poi usare bash per lanciare un test o un comando di build. L’output diventa parte della richiesta successiva al modello.
Trovo più semplice capire la divisione Build e Plan come un interruttore di permessi. Build è il predefinito e può leggere, scrivere ed eseguire comandi. Plan chiede conferma prima di modificare i file o eseguire comandi bash. Premendo Tab si passa dall’uno all’altro.
I controlli dei permessi si applicano quando viene invocato uno strumento. Un progetto può consentire uno strumento, bloccarlo o chiedere all’utente ogni volta. Le regole possono anche variare per pattern di comando. Un team potrebbe consentire i test di routine ma chiedere conferma per altri comandi di shell.
Le sessioni sono archiviate in locale su disco nella directory dati di OpenCode. OpenCode compatta automaticamente le conversazioni lunghe. I comandi /undo e /redo si muovono tra snapshot dei file basati su Git.
Funzionalità chiave di OpenCode
OpenCode raggruppa le funzioni principali in accesso ai modelli, contesto del progetto, esecuzione dei task e uso locale. Le sezioni seguenti spiegano cosa cambia in ciascun gruppo durante una sessione di coding.
Supporto multi-modello
Come detto, OpenCode ottiene l’elenco dei provider tramite Models.dev. In pratica, gli utenti possono collegare un servizio hosted, una piattaforma cloud o un endpoint compatibile con OpenAI. GitHub Copilot e gli accessi ChatGPT Plus/Pro offrono alternative alla gestione di una chiave API separata.
La scelta del provider non significa che ogni modello si comporti allo stesso modo. Uso degli strumenti, limiti di contesto, tempi di risposta e prezzo dipendono comunque dal modello e dal provider selezionati. Le chiamate a modelli hosted inviano anche il contesto di codice richiesto a quel provider secondo le sue regole sui dati.
OpenCode offre anche due modi opzionali per accedere ai modelli. OpenCode Zen è un gateway pay-as-you-go con un elenco di modelli selezionati. OpenCode Go è un abbonamento che costa 5$ per il primo mese, poi 10$ al mese, per modelli open-weight selezionati. Gli utenti possono comunque fornire le proprie chiavi API. I prezzi possono cambiare.
Questa è la parte fastidiosa: uno strumento gratuito può comunque generare una fattura del provider.
Lavorare con il contesto del repository
Esegui /init e OpenCode genera un AGENTS.md con il riepilogo della struttura e delle convenzioni del progetto. I team possono effettuare il commit di quel file così le sessioni iniziano con istruzioni condivise.
Il file può includere comandi di test, nomi di cartelle, regole di naming e note sul progetto. Un AGENTS.md globale può contenere istruzioni comuni a più progetti. Il file del progetto contiene le regole per un repository.
I controlli LSP descritti sopra girano dopo le modifiche. Il contesto del repository include anche riferimenti ai file: il simbolo @ inserisce un file selezionato in un prompt.
Esecuzione di task di coding
Oltre agli agenti Build e Plan descritti, OpenCode include sub-agent per ricerche multistep, scansione del codebase e documentazione esterna. Gli agenti personalizzati possono avere il proprio modello, prompt e permessi sugli strumenti.
Ogni sub-agent lavora in una sessione figlia, così i suoi messaggi non riempiono la sessione principale allo stesso modo. Un agente personalizzato può essere limitato alla sola lettura dei file, assegnato a un modello meno costoso o istruito per un solo tipo di task.
Model Context Protocol (MCP) aggiunge servizi esterni. Sono definiti in opencode.json, e i controlli di permesso già citati si applicano anche agli strumenti che aggiungono.
Passare dalla pianificazione alle modifiche del codice. Video dell’autore.
Sviluppo local-first (e i suoi limiti)
Il termine "local-first" richiede una precisazione. Non lo leggerei come la promessa che nulla lasci mai la macchina. Come notato nella sezione sui provider, OpenCode può collegarsi a Ollama. Questa configurazione mantiene codice e prompt su infrastruttura locale. I modelli hosted, /share e OpenCode Zen inviano dati al di fuori della macchina locale.
L’uso locale dipende comunque dal modello. I modelli piccoli possono restituire chiamate agli strumenti non valide o mancare collegamenti tra file. Un server locale ha anche bisogno di memoria sufficiente per il modello selezionato e di abbastanza spazio di contesto per i file inviati con ogni richiesta.
Il suo sistema di permessi è una salvaguardia del flusso di lavoro, non un sandbox di sicurezza. La modalità server in rete dovrebbe usare OPENCODE_SERVER_PASSWORD e fare bind a localhost. Un precedente problema di esposizione senza autenticazione è stato corretto, ma la modalità server non dovrebbe comunque essere esposta pubblicamente senza autenticazione.
Architettura di OpenCode
Come detto, OpenCode separa i client dal suo server locale. Questa divisione influisce su configurazione e stato archiviato. L’API aggiunge un altro modo per usare il server.
Se prevedi di usare solo la TUI, puoi saltare i dettagli sull’API. Il paragrafo sulla configurazione alla fine è la parte che userai.
Il server in TypeScript e Bun parla con i provider di modelli ed esegue gli strumenti. Gestisce anche lo stato. La sua specifica OpenAPI 3.1 genera l’@opencode-ai/sdk ufficiale. Script e client personalizzati possono usare questa API documentata.
L’API include sessioni, messaggi, file, provider, strumenti, agenti e configurazione. È lo stesso server usato dai client di OpenCode. Uno script può creare una sessione o inviare un messaggio senza cercare di controllare la TUI.
Client OpenCode collegati a un server. Immagine dell’autore.
Le interfacce elencate agiscono da client: la TUI, l’app desktop, l’estensione IDE e opencode web. Ognuna parla allo stesso processo server. Un dispositivo separato può agganciarsi a una sessione esistente tramite quel processo.
Eseguire opencode serve avvia il server senza la TUI normale. Eseguire opencode web aggiunge un client browser. Entrambi i comandi richiedono autenticazione se il server è raggiungibile da un altro dispositivo.
La configurazione risiede a livello di progetto in opencode.json o opencode.jsonc, con fallback globale in ~/.config/opencode/opencode.json. Controlla modelli, permessi, server MCP e agenti personalizzati. Come spiegato nella sezione sul flusso di lavoro, cronologia delle sessioni e log degli strumenti rimangono in file locali a meno che l’utente non li condivida.
Workflow comuni in OpenCode
Le stesse parti di OpenCode possono essere usate per diversi compiti software comuni. Gli esempi qui sotto mostrano dove serve ancora la revisione umana in ciascuno.
Costruire nuove funzionalità
Usando il processo Plan-to-Build descritto, uno sviluppatore può richiedere una funzionalità e rivedere i passaggi proposti prima di qualsiasi modifica. Premere Tab sposta poi l’attività in modalità Build per modifiche al codice e test.
Il piano può essere rivisto prima di qualsiasi modifica ai file. Userei quella revisione per correggere lo scope, nominare i file che non devono cambiare o aggiungere requisiti di test.
Refactoring del codice esistente
Lo stesso processo Plan-to-Build funziona per il refactoring. La modalità Plan può identificare dipendenze e call site prima che la modalità Build applichi le modifiche. Se il risultato è sbagliato, /undo ripristina lo snapshot precedente. L’utente deve comunque rivedere il diff perché test superati non confermano che ogni interfaccia pubblica sia rimasta identica.
Debug delle applicazioni
Per il debugging, OpenCode può combinare uno stack trace con le informazioni di tipo del language server. Può proporre una modifica, ripetere i passaggi che hanno causato l’errore e verificare il risultato. Senza passaggi di riproduzione chiari, può solo confermare che il codice compila o che i test esistenti passano.
Scrivere test
Come detto, la modalità Build può modificare i file ed eseguire comandi. Per la scrittura dei test, significa che può creare un test, leggerne il risultato e apportare un’altra modifica. Una suite di test completa gli fornisce più feedback ma richiede più tempo.
La qualità dei test richiede comunque revisione umana. Un test generato può ripetere l’implementazione invece di verificare il comportamento su cui gli utenti fanno affidamento.
Comprendere grandi codebase
La sezione sul repository ha spiegato come /init crea le note di progetto. Dopo quel passaggio, una domanda come "Come funziona l’autenticazione qui?" può guidare la ricerca. Il sub-agent @general può cercare in diverse parti del repository.
Domande specifiche di solito producono risultati più chiari rispetto a richieste di spiegare l’intero repository. I riferimenti ai file con @ possono restringere ulteriormente la ricerca.
OpenCode vs. altri agenti di coding con IA
Questi strumenti differiscono per licenza, supporto ai modelli, interfaccia e fatturazione. Li confronto su questi punti invece di trattarne uno come scelta predefinita.
OpenCode vs. Claude Code
Abbiamo un articolo separato su OpenCode contro Claude Code con maggiori dettagli. Claude Code è proprietario e usa il modello e il sistema di account di Anthropic. OpenCode usa la licenza MIT e chiede all’utente di selezionare un provider. Offre anche accesso al suo sorgente e alla configurazione. Come menzionato nella sezione storica, gli abbonamenti consumer di Claude non funzionano più tramite OpenCode, quindi per usare Claude serve una chiave API a consumo di Anthropic.
Entrambi gli strumenti possono leggere file, apportare modifiche, eseguire comandi e usare server MCP. L’accesso ai modelli è la differenza principale: Claude Code resta nell’assetto Anthropic descritto, mentre OpenCode può connettere altri provider o un endpoint locale.
OpenCode vs. Cursor
Cursor è un IDE basato su VS Code che offre anche agenti CLI e cloud. Il suo flusso principale mantiene suggerimenti, modifiche ai file e azioni dell’agente dentro l’editor. OpenCode usa le interfacce terminale, desktop e editor elencate. Cursor usa piani in abbonamento a pagamento. Il software di OpenCode è gratuito, ma gli utenti possono pagare i token al provider del modello. Le differenze principali sono interfaccia di lavoro, scelta del modello e metodo di fatturazione.
Cursor include anche il completamento inline mentre digiti. OpenCode si concentra su task affidati a un agente e non sostituisce quel tipo di completamento. Alcuni sviluppatori possono usare entrambi gli strumenti per lavori diversi.
OpenCode vs. Cline
Cline ha come core un agente open source BYOK con interfacce VS Code e CLI. Ha anche un client JetBrains, che però non è open source al momento della scrittura. Sia Cline che OpenCode supportano MCP e consentono di impostare regole di approvazione. Cline posiziona i controlli dell’editor in una sidebar. OpenCode usa sessioni terminale che possono girare separatamente da un editor. La scelta dipende soprattutto da dove lo sviluppatore vuole rivedere e approvare le modifiche.
Cline usa la licenza Apache 2.0. OpenCode usa la licenza MIT indicata. Entrambi permettono revisione e modifiche al sorgente, ma differiscono per interfaccia e file di progetto.
Aider e Codex CLI sono anch’essi agenti di coding basati su terminale. OpenCode copre uso da terminale, desktop e IDE nello stesso progetto e supporta modelli di diversi provider.
Installazione e primi passi con OpenCode
Lo script di installazione ufficiale funziona sulla maggior parte dei sistemi tipo Unix. Fornisce un modo per installare lo strumento da riga di comando:
Il comando scarica il binario di OpenCode e lo aggiunge all’ambiente dell’utente. Un gestore di pacchetti può essere più adatto quando gli aggiornamenti sono gestiti insieme al resto del sistema.
curl -fsSL https://opencode.ai/install | bashLe opzioni dei package manager includono npm i -g opencode-ai@latest, brew install anomalyco/tap/opencode su macOS e Linux, e scoop install opencode o choco install opencode su Windows. È disponibile un’app desktop per macOS, Windows e Linux. Su Windows, la documentazione di OpenCode consiglia WSL perché alcune funzioni del file system e della shell funzionano meglio lì.
L’installazione non include l’accesso ai modelli. La prima sessione richiede comunque uno dei metodi di accesso trattati nella sezione multi-modello.
Installare OpenCode prima di creare le istruzioni del progetto. Video dell’autore.
OpenCode è davvero gratuito da usare?
Posso usare i modelli Claude dentro OpenCode?
OpenCode funziona senza una connessione a Internet?
Il repository archiviato opencode-ai/opencode è lo stesso progetto?
Come gestisce OpenCode la privacy del mio codice sorgente?
Argomenti