OpenHuman si vende come agente AI self-hosted desktop, "local-first, privacy-first". La sua stessa documentazione dice il contrario.
Non serve un'inchiesta. Non serve installarlo. Bastano due file pubblici del loro repository: il .env.example e la Issue #1793, aperta da un contributor e presa in carico dal team. Dicono che chat, vision, trascrizione, sintesi vocale, ricerca web e le 118+ integrazioni passano per un backend cloud proprietario, api.tinyhumans.ai. Il local-first reale si riduce a una cosa sola — gli embeddings della memoria — e quella funzione è spenta di default. Chi cerca un agente AI self-hosted, qui, trova un client desktop con un backend cloud davanti.
Il progetto è giovane: ~8.200 stelle su GitHub, GPL-3.0, repo creato il 18 febbraio 2026. Lo stesso pattern "AI agent self-hostable con migliaia di stelle" lo avevamo già analizzato con UI-TARS Desktop e i suoi requisiti hardware da datacenter. Qui il caso è opposto e più sottile: OpenHuman gira con pochi GB di RAM proprio perché il lavoro pesante non è in locale. È leggero sul tuo nodo perché non è davvero locale per le funzioni che contano.
Il repository OpenHuman su GitHub (tinyhumansai/openhuman, GPL-3.0)
OpenHuman come agente AI self-hosted: cosa promette e cosa fa davvero
OpenHuman è un'app desktop costruita da tinyhumansai in Rust e TypeScript su Tauri, con una mascotte animata, memoria persistente locale e 118+ integrazioni. Il README la presenta come una personal AI super intelligence privata, con tutti i dati di workflow locali e cifrati. Il punto da verificare non è cosa fa l'app — è dove finiscono i dati quando la usi davvero. E qui le fonti ufficiali del progetto raccontano due storie diverse, in pagine diverse della stessa documentazione.
La pagina GitBook Local AI elenca in modo esplicito cosa resta nel cloud, sempre: la chat ("frontier reasoning quality", il default), la vision, lo speech-to-text ("backend-proxied transcription"), il text-to-speech ("hosted") e la ricerca web ("backend proxy"). Cosa gira davvero on-device? Solo gli embeddings della memoria e la costruzione del summary-tree, con due modelli minuscoli via Ollama. Nessun ragionamento di chat, nessuna conversazione: in locale solo loop di background (heartbeat, learning). Lo scarto tra il claim e il funzionamento documentato è tutto qui.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Intelligenza Artificiale
Headroom compressione contesto LLM: il 90% di token in meno è hype
Headroom promette 60-95% di token in meno agli AI agent, ma i benchmark del repo dicono 19-77% e un utente in produzione ha visto 0%. Cosa regge e cosa no.
FunzioneChat / ragionamento
Dove gira di defaultCloud — api.tinyhumans.ai ("frontier")
Local-first reale?No
FunzioneVision (immagini)
Dove gira di defaultCloud — backend
Local-first reale?No
FunzioneSpeech-to-text
Dove gira di defaultCloud — "backend-proxied transcription"
Local-first reale?No
FunzioneText-to-speech
Dove gira di defaultCloud — "hosted text-to-speech"
Local-first reale?No
FunzioneRicerca web
Dove gira di defaultCloud — backend proxy (Seltz)
Local-first reale?No
Funzione118+ integrazioni (Composio)
Dove gira di defaultCloud — via backend OpenHuman
Local-first reale?No (Issue #1793)
FunzioneEmbeddings memoria
Dove gira di defaultLocale via Ollama — se Local AI è ON
Local-first reale?Sì, ma opt-in
FunzioneSummary-tree (memoria)
Dove gira di defaultLocale via Ollama — se Local AI è ON
Local-first reale?Sì, ma opt-in
Funzione
Dove gira di default
Local-first reale?
Chat / ragionamento
Cloud — api.tinyhumans.ai ("frontier")
No
Vision (immagini)
Cloud — backend
No
Speech-to-text
Cloud — "backend-proxied transcription"
No
Text-to-speech
Cloud — "hosted text-to-speech"
No
Ricerca web
Cloud — backend proxy (Seltz)
No
118+ integrazioni (Composio)
Cloud — via backend OpenHuman
No (Issue #1793)
Embeddings memoria
Locale via Ollama — se Local AI è ON
Sì, ma opt-in
Summary-tree (memoria)
Locale via Ollama — se Local AI è ON
Sì, ma opt-in
Il dettaglio che cambia tutto: la modalità Local AI, dice la doc verbatim, "is opt-in and ships off by default". Quindi l'unica parte realmente locale è anche quella che, su un'installazione appena fatta, non è attiva. E la stessa documentazione la sconsiglia:
"It is not worth turning on if you only have a few sources connected, the cloud path is faster and the privacy benefit is small." — Documentazione ufficiale OpenHuman (GitBook, Local AI)
È il progetto stesso a dire che il beneficio privacy del suo unico pezzo locale è piccolo e che la strada cloud è più veloce. Un assistente privacy-first che ti consiglia il cloud è un assistente che ha sbagliato l'etichetta.
La contraddizione è nel repo, non nelle nostre supposizioni
Qui non serve un'opinione: basta il file di configurazione pubblico del progetto. Il .env.example di OpenHuman definisce un backend cloud come default obbligatorio, non come opzione. Non stiamo interpretando il marketing — stiamo leggendo i valori di default che ogni nuova installazione eredita.
Un writeup di terze parti su dev.to afferma che i token OAuth restano cifrati localmente, mai instradati attraverso i server OpenHuman. Sembra rassicurante. Poi apri la Issue #1793, aperta il 15 maggio 2026 da un contributor del progetto e presa in carico dal team — e leggi il contrario, verbatim:
"OpenHuman currently routes Composio integration authorization and execution through the OpenHuman backend." — Issue #1793, aperta da un contributor e presa in carico dal team OpenHuman
Le 118+ integrazioni — Gmail, Drive, Stripe e il resto — passano per Composio instradato via api.tinyhumans.ai. La stessa Issue chiede di aggiungere una modalità per "eseguire Composio direttamente senza il backend OpenHuman", pensata esplicitamente per chi vuole più controllo sul flusso dei dati delle integrazioni, meno dipendenza dal backend, operatività local/self-hosted. Tradotto: la modalità self-hosted vera non esiste ancora. È una feature richiesta, in una issue aperta. Il claim che i dati delle integrazioni restino sul tuo device non regge allo stato attuale — e a documentarlo non siamo noi, è una issue ufficiale del progetto, presa in carico dal team.
C'è poi un problema di sicurezza strutturale, e qui vale la pena lasciare la parola a chi sul tema è autorevole. Simon Willison, parlando di agenti AI in generale, ha coniato il concetto di "lethal trifecta":
"The only way to stay safe there is to avoid that lethal trifecta combination entirely. Guardrails won't protect you." — Simon Willison, "The lethal trifecta"
I tre ingredienti tossici, secondo Willison, sono: accesso a dati privati, esposizione a contenuto non fidato, capacità di comunicare verso l'esterno. OpenHuman, per design, li ha tutti e tre insieme: 118+ integrazioni con dati privati, un web-scraper che legge contenuto arbitrario, esecuzione di tool con comunicazione esterna e auto-fetch ogni 20 minuti. Non è un difetto specifico di OpenHuman — è proprio la categoria di architettura che Willison sconsiglia di adottare, qui aggravata dal routing via backend di terzi.
L'obiezione: "ma 8.200 stelle non possono sbagliarsi"
C'è un'obiezione più forte di quella tecnica, ed è sociale: oltre 8.000 stelle su GitHub in pochi mesi sono un segnale fortissimo, e tanta gente non può sbagliarsi tutta insieme. È un'obiezione da prendere sul serio — e poi da guardare da vicino, perché la crescita di OpenHuman ha una forma particolare.
Partiamo dalle date. Il repo è del 18 febbraio 2026, e per circa due mesi è rimasto quasi piatto: ~100 stelle ancora al 22 aprile. Poi lo strappo: ~500 il 9 maggio, ~1.000 l'11, ~2.000 il 12, ~5.000 il 13, ~8.300 il 15. Circa 7.700 stelle in quattro giorni. Una curva del genere non è di per sé prova di nulla — i progetti diventano virali. Ma manca l'altra metà del segnale: la discussione.
I due post su Hacker News legati al progetto sono auto-pubblicati dal founder: lo "Show HN" si è fermato a 2 punti e 0 commenti; l'altro, "OpenClaw is toast. OpenHuman just landed", a 3 punti e 1 commento — del founder stesso, in chiave comment-bait ("commenta 'Openhuman' e ti mando il link per il download"). Nessun thread tecnico organico su HN o Reddit. Le recensioni presentate come indipendenti che circolano (firethering, dev.to) sono di fatto promozionali: ripetono i claim aziendali senza verificarli.
Aggiungiamo il profilo di chi c'è dietro, senza trasformarlo in processo alle intenzioni. Steven Enamakel (Dubai) viene dal mondo DeFi/crypto: fondatore di ZeroLend e di una stablecoin (MahaDAO). TinyHumans si descrive come un AI lab che lavora per avvicinarsi alla coscienza artificiale. Provenienza crypto, linguaggio "superintelligence", spike di stelle, auto-promo: nessuno di questi elementi, da solo, condanna il progetto. Messi insieme, suggeriscono di pesare la sostanza tecnica più del clamore. E la sostanza tecnica l'abbiamo già letta nel .env.example.
Sull'altro numero che gira, il "TokenJuice -80%": è una compressione pre-LLM (HTML→Markdown, URL accorciati, rimozione ridondanza) che ridurrebbe "fino all'80%" costo e latenza. "Fino a" senza benchmark pubblico, metodologia o numeri verificabili. Curiosamente lo stesso founder, su dev.to ad aprile 2026, non cita né "TokenJuice" né "-80%": parla di "1 dollaro per indicizzare ~5M token, ~10x più economico" — un claim diverso, anch'esso non verificabile in modo indipendente. Due numeri di marketing che non collimano tra loro restano ipotesi, non risultati.
L'app desktop OpenHuman con mascotte animata (frame demo, tinyhumans.ai)
Cosa significa per chi ha già Ollama nel proprio homelab
Per chi cerca un agente AI davvero self-hosted come alternativa a un assistente AI cloud, la domanda pratica è secca: OpenHuman sostituisce un setup Ollama locale? La risposta documentata è no, e per un motivo preciso. I modelli che girano davvero in locale sono all-minilm:latest (~23 MB, embeddings) e gemma3:1b-it-qat (~700 MB, summary-tree). Sono modelli da indicizzazione memoria, non da ragionamento. Il "supporto Ollama" di OpenHuman non significa "ChatGPT potente che gira tutto a casa tua": la chat vera resta cloud frontier via api.tinyhumans.ai.
Qui posso parlare per esperienza diretta, ma solo sul lato Ollama: nel mio homelab gira da tempo Ollama in un LXC Proxmox CPU-only, attorno ai 12 token/secondo, un ChatGPT privato che costa sui 13 euro l'anno di corrente. Quello sì è un agente AI self-hosted nel senso letterale: chat e ragionamento al 100% in locale, zero backend di terzi nel percorso. OpenHuman, nella sua configurazione di default, no. L'ho potuto verificare solo sui suoi file pubblici, non con un deploy mio — ed è esattamente il punto: la differenza tra i due si legge nel .env.example, non serve provarlo.
C'è anche un mito da smontare, e non riguarda OpenHuman in particolare. Anche se girasse al 100% in locale, locale non vuol dire privato in automatico. Lo nota bene un'analisi su kindalame.com che cita una scansione SentinelLABS+Censys: oltre 175.000 istanze Ollama esposte su internet pubblico. Verbatim: "Self-hosting only beats hosted AI if you keep the inference endpoint private, authenticated, and off the public internet." La privacy reale non è un default: è hardening. Vale per OpenHuman e vale per qualunque nodo AI nel tuo lab.
Il contrasto con il self-hosting che mantiene la promessa è netto. Quando abbiamo messo Vaultwarden in un LXC Proxmox con 7,4 MiB di RAM, "self-hosted" significava davvero che i dati non lasciavano il nodo: zero backend di terzi nel percorso. È il metro di paragone. Ed è la stessa logica con cui, analizzando l'AI search contro Google, la conclusione era che l'etichetta conta meno di cosa fa il prodotto sotto il cofano. Stessa dinamica, qui.
Onestà sul progetto: OpenHuman è sviluppo molto attivo (~1.843 commit, 33 contributor, ultimo commit 15 maggio 2026), dichiaratamente early beta ("Expect rough edges"), e l'idea della memory-tree deterministica con dual-write Obsidian-compatibile è tecnicamente interessante. Il problema non è che sia scritto male. Il problema è l'etichetta. Se e quando la modalità "direct, no-backend" della Issue #1793 verrà rilasciata, l'analisi andrà rifatta — perché solo allora OpenHuman potrebbe diventare l'agente AI self-hosted che promette di essere. Oggi non lo è.
Funzioni di un agente AI self-hosted che in OpenHuman girano davvero local-first, di default, su un'installazione nuova:
