Claude, GPT, Gemini o un modello eseguito sul proprio computer: per OpenCode il modello AI è una componente sostituibile del sistema. Il progetto è salito all’attenzione anche per aver reso disponibile Ox Alpha, il modello AI anonimo distribuito con una capacità dichiarata di 100 mila miliardi di token al giorno, ma OpenCode è qualcosa di più del canale attraverso cui provare uno stealth model. È un coding agent open source che può leggere e modificare una codebase, eseguire comandi, utilizzare strumenti esterni e delegare attività a subagenti, mantenendo separata la scelta dell’LLM e dell’infrastruttura che lo serve.
Questa separazione è il punto centrale del progetto, perché un coding agent non coincide con il modello linguistico. L’LLM decide come affrontare il compito, mentre intorno al modello serve un agent harness, cioè il software che gestisce strumenti, contesto, autorizzazioni, sessioni e interazione con l’ambiente di sviluppo. OpenCode concentra questo livello in un runtime aperto che può essere utilizzato dal terminale, attraverso un’applicazione desktop o negli IDE e collegato a oltre 75 provider AI, a endpoint personalizzati e a modelli eseguiti localmente.
Un progetto open source costruito da Anomaly
OpenCode è sviluppato da Anomaly, un’organizzazione open source che realizza strumenti per sviluppatori e infrastrutture legate agli agenti AI. Tra i suoi progetti ci sono Models.dev, un database open source con caratteristiche, prezzi e capacità dei modelli AI, utilizzato anche internamente da OpenCode, e OpenTUI, la libreria per interfacce da terminale che oggi alimenta la TUI di OpenCode.
Il progetto continua a presentarsi con una definizione essenziale – “The open source coding agent” – ma nel frattempo si è esteso ben oltre la sua originaria interfaccia da terminale. Al runtime si sono aggiunti l’applicazione desktop, le integrazioni con gli IDE, API, SDK, automazioni GitHub e Zen, il servizio opzionale con cui OpenCode seleziona e distribuisce modelli attraverso una propria infrastruttura.
La licenza MIT riguarda il runtime e l’agent harness, mentre i modelli AI utilizzati rimangono soggetti alle licenze e alle condizioni commerciali dei rispettivi provider. La distinzione consente di mantenere aperto il livello agentico senza imporre una particolare sorgente per il modello che lo alimenta.
Il modello è separato dal runtime agentico
Quando OpenCode riceve la richiesta di correggere un bug o implementare una funzione, il lavoro non consiste semplicemente nell’inviare un prompt a un LLM. L’agente deve individuare i file interessati, leggerli, decidere quali strumenti utilizzare, eventualmente eseguire comandi, applicare le modifiche e verificare il risultato, continuando il ciclo sulla base di ciò che emerge.
Il modello prende le decisioni all’interno di questa sequenza, mentre OpenCode fornisce l’ambiente nel quale quelle decisioni diventano azioni. È questa divisione dei compiti a rendere possibile sostituire l’LLM senza dover ricostruire il resto del sistema.
La configurazione separa infatti il provider dal modello e permette di collegare servizi commerciali, endpoint personalizzati e modelli locali. Possono quindi cambiare l’LLM o l’infrastruttura di inference senza sostituire agenti, strumenti e regole operative già definiti.
L’indipendenza dal modello non implica che tutti gli LLM siano equivalenti. Capacità di reasoning, tool calling, contesto disponibile, velocità, costo e qualità nel coding possono variare in modo significativo. Significa invece che il runtime agentico non coincide con il produttore del modello e può continuare a funzionare anche quando il motore AI sottostante cambia.
Un server separa l’agente dalle interfacce
Questa impostazione si riflette anche nell’architettura di OpenCode, che separa l’interfaccia dal runtime. La normale esperienza da terminale comunica con un server locale responsabile di sessioni, agenti, strumenti, file e provider, mentre l’interfaccia presenta e controlla il lavoro dell’agente.
Il server di OpenCode può essere utilizzato anche indipendentemente dall’interfaccia e il progetto mette a disposizione API e SDK per controllare il runtime programmaticamente. Terminale, applicazione desktop, browser e integrazioni con gli IDE possono quindi diventare client dello stesso sistema, mentre software esterno può costruire workflow propri sopra il medesimo runtime.
OpenCode può così essere utilizzato anche come runtime agentico locale integrabile in altri strumenti, anziché soltanto come applicazione interattiva per dialogare con un modello.
Le istruzioni del progetto entrano nel contesto dell’agente
Per lavorare in modo efficace su un progetto, OpenCode deve costruire un contesto che vada oltre il contenuto dei singoli file. Il progetto utilizza a questo scopo anche un file AGENTS.md, nel quale possono essere raccolte istruzioni persistenti sulla struttura del software, sulle convenzioni adottate e sulle modalità con cui l’agente deve operare.
Le regole di OpenCode permettono quindi di mantenere insieme al repository una parte della conoscenza necessaria all’agente. AGENTS.md diventa una forma di documentazione operativa destinata anche all’AI e può essere condiviso dal team, evitando di dover ricostruire le stesse istruzioni in ogni nuova sessione.
Una volta acquisito il contesto del progetto, OpenCode può esplorare file e directory, cercare simboli e stringhe, analizzare dipendenze, modificare il codice ed eseguire gli strumenti disponibili nell’ambiente locale.
Agenti diversi per pianificazione, sviluppo e attività delegate
OpenCode non obbliga a concentrare tutto il lavoro in un unico agente. La configurazione degli agenti combina system prompt, modello, strumenti e permessi e consente di creare profili differenti per attività differenti.
Gli agenti primari gestiscono il lavoro principale. Build è destinato allo sviluppo vero e proprio, mentre Plan privilegia l’analisi e la pianificazione prima delle modifiche. I subagenti possono invece ricevere compiti più circoscritti e lavorare con un proprio contesto, alleggerendo la sessione principale e separando attività che non devono necessariamente condividere tutte le informazioni.
Questa struttura permette, per esempio, di distribuire esplorazione della codebase, ricerca, implementazione e revisione fra agenti distinti. Gli stessi agenti possono inoltre essere personalizzati assegnando modelli, prompt, strumenti e autorizzazioni differenti, così che un team possa predisporre profili specifici per code review, documentazione, refactoring o controlli di sicurezza.
Sessioni separate permettono di lavorare in parallelo
La delega ai subagenti acquista maggiore rilevanza perché le attività possono essere eseguite in sessioni separate. In questo modo ricerche, analisi e compiti secondari non devono necessariamente occupare il medesimo contesto della conversazione principale.
Più sessioni possono inoltre lavorare sullo stesso progetto quando le attività sono abbastanza indipendenti da poter procedere in parallelo. Un agente può analizzare una parte della codebase mentre un altro esamina una dipendenza o prepara i test, riducendo il bisogno di serializzare ogni fase del lavoro.
La separazione fra server e interfaccia rende queste sessioni accessibili anche programmaticamente e trasforma OpenCode in una possibile base per orchestrazioni più complesse, nelle quali il coding agent diventa uno dei componenti di un workflow automatizzato più ampio.
I permessi limitano ciò che ogni agente può fare
La capacità di modificare file ed eseguire comandi rende il controllo delle autorizzazioni una parte essenziale dell’agent harness. OpenCode consente di stabilire quali strumenti possano essere utilizzati liberamente, quali richiedano l’approvazione dell’utente e quali debbano essere vietati.
Le policy possono cambiare da un agente all’altro, così che un profilo destinato alla review possa avere accesso in sola lettura, mentre quello incaricato dell’implementazione riceva privilegi più ampi. Il modello scelto rimane separato da queste autorizzazioni: sostituire l’LLM non modifica automaticamente i privilegi concessi all’agente sull’ambiente di sviluppo.
Questo aspetto diventa particolarmente rilevante quando OpenCode viene collegato a provider diversi o a modelli locali, perché permette di mantenere stabile il perimetro operativo anche quando cambia il sistema AI che prende le decisioni.
LSP e MCP collegano codice e strumenti esterni
La comprensione di una codebase non dipende esclusivamente dalla lettura dei file. OpenCode integra il Language Server Protocol – LSP, l’infrastruttura utilizzata dagli editor per ottenere informazioni strutturate sul codice, come definizioni, riferimenti, simboli e diagnostica.
L’agente può quindi lavorare anche sulle relazioni semantiche presenti nella codebase, invece di affidarsi soltanto alla ricerca testuale. A questo livello si aggiunge MCP, Model Context Protocol, attraverso il quale OpenCode può collegarsi a server locali o remoti e rendere disponibili strumenti e fonti esterne.
I due meccanismi svolgono ruoli differenti ma complementari: LSP aiuta l’agente a comprendere il codice, mentre MCP estende l’insieme delle risorse e delle azioni che può utilizzare al di fuori del repository.
Lo stesso runtime dal terminale all’IDE
Il terminale rimane centrale nell’identità di OpenCode, ma oggi è soltanto una delle interfacce disponibili. L’applicazione desktop porta le sessioni fuori dalla TUI, mentre l’integrazione con gli IDE permette di utilizzare OpenCode da VS Code e dai suoi principali derivati.
Il file aperto e il testo selezionato possono entrare direttamente nel contesto dell’agente, riducendo la necessità di copiare manualmente codice e riferimenti nel prompt. Il principio architetturale rimane però invariato: cambia il client, non l’agent harness sottostante.
È questa continuità fra interfacce differenti a separare OpenCode dai prodotti nei quali l’agente è incorporato direttamente nell’editor.
L’agente può entrare anche nel workflow GitHub
L’integrazione con GitHub estende lo stesso runtime al workflow del repository. Attraverso GitHub Actions, OpenCode può analizzare issue e pull request, proporre modifiche e lavorare su branch dedicati, arrivando a presentare il risultato attraverso una pull request.
Il coding agent può così operare anche senza una sessione interattiva da terminale, inserendosi in attività di triage, review o manutenzione automatizzata. Anche in questo caso la scelta del modello rimane separata dal runtime che esegue il lavoro.
Zen seleziona modelli e infrastruttura di inference
La possibilità di scegliere fra numerosi provider introduce una variabile meno visibile: lo stesso modello può comportarsi diversamente a seconda dell’infrastruttura che lo serve. Configurazione dell’inference, quantizzazione, caching, latenza e implementazione delle API possono influire sulle prestazioni di un coding agent anche quando il nome dell’LLM rimane identico.
OpenCode Zen interviene su questo livello. Il team dichiara di testare e confrontare modelli e provider per il coding agentico e di selezionare le combinazioni ritenute più efficaci, rendendole disponibili attraverso un proprio AI gateway.
L’utente può quindi delegare a OpenCode anche la scelta dell’infrastruttura di inference, oppure continuare a collegare direttamente i propri provider. Zen rimane facoltativo e non modifica il principio su cui è costruito il progetto: runtime, modello e provider possono continuare a essere scelti separatamente.
I concorrenti: Claude Code, Codex, Gemini CLI e Copilot
Il concorrente più immediato è Claude Code, il coding agent di Anthropic, che opera nel terminale e nel repository, utilizza strumenti, supporta pianificazione, subagenti e MCP e può essere impiegato anche attraverso IDE e altre interfacce. La differenza principale riguarda il rapporto con il modello: Claude Code nasce attorno alla famiglia Claude, mentre OpenCode costruisce esplicitamente il proprio runtime per poter cambiare provider e LLM.
OpenAI Codex compete sullo stesso terreno attraverso terminale, IDE e ChatGPT. Può leggere, modificare ed eseguire codice, lavorare su attività end-to-end e gestire più agenti. OpenAI distribuisce inoltre Codex CLI come progetto open source e mette a disposizione strumenti per incorporare l’agente in workflow esterni. Anche Codex separa quindi sempre più l’agent harness dall’interfaccia utilizzata, ma rimane costruito sui modelli e sull’infrastruttura OpenAI.
Molto vicino a OpenCode per impostazione è Gemini CLI, che Google distribuisce come agente AI open source per il terminale. Dispone di strumenti integrati e può collegarsi a server MCP, ma rimane concepito principalmente come interfaccia agentica ai modelli Gemini.
Un altro concorrente diretto è GitHub Copilot, soprattutto nelle sue modalità agentiche e da riga di comando. L’integrazione nativa con repository, issue, pull request e workflow di sviluppo costituisce uno dei suoi principali vantaggi, mentre la possibilità di utilizzare modelli di produttori differenti riduce una distinzione che in passato separava più nettamente OpenCode dalle piattaforme commerciali.
Anche Cursor e Windsurf competono sugli stessi workload, ma con un’impostazione diversa: sono ambienti di sviluppo completi nei quali il coding agent è integrato nell’editor, mentre OpenCode mantiene l’agent harness utilizzabile indipendentemente dall’IDE.
Il vantaggio di separare agente, modello e infrastruttura
Molte delle singole caratteristiche di OpenCode sono ormai presenti anche altrove. Claude Code dispone di subagenti, Codex gestisce agenti paralleli, Gemini CLI è open source, Copilot e gli IDE agentici permettono di utilizzare modelli differenti e MCP è diventato comune a buona parte della categoria.
La particolarità di OpenCode emerge dalla combinazione fra apertura del runtime e libertà sull’infrastruttura AI. L’agent harness è open source, il modello non è imposto dal produttore, sono disponibili oltre 75 provider, possono essere configurati endpoint propri e resta possibile eseguire LLM localmente. Zen aggiunge un percorso gestito per chi preferisce delegare anche la scelta del provider di inference, senza sostituire queste possibilità.
Per uno sviluppatore o un’organizzazione, questo significa poter mantenere agenti, istruzioni, strumenti, permessi e workflow mentre cambia il modello che li esegue. In un mercato nel quale gli LLM per il coding vengono aggiornati rapidamente e le differenze prestazionali possono spostarsi da un produttore all’altro, OpenCode costruisce la propria identità sulla separazione fra modello, agent harness e infrastruttura di inference.
