Il progetto che tratteremo in questo articolo è `open-jarvis/OpenJarvis` su GitHub, licenza Apache 2.0, scritto in Python, con una descrizione che lascia pochi dubbi sull’obiettivo del progetto: “Personal AI, On Personal Devices”. Nasce da Hazy Research e Scaling Intelligence Lab di Stanford, con un paper su arXiv del 16 maggio 2026. La precisazione serve, perché il nome è comune e in rete circolano progetti omonimi che non c’entrano nulla con questo.
OpenJarvis è un framework, un insieme di componenti da configurare ed estendere per chi ha dimestichezza con terminale, ambienti virtuali e package manager e non un’applicazione chiavi in mano, anche se un’app desktop esiste. Chi vuole installare e dimenticare troverà più attrito del previsto, mentre chi vuole costruirci sopra qualcosa di proprio trova un’architettura dichiarata e sostituibile pezzo per pezzo. Otto agenti arrivano già integrati e girano in tre modalità, a seconda che debbano rispondere su richiesta, partire a orario o restare in ascolto continuo.
Il repository è stato creato il 15 febbraio 2026, la versione 1.0.0 è del 16 maggio 2026 e l’app desktop è ferma alla 1.0.2 del 25 maggio 2026, senza nessuna release stabile successiva. Sei mesi di vita e uno sviluppo attivo che non ha ancora consolidato una cadenza di rilascio: su questo genere di maturità le date dicono più degli aggettivi.
Perché un assistente AI locale invece di un servizio cloud
La formula del progetto è eseguire in locale per default e chiamare il cloud solo quando serve davvero. Non è una posizione ideologica, visto che cambia dove passano i dati e quanto costa la singola richiesta al margine, e cambia anche cosa succede quando la rete non c’è. Il costo non sparisce, si sposta su hardware ed energia, ed è la ragione per cui il gruppo di Stanford ha proposto una metrica chiamata Intelligence per Watt, cioè accuratezza sul compito per unità di potenza consumata.
Nella revisione del 7 agosto 2026 quel lavoro riporta che i modelli locali rispondono correttamente all’88,7% di un milione di query reali a turno singolo e che la copertura di richieste servibili in locale è passata dal 23,2% al 71,3% fra il 2023 e il 2025. Gli stessi autori annotano che gli acceleratori locali restano almeno 1,4 volte indietro rispetto al cloud sulla metrica, che è insieme un limite e un margine.
Il motore che il framework installa per default è Ollama, che la propria homepage descrive come utilizzabile interamente offline. È un claim del produttore, vero nella misura in cui i modelli sono già scaricati sulla macchina.
Come funziona OpenJarvis
L’architettura descritta nel paper poggia su cinque primitive: Intelligence, Engine, Agents, Tools & Memory, Learning. Intelligence è il modello che ragiona, e le note del progetto citano come esempi on-device le famiglie Qwen, GPT-OSS, Gemma, Granite, GLM e Kimi. Non esiste una pagina che enumeri i modelli compatibili, quindi ogni elenco esaustivo che trovate in giro se lo è compilato qualcuno.
Engine è la parte che rende il progetto qualcosa di più di un involucro attorno a un singolo tool. Le note di rilascio della v1.0.0 dichiarano quattro motori locali dietro un’interfaccia unica, Ollama, vLLM, SGLang e llama.cpp, più i motori cloud raggiungibili dalla stessa astrazione. Cambiare motore, in questo disegno, non dovrebbe costringere a riscrivere gli agenti.
Fra gli agenti integrati, `simple`, `native_react`, `native_openhands`, `orchestrator` e `deep_research` lavorano su richiesta, `morning_digest` gira a orario fisso, `operative` e `monitor_operative` restano in esecuzione continua. La distinzione fra le tre modalità è la scelta di progetto che pesa di più nella pratica, perché un agente continuo consuma risorse anche quando non produce nulla di utile, mentre un digest schedulato costa quasi niente e non reagisce agli eventi.
I tool esterni si collegano via MCP. La reference API espone canali come Discord, Slack, Teams, Telegram e WhatsApp e connettori verso Google Drive, Notion e Apple Health, che restano voci di documentazione e non integrazioni che possiamo dichiarare testate una per una. L’origine accademica si vede nella telemetria energetica hardware-agnostica su NVIDIA, AMD, Apple Silicon e Intel, dato che misurare quanto consuma un agente è coerente con la metrica del gruppo e non si trova spesso altrove. L’app desktop, dal canto suo, parla con il backend su `http://localhost:8000`.
Come integrare OpenJarvis con Ollama
Il supporto a Ollama è nativo dalla v1.0 e non richiede configurazione manuale se si passa dallo script di installazione, che scarica e avvia il motore da solo. Ollama è a sua volta open source, licenza MIT, scritto in Go, ed espone un’API REST locale su `localhost:11434`, che resta il primo posto da controllare quando qualcosa non risponde.
Per cambiare modello la configurazione accetta una voce come `default_model = “qwen3.5:35b”`, e dalla riga di comando gli stessi passaggiì:
“`
jarvis model pull qwen3.5:35b
jarvis ask -m qwen3.5:35b “…”
“`
Quanta memoria serva per un modello dato non lo dice nessuna delle due documentazioni, visto che né il README di OpenJarvis né la documentazione di Ollama dichiarano minimi di RAM o memoria video. La documentazione GPU di Ollama, alla stessa data, dichiara la compatibilità e non il dimensionamento, ossia NVIDIA con compute capability 5.0 o superiore e driver 550 o superiori, AMD via ROCm, Apple via Metal. Il fabbisogno dipende dal modello scelto, e l’unico modo serio di scoprirlo è partire dal basso.
Come installare OpenJarvis su Windows
Il sorgente verifica per prima cosa la build di Windows e rifiuta qualsiasi build inferiore a ciò che precede Windows 10. Poi cerca Python e accetta dalla 3.10 alla 3.13, escludendo la 3.14 perché su Windows mancano ancora le wheel di numpy. Richiede git e, se non lo trova, prova a installarlo via winget. Installa uv con l’installer ufficiale di astral.sh, scarica Ollama e lo esegue in modalità silenziosa. Attende il daemon fino a sessanta secondi e, se non risponde, lancia `ollama serve` in background ed infine scarica `qwen3.5:2b`.
Registrare OpenJarvis come servizio passa da `Register-ScheduledTask` e richiede PowerShell elevato, il che fa perdere tempo a chi non lavora da amministratore. Senza privilegi si omette l’opzione di servizio e si avvia a mano, che per una prova basta.
Chi preferisce l’interfaccia grafica scarica `OpenJarvis-setup.exe`, avvia prima il backend e poi collega l’app. Quella pagina mostra la 1.0.1 mentre le release arrivano alla desktop-v1.0.2 del 25 maggio 2026, quindi il sito della documentazione è indietro rispetto ai rilasci.
Quando scegliere OpenJarvis rispetto ad altri framework per agenti AI
Per questo articolo non stileremo una classifica di confronto strutturato ma ci focalizzeremo sui criteri, che durano più di una tabella. Il primo è dove passano i dati, e se per il vostro caso d’uso sia un vincolo o una preferenza. Conta poi se il motore di inferenza è sostituibile o cablato nel prodotto, differenza che si paga quando il fornitore cambia prezzo, e se vi serve schedulazione ed esecuzione continua oppure soltanto una chat. La licenza pesa a sua volta, visto che una Apache 2.0 permissiva e una licenza dichiarata genericamente come “Other” non valgono uguale quando il software entra in azienda. Restano età e cadenza di rilascio, che su progetti di pochi mesi dicono più di qualunque benchmark.
L’unico termine di paragone su cui esistono dati primari è OpenClaw, con una scala di adozione incomparabile, con licenza dichiarata dall’API come “Other”. Il paper di OpenJarvis colloca OpenClaw e Hermes Agent fra i personal AI stack che instradano quasi ogni richiesta, spesso su dati locali sensibili, verso modelli di frontiera nel cloud. È una tesi degli autori del framework concorrente, cioè di una parte interessata, e va pesata come tale.
Se il vostro problema è orchestrare automazioni fra servizi più che far girare un modello sulla vostra macchina, il confronto giusto è con l’approccio a workflow visuali, e su quello abbiamo scritto un articolo su come creare agenti AI con n8n.
Vantaggi di un framework open source self-hosted
Gli autori dichiarano che le configurazioni ottimizzate on-device restano in media entro 3,2 punti percentuali dal miglior baseline cloud, con circa 800 volte di costo API marginale in meno e 4 volte di latenza end-to-end in meno. Nello stesso lavoro dichiarano anche che sostituire Claude Opus 4.6 con un Qwen3.5-9B locale, prima dell’ottimizzazione, costa dai 25 ai 39 punti percentuali di accuratezza, e che le configurazioni on-device eguagliano o superano il cloud su 4 benchmark su 8.
Altri vantaggi non hanno bisogno di numeri, a partire dalla licenza Apache 2.0, permissiva e aperta all’uso commerciale, il che semplifica l’approvazione interna. Il motore resta sostituibile per costruzione, e la telemetria energetica dà un dato che quasi nessuno misura. MCP evita di reinventare il collegamento ai tool, e per default il carico resta sulla macchina, con il cloud come eccezione dichiarata invece che come impostazione implicita.
Limiti da considerare prima dell’adozione
Sei mesi di vita e nessuna release stabile dopo il 25 maggio 2026 sono il dato che pesa di più. La documentazione ha pagine chiave che rispondono 404 e un sito disallineato rispetto alle release, quindi parte della verità sta nel README e parte negli script.
Nessuno dichiara requisiti hardware minimi, e non c’è modo di sapere in anticipo se la vostra macchina regge il modello che avete in mente. Manca anche un elenco esaustivo di modelli supportati, e non ci sono dati pubblici su download o utenti reali, quindi ogni affermazione sull’adozione è aria. Il calo di accuratezza sui modelli piccoli è reale e documentato dagli stessi autori, e il servizio in background richiede privilegi elevati, cosa che in molti contesti aziendali basta a chiudere il discorso.
Niente di tutto questo squalifica il progetto, lo colloca dove sta, fra le cose da provare con attenzione e da non mettere sotto un processo critico questo trimestre.
Come creare agenti AI sempre più evoluti: i consigli di Data Masters
Installare un framework è la parte facile, e quello che distingue un agente giocattolo da uno che regge il lavoro vero sta nell’orchestrazione, nella memoria, nella scelta dei tool e soprattutto nella valutazione, che è la disciplina che quasi tutti saltano.
Conviene partire da un modello piccolo e misurare prima di scalare, dato che la differenza fra sembrare funzionante ed esserlo si vede solo su un insieme di casi ripetibili. Il motore va trattato come un componente sostituibile, senza cablare il fornitore nel codice, visto che prezzi e condizioni cambiano più in fretta della vostra architettura. La scelta fra esecuzione su richiesta, schedulata e continua va fatta con criterio, perché la modalità sbagliata si paga in risorse sprecate o in reattività assente. E dei benchmark pubblicati da chi ha scritto il software conviene diffidare, anche quando sono onesti come in questo caso, perché nessuno misura sé stesso con i casi in cui perde.
Se questo è il livello a cui volete lavorare, il passo successivo è imparare a progettare e valutare sistemi agentici invece di assemblarli a intuito, che è quello che facciamo nella AI Agentic Application Masterclass.
AUTORE:Simone Truglia Apri profilo LinkedIn
Simone è un Ingegnere Informatico con specializzazione nei sistemi automatici e con una grande passione per la matematica, la programmazione e l’intelligenza artificiale. Ha lavorato con diverse aziende europee, aiutandole ad acquisire e ad estrarre il massimo valore dai principali dati a loro disposizione.
