Copilot CLI trova i modelli Ollama locali: requisiti e limiti della modalità offline

Copilot CLI può rilevare i modelli Ollama presenti sul server locale in esecuzione, ma non installa il runtime e non attiva da solo la modalità offline. La novità del 7 ottobre 2026 introduce il rilevamento tramite /model e indica come requisito la CLI 1.0.94-0. Data, comando e versione minima provengono dal changelog ufficiale GitHub.

Per una PMI che lavora su codice riservato è un’opzione da valutare con attenzione. Il modello locale può cambiare il percorso del contenuto, ma il progetto deve verificare anche rete degli strumenti, qualità delle risposte e costo dell’ambiente. Locale descrive dove gira una componente; offline descrive una configurazione del percorso completo. Confondere i due termini produce aspettative che il solo rilevamento non soddisfa.

Che cosa cambia nel percorso di selezione del modello?

La novità riduce il lavoro necessario per individuare un modello Ollama disponibile nel percorso CLI. Non equivale a scaricare il modello, dimensionare il computer o verificare che il servizio risponda correttamente. Il team deve prima predisporre un runtime in esecuzione e scegliere un modello compatibile con l’uso previsto. Il comando di selezione è il punto di accesso, non la preparazione dell’intero ambiente.

La documentazione GitHub sui modelli BYOK richiede streaming e tool calling. Un modello capace di rispondere a una domanda in chat può non gestire nello stesso modo chiamate agli strumenti e sequenze operative. La prova deve quindi riguardare il flusso dell’agente, non soltanto un testo generato correttamente in una interfaccia diversa.

La scelta del modello deve essere registrata insieme al compito. Se un aggiornamento cambia comportamento o requisiti, il team deve poter confrontare gli esiti. La guida ai modelli AI locali aiuta a leggere questa differenza fra disponibilità del modello e capacità del sistema di sostenere un lavoro aziendale concreto.

Come si distingue il modello locale dalla modalità offline?

La documentazione indica COPILOT_OFFLINE=true per la modalità offline esplicita. Un provider BYOK remoto rimane remoto: usare una propria chiave non sposta l’elaborazione sul computer. Queste distinzioni provengono dalla guida ufficiale GitHub e devono essere verificate nel percorso adottato dall’azienda.

Il team deve descrivere il flusso completo: client, runtime, modello, strumenti e destinazioni. Un modello locale può essere usato da un agente che tenta di installare dipendenze o leggere documentazione online. La possibilità di lavorare senza rete dipende quindi anche dal compito e dalla preparazione dell’ambiente. Un test eseguito con tutto già disponibile non dimostra che qualsiasi attività futura sarà offline.

Quali capacità verificare prima di usare il modello su un repository?

Il primo controllo riguarda la comprensione del compito e la produzione di un diff coerente. Il secondo riguarda la gestione degli strumenti: lettura dei file, interpretazione degli errori e scelta dei passi successivi. Il terzo riguarda la capacità di fermarsi quando manca una informazione. Un modello che produce codice plausibile ma non riconosce un test fallito richiede più supervisione di quanto sembri in una demo.

Il campione deve contenere modifiche di difficoltà diversa e casi con un esito noto. È utile osservare anche quanto contesto serva e se l’ambiente mantenga una latenza compatibile con il lavoro del team. Non esiste una qualità uniforme per tutti i modelli Ollama: scelta, configurazione e hardware influenzano il risultato. Le valutazioni devono restare specifiche al compito provato.

Il confronto con un modello remoto deve usare la stessa definizione di completamento. Se nel test locale un operatore corregge manualmente il diff, quel tempo entra nel costo. La qualità accettata dal team è una condizione del confronto, non una variabile da ridurre per far apparire migliore una opzione tecnica.

Come scegliere l’hardware senza promettere prestazioni non provate?

Il dimensionamento parte dal modello selezionato e dal carico previsto. Occorre capire se il computer debba sostenere un solo sviluppatore, più sessioni o un servizio condiviso. Memoria disponibile, tempi di caricamento e concorrenza possono diventare vincoli. Una macchina che risponde bene a una richiesta breve può comportarsi diversamente quando il compito richiede più file e una sequenza di strumenti.

Prima di acquistare hardware conviene fare una prova sull’ambiente disponibile o su una configurazione temporanea adatta. Il test dovrebbe registrare tempo al risultato accettato, utilizzo delle risorse e lavoro umano di correzione. Questi sono criteri proposti, non benchmark eseguiti da Giallo. Senza misure, una stima di prestazioni o risparmio resta una ipotesi.

Il costo totale include gestione del runtime, aggiornamenti, energia e continuità del servizio. Se il computer del fondatore diventa un componente indispensabile per tutto il team, occorre prevedere cosa succede quando non è disponibile. Il confronto locale-cloud deve considerare questa responsabilità operativa, non soltanto l’assenza di una tariffa per token nel percorso locale scelto.

Una software house può usarlo su codice proprietario?

Scenario ipotetico. Una software house italiana vuole valutare un modello locale per piccole correzioni su un gestionale proprietario. Il pilota usa un repository di prova, dati minimizzati e compiti con esito verificabile. L’agente prepara il diff e l’operatore lo rivede. Il codice produttivo e le credenziali reali non entrano automaticamente nel primo esperimento.

Il campione include una modifica semplice, una ricerca fra più file e un test che inizialmente fallisce. Il team osserva se il modello corregga la causa o modifichi il test per farlo passare. Questo comportamento conta più della capacità di generare una funzione isolata. Il risultato deve soddisfare il compito e mantenere i controlli pertinenti.

Il tema dei dati aziendali e privacy nell’AI resta applicabile anche in locale. Il contenuto può comparire in log, file temporanei e risultati condivisi. Ridurre il trasferimento verso un provider non elimina la necessità di definire accessi, conservazione e destinatari delle informazioni generate dal sistema.

Una PMI può automatizzare script interni senza dipendere dal cloud?

Secondo scenario ipotetico. Una piccola azienda commerciale vuole migliorare script che preparano report da esportazioni del gestionale. Il pilota locale assiste nella modifica del codice e usa file fittizi con la stessa struttura. Non esegue direttamente operazioni sui dati produttivi e non sostituisce il controllo dei totali da parte dell’amministrazione.

La prova verifica campi mancanti, codifiche incoerenti e formati diversi. Il modello può proporre una gestione degli errori, ma il test deve dimostrare che il report non perda righe o alteri importi. L’azienda misura il tempo per arrivare a una modifica verificata e la facilità con cui un collega riesce a mantenerla. Un output di codice lungo non rappresenta di per sé un vantaggio.

Il percorso offline può essere utile se l’ambiente contiene già dipendenze e documentazione necessarie. Se lo script richiede accessi remoti al gestionale, il progetto deve distinguere assistenza al codice ed esecuzione del processo aziendale. Il modello locale non trasforma automaticamente tutti i sistemi collegati in servizi presenti sul computer.

Quale ruolo ha la sandbox quando il modello gira in locale?

Il modello e gli strumenti hanno confini diversi. Un modello locale può comunque proporre o eseguire operazioni su file e rete tramite il client. La sandbox locale di GitHub Copilot affronta il perimetro degli strumenti nel percorso supportato; non è una conseguenza automatica del fatto che il modello sia ospitato da Ollama.

Il progetto deve provare accessi consentiti e vietati con materiale innocuo. Serve sapere se l’agente possa leggere cartelle estranee, scrivere fuori dal repository o usare credenziali già presenti. La configurazione deve riflettere il compito, mentre una richiesta di eccezione deve descrivere una necessità concreta. Aprire tutto l’ambiente per superare un blocco riduce il valore del controllo.

La guida su AI e sicurezza dei dati collega questi aspetti al lavoro delle persone. Un sistema locale può essere una scelta appropriata, ma la responsabilità di preparare e verificare l’ambiente resta in azienda. La vicinanza fisica del computer non rende automaticamente corretto il processo.

Come gestire gli strumenti browser o desktop nello stesso progetto?

Se il flusso include un browser, una sessione autenticata o un portale, bisogna definire un controllo specifico. Il Claude SDK per browser e computer use riguarda un altro ecosistema, ma evidenzia la separazione fra modello e ambiente operativo. Ogni componente deve avere accessi e conseguenze leggibili, senza importare garanzie da un prodotto a un altro.

La disponibilità del modello locale può invogliare ad affidargli più attività. Conviene invece mantenere inizialmente lo stesso mandato e misurare il risultato. Aggiungere strumenti cambia il rischio e la definizione di completamento. Una correzione di codice e l’invio di una pratica attraverso un portale sono lavori diversi, anche se avviati dalla stessa conversazione.

Il team deve indicare quali passaggi richiedano approvazione umana e come l’operatore possa controllare l’azione concreta. La configurazione offline non è una autorizzazione a compiere azioni irreversibili su dati locali. File, risultati e modifiche mantengono il valore aziendale che avevano prima dell’introduzione dell’assistente.

Che cosa misurare nel confronto fra modelli locali?

Il risultato principale è il compito accettato dal revisore, accompagnato da tempo totale e correzioni. Si registrano errori di comprensione, chiamate agli strumenti non valide e tentativi inutili. È utile distinguere un problema del modello da un ambiente preparato male. Senza questa separazione, un runtime instabile può far scartare un modello adatto oppure una demo facile può nascondere limiti importanti.

L’approfondimento su ML Drift e AI locale open source offre un altro punto di osservazione sul mantenimento del comportamento. Per il proprio progetto conviene conservare un campione di valutazione e riprovarlo dopo cambi di modello o configurazione. Un aggiornamento non dovrebbe essere considerato automaticamente migliore solo perché più recente.

La guida a Copilot AI aiuta a leggere il prodotto nel suo contesto. In questo caso si parla della CLI per sviluppo e strumenti, non di ogni servizio che usa il nome Copilot. Il confronto deve riguardare il percorso effettivo che gli sviluppatori utilizzeranno.

Prima di chiamare il pilota offline

Verifica modello e runtime realmente utilizzati. Controlla la configurazione offline esplicita e i requisiti della CLI. Prova il compito con le dipendenze previste e osserva quali strumenti richiedano rete. Controlla file temporanei, log e credenziali. Registra cosa funziona senza collegamento e quali passaggi restano fuori dal perimetro, invece di usare una etichetta generica.

Chi mantiene runtime e modelli dopo il primo test?

Un ambiente locale ha bisogno di una responsabilità operativa. Il team deve sapere chi installa gli aggiornamenti, chi verifica che il modello corretto sia disponibile e come venga gestita una interruzione. Una macchina configurata da uno sviluppatore può funzionare durante il pilota e diventare difficile da ripristinare se i passaggi non sono documentati. La continuità richiede istruzioni riproducibili, senza includere segreti nei documenti condivisi.

È utile registrare versione del runtime, modello selezionato e configurazione rilevante per il campione di prova. Quando cambia un elemento, si ripetono i compiti rappresentativi prima di estendere l’aggiornamento. Non occorre bloccare ogni evoluzione dell’ambiente; serve poter riconoscere quale modifica abbia introdotto una regressione o un nuovo requisito hardware.

Il responsabile deve prevedere anche una alternativa quando il servizio non è disponibile. Il team può tornare al lavoro manuale oppure usare un altro percorso già autorizzato, senza trasferire automaticamente codice riservato a un provider remoto per superare un blocco. La modalità di ripartenza deve rispettare gli stessi vincoli che hanno motivato la scelta locale. In questo modo la continuità operativa non diventa una eccezione implicita alle regole sui dati.

Quali promesse evitare nella decisione finale?

Non bisogna promettere costo zero, compatibilità universale o qualità identica fra tutti i modelli. Il routing intelligente fra locale e cloud descritto come sviluppo futuro non va presentato come funzione già garantita da questo annuncio. Anche l’assenza di trasferimenti verso l’esterno deve essere verificata sul percorso completo, senza dedurla dalla sola selezione di Ollama.

Non emerge una esclusione italiana dal changelog, ma requisiti di client, runtime, modello e hardware restano concreti. Per scegliere un ambiente AI locale adatto al codice e ai dati trattati, la progettazione del software aziendale può partire da un compito di prova, dal confronto fra risultati accettati e da una mappa delle destinazioni realmente raggiunte.