GitHub Copilot alternative: le migliori con modelli locali nel 2026

Per chi cerca una “GitHub Copilot alternative”, la strategia di GitHub Copilot per i modelli locali è cambiata nel giugno 2026: oggi VS Code consente di eseguire offline chat e workflow agentici senza un account GitHub né un piano Copilot, ma i modelli locali non possono ancora generare i normali suggerimenti inline. Restano quindi solo tre motivi per cambiare: completamento locale mentre si scrive, self-hosting centralizzato oppure un workflow agentico più solido. E, prima di considerare hardware e amministrazione, l’alternativa a pagamento più economica per un team fa risparmiare appena $480 l’anno con 10 postazioni.

Risposta breve su GitHub Copilot alternative: Zed è la soluzione più completa

Zed è la soluzione migliore per chi cerca “GitHub Copilot alternative” e vuole che sia l’agente di coding sia i suggerimenti inline funzionino su un’infrastruttura sotto il proprio controllo. Kilo Code è preferibile quando cambiare editor non è un’opzione. Cline offre l’esperienza più convincente per un agente locale specializzato dentro VS Code; Tabby è la scelta giusta per distribuire un server di completamento gestito centralmente; Aider è l’opzione da terminale più lineare e orientata a Git; OpenCode, infine, copre il maggior numero di interfacce.

C’è anche una settima risposta: non cambiare. Se bastano chat locale e attività agentiche, la versione attuale di VS Code si collega già a Ollama e ad altri provider locali. Un’alternativa merita di essere adottata solo quando colma una lacuna precisa.

Prezzi, limiti, condizioni di prova e funzionalità riportati qui sotto sono stati verificati sulle pagine ufficiali di ciascun fornitore il 25 agosto 2026. Per “prezzo iniziale” si intende il costo del software o della piattaforma. Un modello locale può comunque comportare spese per hardware, elettricità, configurazione e manutenzione.

Prima di cambiare, ecco cosa fa già VS Code in locale

VS Code è ormai un host credibile per i modelli locali, ma copre soltanto una metà dell’esperienza Copilot. Con l’aggiornamento BYOK di giugno 2026, Microsoft permette a VS Code di collegarsi a Ollama, Foundry Local e provider compatibili per chat e workflow agentici supportati. Il tutto funziona senza accesso a GitHub o piano Copilot, anche completamente offline.

Questo non trasforma GitHub Copilot in un prodotto ospitato in locale. È VS Code a diventare il livello applicativo che fornisce al modello strumenti, contesto e ciclo d’interazione. Il modello può girare localmente, mentre l’editor mette a disposizione l’interfaccia per chat e agente.

Per confrontare le soluzioni senza ambiguità, occorre distinguere quattro concetti:

• Modello locale: l’inferenza avviene sul computer dell’utente o su hardware sotto il suo controllo.
• Modello self-hosted: l’endpoint opera all’interno di un’infrastruttura controllata dall’organizzazione. Può trovarsi su un altro computer o in un cloud privato, non necessariamente sul portatile dello sviluppatore.
• Agente: il modello può esaminare file, modificarne più di uno e usare strumenti come il terminale, rispettando il sistema di autorizzazioni dell’applicazione.
• Completamento inline: è il testo fantasma o il suggerimento su più righe che compare durante la digitazione e che in genere si accetta con Tab.

La lacuna riguarda proprio l’ultimo punto. La documentazione attuale sui modelli linguistici di Microsoft specifica che BYOK vale per chat e attività di supporto, non per i normali suggerimenti inline. Anche la ricerca semantica e le funzioni basate su embedding continuano a dipendere dal supporto di GitHub o Copilot. VS Code offre un’API per estensioni che altri prodotti possono usare per un completamento personalizzato, ma il percorso integrato per i modelli locali non invia a Ollama i suggerimenti inline.

La vecchia domanda “qual è un’alternativa locale a Copilot?” va quindi divisa in due:

1. Serve un modello locale che pianifichi e modifichi il codice all’interno di un ciclo agentico visibile?
2. Anche ogni suggerimento mostrato mentre si scrive deve essere generato localmente?

Se la risposta alla seconda domanda è no, installare un’altra estensione può aumentare la complessità senza offrire più privacy. Basta configurare l’editor Language Models, collegare il provider locale, scegliere il modello per la chat o per le attività agentiche supportate e mantenere l’editor esistente. Se invece la risposta è sì, Zed, Kilo Code o Tabby diventano pertinenti, perché ciascuno documenta un percorso locale per il completamento.

La stessa distinzione vale per le promesse di funzionamento offline. Una chat locale può operare senza internet mentre la ricerca nel repository, l’aggiornamento di un’estensione, un’operazione remota di controllo versione o un servizio di embedding ospitato continuano a comunicare fuori dal computer. “Il modello è locale” e “l’intero ambiente di sviluppo è isolato dalla rete” non sono promesse equivalenti.

Il prezzo di Copilot che si intende sostituire

Gli attuali piani individuali di GitHub sono Free, Student, Pro a $10 al mese, Pro+ a $39 al mese e Max a $100 al mese. Free comprende fino a 2,000 completamenti inline al mese, mentre Student è gratuito per gli studenti verificati. I piani per le organizzazioni sono Business a $19 per postazione assegnata al mese ed Enterprise a $39 per postazione assegnata al mese.

La pagina aggiornata dei piani GitHub segnala inoltre che, dal 22 aprile 2026, le nuove sottoscrizioni self-service a Business sono temporaneamente sospese per le organizzazioni su GitHub Free e GitHub Team. Il riferimento di $19 per il confronto non cambia, ma può cambiare il percorso d’acquisto. Una decisione di sostituzione va confrontata con il piano che l’organizzazione può davvero acquistare, non con una procedura di checkout ricordata a memoria.

Come sono state scelte queste alternative

Un prodotto è entrato nella selezione soltanto se la documentazione corrente del fornitore mostrava un percorso supportato verso un modello locale per un workflow di coding. Non è bastato un repository teoricamente modificabile per chiamare un endpoint locale. Sono rimasti fuori anche gli assistenti cloud che offrono solide garanzie di privacy ma inviano comunque l’inferenza al proprio servizio.

I sei prodotti sono stati valutati in base a cinque criteri:

1. Copertura: disponibilità dei modelli locali per l’agente, il completamento inline o entrambi.
2. Chiarezza della distribuzione: presenza di documentazione per Ollama, LM Studio, llama.cpp, un endpoint compatibile con OpenAI o un server self-hosted.
3. Coerenza con il workflow: integrazione in un editor, un terminale, un’app desktop o un servizio centrale.
4. Primo limite operativo: il primo vincolo incontrato da una distribuzione seria, come la migrazione dell’editor, un modello di completamento fisso, requisiti hardware minimi, il limite di una GPU o controlli d’identità assenti.
5. Costo totale: ogni livello software pubblico, più il costo di calcolo o inferenza esterno.

Non viene dichiarato alcun test prestazionale pratico. Latenza e qualità dell’output in locale dipendono troppo da dimensione del modello, quantizzazione, lunghezza del contesto, memoria GPU, struttura del repository e tipo di attività perché il risultato ottenuto su un portatile possa rappresentare l’intera categoria. La classifica usa invece funzioni attualmente supportate, prezzi esatti, limiti documentati e un’analisi normalizzata dei costi.

Questo metodo ha escluso anche alcuni nomi noti. Un assistente di coding solo cloud non diventa un’alternativa con modelli locali perché offre un piano gratuito generoso. Continue non compare in classifica perché la homepage attuale comunica l’acquisizione da parte di Cursor e presenta il codice open source rimasto come una base di partenza, non come un prodotto indipendente supportato per una nuova distribuzione. Questo cambiamento, da solo, rende obsolete molte vecchie liste di alternative locali a Copilot.

Per una panoramica più ampia tra cloud e locale, il confronto sui migliori assistenti AI per il coding nel 2026 include più soluzioni. Qui il perimetro resta volutamente ristretto: ogni prodotto in classifica offre un percorso documentato verso l’inferenza locale.

1. Zed: la migliore alternativa locale completa a Copilot

Zed è la sostituzione completa più convincente perché documenta l’uso di modelli locali sia per Agent sia per Edit Prediction. Edit Prediction è il livello di completamento inline di Zed e comprende suggerimenti su una o più righe. Una copertura così completa è rara ed elimina l’ambiguità di molte dichiarazioni del tipo “supporta Ollama”.

Si tratta di un editor di codice completo, non di un’estensione per VS Code. Per Agent, Inline Assistant e altre funzioni AI, i modelli locali possono essere eseguiti tramite Ollama, LM Studio, llama.cpp o un server locale compatibile. Una configurazione locale separata per Edit Prediction supporta Ollama, vLLM, il server llama.cpp, LocalAI e altri server che implementano l’API di completamento OpenAI.

Questa architettura rende Zed la risposta più lineare per chi lavora da solo, vuole entrambi i flussi in locale e accetta di cambiare editor. È anche il cambiamento di workflow più ampio dell’intera lista. Prima della migrazione vanno verificati estensioni, scorciatoie, abitudini di sviluppo remoto, strumenti di debug e convenzioni del team.

Ideale per: sviluppatori che vogliono attività agentiche e completamento inline locali in un unico editor.
Punto di forza: percorsi locali documentati sia per Agent sia per Edit Prediction.
Prezzi: Personal $0 per sempre; Pro $10/mese; Business $30/postazione/mese; oltre ai $5 inclusi in Pro, l’uso ospitato costa il prezzo di listino delle API più il 10%.
Prova gratuita: Pro per due settimane o fino all’esaurimento di $20 in crediti token di prova; nessuna prova gratuita per Business.

Prezzi di Zed e limite nascosto

Zed Personal costa $0 per sempre e comprende 2,000 previsioni di modifica ospitate accettate, oltre all’uso illimitato con chiavi API proprie o agenti esterni. Zed Pro costa $10 al mese, offre previsioni di modifica illimitate e $5 in token ospitati; superata questa quota, l’utilizzo ospitato viene fatturato al prezzo di listino delle API più il 10%. Zed Business costa $30 per postazione al mese e include criteri sui modelli validi per tutta l’organizzazione, controlli sui dati, visibilità unificata della spesa, previsioni di modifica illimitate e controllo degli accessi basato sui ruoli.

La parola “Business” può generare aspettative sbagliate. Il piano non include una quota fissa di crediti LLM, non offre una prova gratuita e al momento non dispone di SSO, SAML o SCIM. Non esiste un numero minimo di postazioni, anche se i moduli d’ordine partono da 25. In una distribuzione enterprise fortemente dipendente dall’identità, l’assenza della famiglia SSO può contare più della completezza di Zed sul fronte dei modelli locali.

Con 10 postazioni, Zed Business costa $3,600 l’anno prima dell’uso dei modelli o del calcolo locale. Copilot Business costa $2,280 per lo stesso numero di postazioni. Sul solo costo della piattaforma, Zed è quindi più caro di $1,320. Va scelto per la progettazione dell’editor e il controllo locale completo, non per risparmiare sulle licenze.

Mini tutorial: usare Zed Agent ed Edit Prediction tramite Ollama

Zed documenta separatamente i due percorsi locali. È bene mantenerli distinti durante la configurazione, così un agente funzionante non farà credere erroneamente che anche le previsioni inline siano locali.

1. 1

   Avviare il runtime locale

   Installare Ollama, eseguire ollama pull mistral per l’esempio Agent documentato da Zed, quindi lanciare ollama serve nei sistemi in cui il servizio non parte automaticamente. Zed dovrebbe rilevare i modelli Ollama scaricati e mostrarli nel selettore.

2. 2

   Selezionare il modello per Agent

   Aprire il pannello Agent, scegliere il modello Ollama rilevato e iniziare con un’attività circoscritta in sola lettura, per esempio la spiegazione di un modulo. Verificare dal provider selezionato e dall’attività del processo locale che la richiesta raggiunga Ollama.

3. 3

   Configurare Edit Prediction a parte

   Aprire le impostazioni di Zed per edit_predictions. Nell’esempio documentato dal fornitore, il provider è ollama, l’endpoint è http://localhost:11434, il modello è qwen2.5-coder:7b-base, il formato del prompt è infer e il numero massimo di token in uscita è 512.

4. 4

   Verificare entrambi i percorsi

   Disconnettere la rete su un computer di prova non critico. Inviare un prompt ad Agent, poi digitare in un file rappresentativo e controllare che compaia una Edit Prediction. Se il test di Agent riesce ma quello del completamento fallisce, solo metà della distribuzione è locale.

Il modello preciso va scelto in base al computer e all’attività. Il valore del tutorial sta nella verifica dei due percorsi, non nel nome del modello usato nell’esempio. Un modello locale incapace di chiamare gli strumenti in modo affidabile resta una scelta scadente per Agent, anche se produce completamenti accettabili.

2. Kilo Code: la migliore opzione locale in VS Code e JetBrains

Kilo Code è la soluzione più adatta quando l’editor deve restare lo stesso e sia il lavoro agentico sia il completamento inline richiedono un percorso locale. Le estensioni open source coprono VS Code e JetBrains, mentre la CLI aggiunge il terminale. La migrazione è quindi più contenuta rispetto a Zed; inoltre, il prodotto documenta Ollama locale per l’agente e Codestral locale tramite Ollama o LM Studio per l’autocomplete.

Questa forza porta con sé due vincoli. Al momento il modello di autocomplete di Kilo è limitato a Codestral: “completamento locale” non equivale dunque a poter scegliere qualsiasi modello. La guida per l’agente indica anche requisiti hardware importanti: almeno 24 GB di VRAM GPU oppure un Mac con almeno 32 GB di memoria unificata per eseguire a una velocità adeguata i modelli locali consigliati.

La documentazione di Kilo è insolitamente schietta sulla qualità. Consiglia qwen3-coder:30b per le attività agentiche, cita devstral:24b come alternativa e avverte che il modello Qwen più piccolo può sbagliare le chiamate agli strumenti, entrare in loop o produrre errori di sintassi più spesso di un modello cloud di frontiera. Raccomanda una finestra di contesto di almeno 32k e documenta un timeout API predefinito di 10 minuti. Sono requisiti operativi, non dettagli marginali.

Ideale per: utenti di VS Code o JetBrains che vogliono un agente locale e un percorso supportato per il completamento locale.
Punto di forza: la strada meno invasiva verso entrambi i workflow locali negli editor abituali.
Prezzi: Individual $0; Teams $15/utente/mese; Enterprise su preventivo; inferenza e calcolo cloud separati.
Prova gratuita: prova Enterprise di 14 giorni.

Prezzi di Kilo: tre fatture, non una

I piani piattaforma di Kilo sono Individual a $0, Teams a $15 per utente al mese ed Enterprise a un prezzo personalizzato. Teams aggiunge analisi, modalità agente condivise, fatturazione centralizzata, BYOK condiviso, controlli della privacy e assistenza prioritaria. Enterprise aggiunge SSO, OIDC, SCIM, log di audit, limiti per provider, BYOK tramite gateway privato, impegni SLA e assistenza dedicata. La prova di 14 giorni abilita le funzionalità Enterprise; al termine, il cliente sceglie Teams o Enterprise.

L’inferenza è una decisione separata. Auto Free, BYOK o locale costano $0 al mese in commissioni di inferenza della piattaforma Kilo. Kilo Gateway non richiede un abbonamento e addebita le tariffe esatte dei provider, senza maggiorazioni. Kilo Pass offre Starter a $19 al mese con un massimo di $26.60 in crediti mensili, Pro a $49 con un massimo di $68.60 ed Expert a $199 con un massimo di $278.60. Gli acquisti di crediti comportano una commissione di elaborazione del 5%.

Le funzioni cloud generano una terza fattura. Code Review costa $0.33 l’ora. Cloud Agent Docker e Small costano entrambi $0.60 l’ora. Gas Town e Cloud Agent Standard costano entrambi $1.20 l’ora. La fatturazione avviene al secondo e l’inferenza del modello resta separata.

Per 10 sviluppatori, Kilo Teams costa $1,800 l’anno contro i $2,280 di Copilot Business. La differenza di $480 è il tetto di spesa locale: se hardware aggiuntivo e amministrazione superano complessivamente $40 al mese, il risparmio apparente sulla piattaforma scompare. Bastano anche poche ore di un tecnico dedicate alla manutenzione del servizio locale per oltrepassarlo.

3. Cline: il miglior agente locale trasparente in VS Code

Cline è la scelta specializzata migliore per un agente di coding locale in VS Code basato su approvazioni esplicite. Mostra le modifiche ai file, le azioni nel terminale e la scelta del provider del modello senza imporre un abbonamento individuale alla piattaforma. Il percorso locale tramite Ollama, LM Studio e Atomic Chat è ben documentato.

Cline non copre però ogni funzione di Copilot. Il prodotto centrale è un agente, non una funzione propria per sostituire il completamento con Tab. Se l’obiettivo è generare localmente il testo fantasma durante la digitazione, occorre affiancargli un’altra estensione di completamento oppure scegliere Zed, Kilo Code o Tabby. Una seconda estensione può essere la scelta architetturale corretta, ma introduce due criteri di gestione, due percorsi di aggiornamento e potenzialmente due server di modelli da governare.

Il caso d’uso ideale è quello di uno sviluppatore che affida a un modello locale un’attività circoscritta, controlla ogni azione proposta e mantiene l’ambiente VS Code esistente. Il paradigma è “individua la causa di questo test non riuscito e proponi una patch”, non “prevedi i prossimi sei token a ogni tasto premuto”. L’interazione è più lenta e intenzionale rispetto al completamento di Copilot, ma può occuparsi di una parte maggiore di un’attività su più file.

Ideale per: utenti di VS Code che vogliono un ciclo agentico locale, visibile e controllabile.
Punto di forza: interfaccia agente individuale gratuita, runtime locali documentati e nessun abbonamento obbligatorio.
Prezzi: Open Source gratuito; Enterprise su preventivo; inferenza fornita separatamente.
Prova gratuita: nessuna prova Enterprise indicata; il livello open source è il percorso di valutazione.

Prezzi di Cline e scala hardware

Cline Open Source è gratuito per i singoli sviluppatori. Non ci sono costi di abbonamento o per postazione, ma l’inferenza ospitata si paga a consumo, salvo uso di una chiave propria o di un modello locale. Il livello gratuito elenca estensione per VS Code e CLI, architettura client-side sicura, marketplace MCP, workspace multi-root e supporto della community.

Cline Enterprise ha un prezzo personalizzato. Aggiunge estensione JetBrains, SSO, SLA, assistenza dedicata, fatturazione centralizzata, gestione della configurazione, controllo degli accessi basato sui ruoli, limiti per provider di inferenza, dashboard del team e log di autenticazione. La pagina prezzi attuale non indica alcuna prova gratuita Enterprise.

La guida hardware definisce un confine più utile del prezzo di piattaforma pari a $0. Cline associa da 16 a 32 GB di RAM a modelli piccoli o quantizzati, da 32 a 64 GB a modelli di medie dimensioni e almeno 64 GB a modelli più grandi e finestre di contesto più ampie. Gli endpoint locali predefiniti sono http://localhost:11434 per Ollama e http://localhost:1234 per LM Studio.

Questa scala dovrebbe guidare il progetto pilota. Un portatile con 16 GB può dimostrare che il collegamento funziona e fallire comunque nel workflow previsto a causa di generazione lenta, contesto insufficiente o uso debole degli strumenti. La distribuzione è pronta soltanto quando il modello scelto riesce a leggere una porzione sufficiente del repository e a completare l’attività rappresentativa entro i tempi accettabili per il team.

Il ruolo di Cline in una configurazione locale mista

Una separazione pratica prevede Cline per le sessioni agentiche esplicite e un provider dedicato di completamento locale per la scrittura del codice. Questa architettura può superare un unico modello generico, perché un agente ha bisogno di uso degli strumenti e ragionamento su contesti lunghi, mentre il completamento richiede bassa latenza e addestramento fill-in-the-middle. Il costo da pagare è la duplicazione operativa.

Per chi lavora da solo, questa duplicazione può ridursi a poche impostazioni. Per un’azienda significa invece due modelli approvati, due criteri per gli endpoint, due verifiche della telemetria e due procedure di rollback. Il confronto tra agenti di coding enterprise approfondisce la governance, ma la decisione immediata su Cline è semplice: va scelto quando la trasparenza dell’agente conta più della completezza di un solo prodotto.

4. Tabby: il miglior server di completamento self-hosted centralizzato

Tabby è la scelta migliore quando l’obiettivo principale è sostituire il completamento di Copilot con un servizio self-hosted gestito centralmente. È un assistente di coding open source costruito attorno a un team che gestisce un proprio server di completamento basato su LLM. Gli sviluppatori si collegano tramite estensioni per l’editor, mentre l’organizzazione mantiene il controllo del servizio.

Questa impostazione centrata sul server appartiene a una categoria diversa da quella di un agente locale sul portatile. È utile quando dieci o cinquanta sviluppatori devono condividere modelli approvati, contesto del repository, controlli di accesso e osservabilità invece di eseguire Ollama ciascuno per conto proprio. Trasferisce però all’organizzazione la responsabilità di disponibilità, aggiornamenti, capacità GPU, autenticazione e risposta agli incidenti.

Tabby è particolarmente adatto a un gruppo di sviluppo regolamentato o attento alla privacy, che attribuisce più valore al completamento centralizzato che al comportamento autonomo dell’agente. Answer Engine e navigazione del codice ampliano l’offerta, ma il completamento resta il motivo per preferirlo a un agente pensato prima di tutto per desktop. Anche un singolo sviluppatore può eseguire Community, sebbene Aider, Cline, Kilo Code o Zed richiedano in genere meno infrastruttura.

Ideale per: team che vogliono un unico server di completamento controllato e self-hosted.
Punto di forza: distribuzione centralizzata e local-first con estensioni per editor e piani per team.
Prezzi: Community $0/utente/mese; Team $19/utente/mese; Enterprise su preventivo; utilizzo cloud Pochi separato.
Prova gratuita: nessuna prova a tempo per Team o Enterprise indicata; Community supporta fino a 5 utenti.

Prezzi di Tabby: privacy senza sconto sulla licenza

Tabby Community costa $0 per utente al mese fino a 5 utenti. Tabby Team costa $19 per utente al mese fino a 50 utenti. Tabby Enterprise è un piano personalizzato con fatturazione annuale, utenti illimitati, SSO, distribuzione su misura, canale Slack dedicato per l’assistenza e priorità nella roadmap.

Pochi di Tabby Cloud applica una fatturazione separata, basata sull’utilizzo del modello. La pagina prezzi attuale comprende $20 di crediti mensili gratuiti, fattura automaticamente quando l’utilizzo supera $10 oppure a fine mese per importi inferiori e dichiara che Tab Completion è sempre gratuito senza limiti d’uso. L’offerta cloud non va confusa con il costo di calcolo del server self-hosted.

Con 10 postazioni, sia Tabby Team sia Copilot Business costano $2,280 l’anno in spese di piattaforma. Tabby richiede poi l’infrastruttura. La documentazione indica circa 8 GB di VRAM per CodeLlama-7B in modalità int8 e precisa che una singola istanza supporta una sola GPU. Il costo esatto del server dipende da proprietà dell’hardware, utilizzo, ridondanza e livello di assistenza richiesto, ma la conclusione è chiara: Tabby si acquista per il controllo, non per ridurre il costo delle licenze.

Il limite di una sola GPU

Il vincolo di una GPU per istanza Tabby è il limite operativo da pianificare. Una GPU singola può bastare per un piccolo team e trasformarsi in una coda quando molti sviluppatori lavorano contemporaneamente. A quel punto, scalare significa aggiungere istanze e decidere come instradare le richieste, non collegare più GPU alla stessa istanza.

Occorre misurare il tempo al primo completamento e i completamenti accettati nei momenti di massima sovrapposizione, non su un server inattivo. Una media veloce può nascondere un’esperienza scadente al 95° percentile e abituare gli sviluppatori a ignorare i suggerimenti. Vanno provati anche il ricaricamento dei modelli, il comportamento di fallback delle estensioni e ciò che accade quando il servizio non è disponibile. Il completamento è utile anche perché si integra senza attrito nella scrittura: ogni attesa ricorrente annulla questo vantaggio.

5. Aider: il miglior workflow da terminale nativo per Git

Aider è la migliore alternativa con modelli locali per chi vuole organizzare la sessione agentica attorno al repository e alla cronologia Git, non all’interfaccia dell’editor. Funziona nel terminale, costruisce una mappa del codebase, modifica i file, crea automaticamente commit e può eseguire linter e test. Il software Apache-2.0 non prevede un abbonamento alla piattaforma.

Il workflow è concreto: entrare in un repository, aggiungere i file pertinenti o lasciare che la mappa del repository orienti il contesto, chiedere una modifica, controllare il diff e usare Git per mantenerla o annullarla. Aider è quindi interessante per chi già si affida alle primitive del terminale e del controllo versione. È meno naturale per chi si aspetta un agente nella barra laterale, checkpoint visivi e completamento in background durante la digitazione.

Aider si collega a quasi ogni LLM cloud o locale, compreso Ollama. La documentazione su Ollama consiglia il prefisso di modello ollama_chat/ e segnala un problema insidioso: Ollama usa per impostazione predefinita una finestra di contesto di 2k e scarta silenziosamente il materiale in eccesso. Una sessione può sembrare funzionante mentre perde il contesto del repository, un esito peggiore di un errore esplicito.

Ideale per: sviluppatori orientati al terminale che vogliono un agente locale incentrato su Git.
Punto di forza: mappa del repository, commit automatici, diff, linting e test in un unico ciclo open source.
Prezzi: software Apache-2.0 a $0; utilizzo del modello o calcolo locale separati; nessun piano piattaforma a pagamento.
Prova gratuita: non applicabile, perché il software è gratuito e open source.

Prezzi di Aider e tetto di $120 per il singolo utente

Aider non ha livelli piattaforma Personal, Pro, Team o Enterprise. Il software è gratuito con licenza Apache 2.0. Il costo deriva dal provider del modello o dal computer che lo esegue.

Sostituire un solo abbonamento Copilot Pro da $10 al mese consente di risparmiare al massimo $120 l’anno. È la versione individuale del tetto di spesa locale. Se si acquistano una nuova GPU, memoria aggiuntiva, tempo di configurazione o prestazioni più lente esclusivamente per risparmiare l’abbonamento, i conti raramente tornano. Se l’hardware esiste già e le ragioni sono privacy, lavoro offline o controllo del modello, i $120 diventano un vantaggio secondario.

Il primo controllo di configurazione deve riguardare il contesto, non l’abilità nel formulare prompt. Aider documenta l’esempio di un server Ollama con 8k e modifica il contesto per ridurre i tagli silenziosi. Repository più grandi possono richiedere molto di più. Quando un modello locale inizia a dimenticare i requisiti, riaprire ripetutamente i file o modificare il simbolo sbagliato, bisogna verificare la finestra di contesto e la mappa del repository prima di attribuire il problema al formato dell’interazione.

6. OpenCode: il miglior agente locale su più interfacce

OpenCode è l’opzione migliore per avere un unico agente open source che accompagni lo sviluppatore tra terminale, estensione IDE e app desktop. Supporta più di 75 provider di modelli, compresi quelli locali, e il software di base non richiede un abbonamento a pagamento. Rispetto all’impostazione di Aider, incentrata sul terminale, il suo vantaggio è la flessibilità delle interfacce.

Ollama locale funziona tramite un endpoint provider compatibile con OpenAI all’indirizzo http://localhost:11434/v1. La documentazione dei provider espone la configurazione invece di nasconderla, compreso il suggerimento di partire da una finestra di contesto tra 16k e 32k quando le chiamate agli strumenti non riescono. Per i team che desiderano un controllo esplicito è un vantaggio; per gli utenti abituati al rilevamento con un clic significa lavoro aggiuntivo.

La proposta locale di OpenCode riguarda le sessioni agentiche, non la sostituzione completa del completamento inline di Copilot. Può funzionare in un IDE, ma la funzione distintiva è lo stesso agente multi-step disponibile in più interfacce. Va scelto per la portabilità tra ambienti e l’ampia scelta di provider, non per i suggerimenti con Tab.

Ideale per: sviluppatori che vogliono lo stesso agente con supporto locale in terminale, IDE e desktop.
Punto di forza: più di 75 provider e tre interfacce d’interazione.
Prezzi: core open source a $0; Go opzionale a $10/mese; Enterprise personalizzato per postazione.
Prova gratuita: progetto pilota interno open source prima del contatto commerciale per Enterprise.

Prezzi e gestione dei dati di OpenCode

Il core di OpenCode è un software open source gratuito; l’utente sceglie un modello locale, BYOK, gratuito oppure ospitato. OpenCode Zen è un gateway opzionale a consumo, con prezzi per token differenziati per modello. OpenCode Go è un abbonamento opzionale da $10 al mese per modelli di coding open ospitati. I limiti attuali sono espressi come soglie di valore: $12 ogni 5 ore, $30 alla settimana e $60 al mese.

OpenCode Enterprise applica un prezzo personalizzato per postazione. Quando il cliente fornisce il proprio gateway LLM, OpenCode dichiara di non addebitare i token utilizzati. Il percorso di valutazione consiste in una prova interna del prodotto open source, seguita da un confronto commerciale su configurazione centralizzata, SSO, gateway interno e assistenza all’implementazione.

La dichiarazione predefinita sui dati è netta: OpenCode afferma di non archiviare codice o contesto, mentre l’elaborazione avviene localmente o tramite chiamate dirette al provider scelto. Fa eccezione la condivisione facoltativa delle conversazioni, che invia fuori i dati della sessione. La documentazione Enterprise consiglia di disabilitare la condivisione durante la prova. La verifica della privacy dovrebbe coprire sia il percorso predefinito sia ogni via d’uscita opzionale.

Quale scegliere in base alle esigenze

Prima si individua la funzione mancante, poi si accetta il cambiamento di workflow più piccolo che riesce a fornirla. L’entusiasmo per un prodotto è un criterio debole, perché ogni opzione sposta costi e complessità su un livello diverso.

Restare con VS Code se basta un agente locale

Il percorso nativo di VS Code richiede il minimo cambiamento per uno sviluppatore o un team che desidera chat, pianificazione e attività agentiche supportate in locale, ma può mantenere il completamento Copilot ospitato o rinunciarvi. Conserva estensioni, abitudini di debug, ambienti remoti e competenze di supporto del team. Il punto di svolta è il completamento inline: se anche quei dati devono restare locali, il percorso BYOK integrato non basta.

È una scelta particolarmente sensata per un piccolo progetto pilota. Si configura un provider locale, si nascondono i modelli non approvati, si seleziona dove necessario un modello di supporto e si documentano le funzioni che dipendono ancora da GitHub. Non serve aggiungere un’altra estensione agentica finché un’attività rappresentativa non dimostra una lacuna concreta della configurazione nativa.

Scegliere Zed se la completezza conta più della continuità dell’editor

Zed è la scelta migliore per un professionista tecnico indipendente o un piccolo gruppo di prodotto disposto ad adottare un nuovo editor in cambio di un sistema coerente che unisca Agent ed Edit Prediction locali. A far cambiare la decisione è la compatibilità dell’editor. Se manca una sola estensione indispensabile, un debugger, un ambiente remoto o un workflow di accessibilità, Kilo Code diventa l’opzione più prudente.

In un’organizzazione più grande, l’identità può ribaltare la scelta ancora prima dell’idoneità dell’editor. Gli attuali controlli Business comprendono criteri per modelli e dati, ma SSO, SAML e SCIM non sono disponibili. Un’azienda che li richiede non dovrebbe trattare una funzione in roadmap come una garanzia di sicurezza.

Scegliere Kilo Code quando VS Code o JetBrains devono restare

Kilo Code prevale se sono necessari sia attività agentiche sia autocomplete locali all’interno dell’editor esistente. Richiede agli sviluppatori di cambiare estensione e configurazione del modello, non tutto l’ambiente di lavoro. La decisione si sposta altrove quando il vincolo di Codestral per l’autocomplete è inaccettabile o l’hardware locale non soddisfa i requisiti di memoria documentati per l’agente.

È anche la proposta economica più allettante e quella che si presta maggiormente a esagerazioni. Dieci postazioni Teams fanno risparmiare $480 l’anno rispetto a Copilot Business, prima di calcolo e lavoro umano. Il prodotto va scelto perché interfacce dell’estensione e controlli dei provider sono adatti; la differenza di prezzo è solo un piccolo contributo.

Scegliere Cline quando l’agente deve essere esplicito e supervisionato

Cline prevale quando gli sviluppatori desiderano un ciclo agentico deliberato in VS Code e non hanno bisogno che lo stesso prodotto generi suggerimenti inline. È adatto ad attività delle dimensioni di un issue, nelle quali lettura dei file, modifiche, comandi e approvazioni devono rimanere visibili. La scelta passa a Kilo o Zed quando un secondo sistema di completamento locale introdurrebbe troppa configurazione.

Per un team conta anche l’assenza di un prezzo pubblico. L’uso individuale è gratuito, mentre Enterprise ha un costo personalizzato. Prima si convalida il workflow open source; soltanto dopo aver identificato SSO, limiti dei provider, dashboard e supporto JetBrains necessari, si chiede un preventivo.

Scegliere Tabby quando l’organizzazione gestisce il servizio

Tabby prevale quando un gruppo piattaforma o sicurezza vuole un servizio centrale di completamento invece di un runtime del modello su ogni portatile. È la scelta più chiara per condividere un modello approvato e un’interfaccia prevedibile tramite estensioni dell’editor. La decisione cambia se il gruppo non ha un responsabile per disponibilità, aggiornamenti, capacità e assistenza agli sviluppatori.

Questa responsabilità non va assegnata implicitamente al “team infrastruttura”. Occorre indicare una persona o un gruppo, definire un obiettivo di servizio e calcolare il costo della GPU prima della distribuzione. Un servizio locale senza operatore diventa una versione meno affidabile del prodotto cloud che ha sostituito.

Scegliere Aider o OpenCode quando il terminale è al centro

Aider è preferibile quando diff Git e commit automatici costituiscono l’interfaccia di controllo naturale. OpenCode è più adatto quando lo stesso agente deve muoversi tra terminale, IDE e desktop mantenendo un’ampia scelta di provider. Nessuno dei due risponde direttamente all’esigenza di completamento inline locale.

Il criterio decisivo è la struttura del workflow. Aider è indicato per un repository, un thread nel terminale e un ciclo stretto di revisione dei diff. OpenCode si adatta meglio a più interfacce, sessioni e configurazioni dei provider. La guida alle alternative a Claude Code è il confronto adiacente quando la decisione riguarda soprattutto gli agenti da terminale e non il completamento in stile Copilot.

Confronto dei costi: calcolare il proprio tetto di spesa locale

I modelli locali permettono di possedere l’inferenza, non fanno sparire i costi. Con 10 postazioni, i costi annuali pubblici delle piattaforme sono:

• Kilo Teams: $1,800
• GitHub Copilot Business: $2,280
• Tabby Team: $2,280
• Zed Business: $3,600

Kilo è l’unico piano pubblico a pagamento che genera un risparmio in questo confronto tra quattro prodotti per team. Si tratta di $480 l’anno, cioè $40 al mese. Questa somma è il tetto di spesa locale: il massimo costo mensile aggiuntivo che la distribuzione può assorbire prima che il risparmio sulla piattaforma scompaia.

Nel tetto non rientra solo l’acquisto della GPU. Vanno conteggiati costo annualizzato dell’hardware, elettricità, hosting o spazio nel rack, monitoraggio, backup, download dei modelli, patch, sicurezza degli endpoint, risposta agli incidenti e tempo dedicato ad aiutare gli sviluppatori quando il servizio rallenta. Va incluso anche lo svantaggio qualitativo, se un modello locale più piccolo richiede più tentativi o genera più lavoro di revisione.

Per Tabby Team, rispetto a Copilot Business il tetto locale è zero, perché il prezzo delle postazioni è identico. Qualsiasi costo di calcolo e amministrazione rende Tabby più caro in termini monetari. Può comunque essere la decisione corretta quando il ritorno consiste in controllo dei dati, disponibilità in una rete isolata, indipendenza dal modello o comportamento di completamento condiviso.

Con 10 postazioni, Zed Business parte da $1,320 in più rispetto a Copilot Business. Deve giustificare questo sovrapprezzo attraverso l’editor e il livello di controllo. Per un singolo utente di Zed i conti cambiano: Personal è gratuito e può usare modelli locali, mentre Pro costa come Copilot Pro, ossia $10 al mese, e aggiunge le funzioni ospitate di Zed.

Aider, Cline Open Source, il core di OpenCode, Kilo Individual, Zed Personal e Tabby Community possono tutti portare il costo del software a $0 nel rispettivo ambito. Per un solo utente Copilot Pro, il massimo risparmio sull’abbonamento è $120 l’anno. Se l’hardware adatto è già disponibile, il vantaggio può essere utile. Acquistare un computer principalmente per recuperare $120 l’anno non lo è.

Le soluzioni da evitare

Continue è il prodotto da evitare più chiaramente per una nuova distribuzione supportata in questa categoria. La sua homepage attuale dichiara che Continue è stata acquisita da Cursor e che il codice open source rimane disponibile come base. Può bastare a una community esistente per creare un fork o mantenere il codice, ma non equivale a scegliere un prodotto indipendente con un percorso attuale di prezzi e assistenza.

Gli utenti attuali di Continue non devono allarmarsi. È opportuno bloccare le versioni, verificare repository e licenza, documentare gli endpoint dei modelli e stabilire chi si occuperà della manutenzione. Chi sta facendo un nuovo acquisto non dovrebbe metterlo sullo stesso piano di Zed, Kilo Code, Cline, Tabby, Aider e OpenCode senza tenere conto del cambiamento nell’assistenza.

Vanno evitati anche gli assistenti nati per il cloud il cui claim “locale” riguarda soltanto l’indicizzazione dei file sul computer, un’app desktop o un account di cloud privato. La domanda decisiva è dove avviene l’inferenza del modello per la funzione specifica che interessa. Occorre chiedere separatamente di chat, chiamate dell’agente, completamento inline, embedding, telemetria, segnalazioni di arresto anomalo, aggiornamenti e condivisione opzionale.

Infine, è meglio evitare il modello locale più grande che il computer riesce a caricare a fatica. Se un modello occupa quasi tutta la memoria disponibile, ne resta poca per contesto, editor, strumenti di build, container e sistema operativo. Un modello più piccolo con chiamate agli strumenti affidabili e latenza accettabile spesso porta a termine più lavoro di uno più grande che usa lo swap, va in timeout o perde il contesto.

La mossa di lunedì: un progetto pilota con due sviluppatori

Prima di cambiare il piano di un team, conviene provare un repository con due sviluppatori per una settimana. Lo scopo non è incoronare un modello sulla base di un prompt sintetico, ma scoprire il primo limite operativo del workflow che si intende acquistare.

1. 1

   Definire la funzione mancante di Copilot

   Scegliere un’attività principale: gestione agentica degli issue, completamento inline, self-hosting centralizzato oppure modifiche guidate dal terminale. Un progetto pilota che tenta di sostituire ogni funzione di Copilot contemporaneamente produrrà un verdetto ambiguo.

2. 2

   Scegliere un repository rappresentativo

   Usare un repository con la normale combinazione di linguaggi, test, tempi di build, struttura delle dipendenze e vincoli di sicurezza. Assegnare ai due sviluppatori le stesse tre attività circoscritte: spiegare un modulo, apportare una piccola modifica su più file e correggere un test non riuscito.

3. 3

   Bloccare la configurazione

   Registrare versione dello strumento, runtime locale, modello e quantizzazione, finestra di contesto, endpoint, hardware, stato della rete, impostazione di condivisione ed eventuale fallback ospitato. Senza questi dati, un buon risultato non è ripetibile e uno negativo non può essere diagnosticato.

4. 4

   Misurare il workflow, non l’output in token

   Rilevare tempo alla prima risposta utile, tempo necessario per un diff valido, suggerimenti inline accettati dove pertinenti, chiamate agli strumenti non riuscite, interventi manuali, tentativi e tempo del revisore. Annotare la latenza di picco quando entrambi gli sviluppatori usano il servizio nello stesso momento.

5. 5

   Prendere la decisione economica

   Confrontare il costo annuale della piattaforma con quello del calcolo e con il tempo mensile stimato per la gestione. Mantenere il percorso locale soltanto se soddisfa il requisito di controllo indicato e resta entro il tetto di spesa locale, oppure se il vantaggio di controllo giustifica chiaramente il superamento del tetto.

La decisione del lunedì dovrebbe essere contenuta: mantenere il percorso locale già presente in VS Code, estendere il progetto pilota con una delle alternative in classifica oppure fermarsi. Non bisogna acquistare postazioni, migrare editor o predisporre GPU condivise finché la prova non mostra quale precisa funzione di Copilot si sta sostituendo.

Domande frequenti

È possibile usare GitHub Copilot in locale?

VS Code può usare un modello locale per chat, workflow agentici supportati e attività di supporto senza un account GitHub né un piano Copilot. I modelli Copilot ospitati da GitHub non vengono eseguiti in locale e il percorso locale integrato non copre i normali suggerimenti inline.

C’è un modo per eseguire Copilot in locale?

La risposta precisa è che VS Code ospita il modello locale tramite BYOK. Si collega un provider come Ollama e si sceglie quel modello per la chat o per le attività agentiche supportate. Completamento inline, ricerca semantica e funzioni basate su embedding hanno dipendenze separate.

Si possono usare modelli locali con VS Code Copilot?

Sì, per chat e attività agentiche supportate tramite i controlli dei modelli di VS Code. No, per il normale modello dei suggerimenti inline in stile Copilot. Kilo Code e Tabby possono aggiungere il completamento locale in VS Code, mentre Cline aggiunge un agente locale.

Esiste una GitHub Copilot alternative gratuita con supporto per modelli locali?

Sì. Zed Personal, Kilo Individual, Cline Open Source, Tabby Community, Aider e il core di OpenCode offrono tutti un percorso software da $0. Hardware, inferenza ospitata, governance del team e manutenzione possono comunque avere un costo.

Scarica la checklist per l’audit dei workflow aziendali con l’AI e ricevi la prossima analisi pratica basata sui dati iscrivendoti alla newsletter.