Un post su Reddit ha cristallizzato in poche righe la frustrazione che accompagna chiunque provi a mettere in piedi uno stack LLM locale per il coding: l’utente racconta di aver configurato OpenCode, un assistente AI per lo sviluppo, con Ollama come back-end, ma il modello — una variante di Gemma — rispondeva solo con parole singole («Hello», «I», «4»), verosimilmente un solo token per risposta. In certi casi, abbassando il limite di contesto, scattava un loop infinito di compattazione. Il colpevole, come sospetta lo stesso utente, è il context window.

La dinamica è istruttiva. Ollama, quando esegue un modello via ollama run, adotta un contesto predefinito di 4.096 token. OpenCode, invece, permette di dichiarare nel file di configurazione un limite molto più ampio — nell’esempio 32.732 token per il contesto e 8.024 per l’output. Il problema nasce perché quel valore non si propaga automaticamente al server Ollama: l’API compatibile con OpenAI espone un parametro max_tokens o context, ma se il runtime di Ollama non è stato istruito con una variabile d’ambiente (OLLAMA_CONTEXT_LENGTH) o modificando il file di unità di systemd, il modello taglia tutto ciò che eccede i 4k. E quando un client come OpenCode pretende di dialogare in una finestra da 32k ma il server ne serve solo un ottavo, il disallineamento produce sintomi bizzarri: generazione tronca a un solo token (come un buffer vuoto) oppure il loop di compattazione che il sistema tenta di usare per rimediare al contesto insufficiente.

L’utente ha provato a impostare il parametro con i metodi canonici — variabili d’ambiente, override del servizio systemd — senza successo. Qui si tocca un nervo scoperto del self-hosting. Non esiste un singolo file di configurazione che governi l’intero stack, ma una stratificazione di meccanismi: i parametri passati al lancio del modello, la configurazione del server Ollama, il file di unità del sistema operativo, e infine le impostazioni lato client di OpenCode. Il contesto diventa così un dato spezzettato, la cui coerenza è affidata all’utente e alla sua capacità di debug.

Questa vicenda è molto più di un bug report. È un segnale strutturale sulla maturità degli strumenti di inference locale. Mentre i provider cloud nascondono queste complessità dietro API coerenti, chi sceglie la via on-premise per la sovranità dei dati si trova a dover indossare i panni dell’amministratore di sistema, risolvendo mismatch che possono bloccare per ore un flusso di lavoro. La promessa del «code assistant privato, sotto il tuo controllo» si scontra con una curva di adozione che penalizza chi non ha background infrastrutturale. E così, paradossalmente, la ricerca di indipendenza dal cloud può spingere gli sviluppatori a tornare alle API esterne pur di ritrovare la produttività.

Non è solo una questione di tooling. La vicenda mostra in controluce una falla nell’ecosistema dell’AI locale: la mancanza di una negoziazione standardizzata del context window tra client e server di inference. Se ogni front-end (OpenCode, Continue, Aider) deve adattarsi ai meccanismi specifici di ogni runtime (Ollama, llama.cpp, vLLM), il mercato degli assistenti di codice on-premise resterà frammentato e riservato a una nicchia tecnica. Al contrario, un’interoperabilità robusta su questo parametro banale ma critico potrebbe sbloccare un’adozione molto più ampia. Per chi valuta oggi un deployment self-hosted, esistono framework analitici — come quelli offerti da AI-RADAR su /llm-onpremise — capaci di mappare questi trade-off e anticipare i punti di attrito. L’alternativa è restare intrappolati in un loop di configurazione che, proprio come il modello, produce solo un singolo token alla volta.