KoboldCpp ha smesso di essere soltanto un runtime per LLM locali. Concedo, il maintainer del progetto, ha annunciato su r/LocalLLaMA che l'ultima versione include un KoboldCpp Agent Harness integrato: un agente che si attiva con una spunta nella scheda Admin del launcher grafico o con il flag --agent. Per chi non vuole assemblare pipeline agentiche esterne, è un cambio di passo: il terminale che si apre è pensato come sostituto leggero di strumenti come Opencode, Codex o Claude Code.

La configurazione è volutamente snella. L'agente offre nove strumenti integrati e un prompt di sistema da circa 2.000 token, comprensivo di tutte le descrizioni degli strumenti. Il parametro è rilevante per chi lavora con hardware locale: prompt più piccoli riducono la pressione sul contesto e lasciano più spazio alla generazione. Il rovescio della medaglia è che KoboldCpp fissa requisiti concreti: almeno 28k di contesto e 8k di generazione, con valori superiori raccomandati. La VRAM consigliata parte da 12 GB, il che colloca il setup in una fascia media per il self-hosted.

Un dettaglio importante riguarda l'esecuzione degli strumenti. Gli MCP caricati tramite mcp.json girano sul server KoboldCpp, mentre gli strumenti dell'agente girano sul client. Questa separazione non è solo architetturale: stabilisce dove atterrano i comandi e chi ne risponde. Le tre modalità di approvazione (on/auto/off) rendono esplicito il controllo, ma Concedo invita alla cautela nell'approvare le chiamate agli strumenti. È il tipico trade-off tra automazione e supervisione: l'agente locale può ordinare file o pianificare task, ma l'approvazione automatica sposta il rischio sull'utente.

Per accelerare l'adozione c'è un template .kcppt per Qwen 3.6 35BA3B da caricare nell'ultima versione. Non si tratta di un modello qualunque: il formato .kcppt è il contenitore che KoboldCpp usa per distribuire configurazioni già pronte. Chi parte da zero evita di dover montare manualmente il contesto e i parametri.

La mossa di KoboldCpp segnala una direzione precisa: l'orchestrazione agentica sta scendendo dentro i runtime locali. Non serve più un tool esterno da collegare a fatica: il launcher diventa anche il punto di controllo dell'agente. Questo cambia gli incentivi per chi sviluppa strumenti CLI separati. Se un runtime popolare offre un harness sufficiente per task di base, i progetti più complessi devono distinguersi su integrazione profonda o su casi d'uso enterprise. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per esaminare questi trade-off, ma il punto qui è la riduzione della complessità di setup.

C'è però un problema di fiducia che non riguarda il codice. Concedo chiede aiuto contro un sito di phishing che sfrutta blackhat SEO e si spaccia per kobolcpp(dot)com. Le segnalazioni a Google e all'hosting non hanno prodotto risultati. Per una community che scarica eseguibili da GitHub, la confusione tra dominio ufficiale e copia malevola è un rischio concreto: un utente che cerca 'KoboldCpp' su Google può finire su pagine con popup e malware. Non è una nota a margine: è la catena di distribuzione del software self-hosted che diventa bersaglio.

L'agente è già disponibile nelle release ufficiali su GitHub; per capirne i comandi basta digitare /help nel terminale.