Hermes Agent o OpenClaw: quale scegliere su un VPS?

La risposta breve

Hermes Agent e OpenClaw offrono entrambi un agent persistente su un VPS, accessibile tramite un'app di chat. Scegli Hermes Agent quando il compito principale dell'agent è il lavoro ricorrente: job pianificati e procedure che deve apprendere una volta e riutilizzare. Scegli OpenClaw quando il compito principale è la portata: un unico assistente che risponde su WhatsApp, Telegram, Discord, Slack e più di venti altri canali, esteso con pacchetti provenienti da un registro pubblico. Entrambi funzionano dalla CLI (interfaccia a riga di comando) e dalla chat, quindi la scelta dipende dall'aspetto a cui ciascun progetto dà priorità e da ciò che ciascuno espone sul server.

Questo confronto è stato redatto sulla base del tag v2026.9.7 di Hermes Agent (7 settembre 2026, rilasciato come v0.21.1) e del tag v2026.9.4 di OpenClaw (11 settembre 2026), quindi verificato nuovamente sulla documentazione aggiornata di entrambi i progetti il 10 ottobre 2026. Le opzioni di pinning di OpenClaw sono state ricontrollate il 17 ottobre 2026, la nota sul contesto di Ollama il 20 ottobre 2026, mentre la sezione sulla memoria e quella sull'abbonamento Claude il 25 ottobre 2026. I numeri delle release, le integrazioni Mem0 e lo Skill Workshop sono stati ricontrollati il 27 ottobre 2026. Entrambi i progetti rilasciano aggiornamenti frequentemente, quindi verifica nella documentazione eventuali modifiche. L'ultima release stabile di OpenClaw è ora v2026.10.7 (24 ottobre 2026). Hermes è passato dai tag basati sulla data ai tag di versione con v0.21.6 l'8 ottobre 2026 e la sua ultima release, v0.22.5, è stata pubblicata il 23 ottobre 2026. Ogni affermazione riportata di seguito proviene dalla documentazione del relativo progetto oppure dalle due fonti esterne indicate nei punti in cui vengono utilizzate.

A cosa serve ciascuno: approccio agent-first o gateway-first

Il confronto di Hostinger definisce Hermes Agent "agent-first" e OpenClaw "gateway-first". Questa distinzione è corretta ed è il modo più rapido per comprendere i due progetti.

Hermes Agent, sviluppato da Nous Research, è incentrato su un worker. Gli si assegna un'attività. Il worker la esegue in un backend terminale e annota ciò che ha appreso sotto forma di skill. Mantiene inoltre una piccola memoria con i fatti persistenti. La chat è uno dei diversi modi per inviare attività. La CLI, i job cron, il gateway di messaggistica e l'app desktop utilizzano tutti lo stesso agent, mentre il gateway è una funzionalità che si abilita con hermes gateway setup, non il componente da installare.

OpenClaw è incentrato sul suo Gateway. Il Gateway è un processo in esecuzione continua che la documentazione definisce come unica fonte autorevole per sessioni, routing e connessioni ai canali. I modelli e gli agent harness sono plugin che vi si collegano; il README cita Claude, Codex e i modelli locali come harness intercambiabili. La capacità di raggiungere gli utenti è il prodotto. L'agent è uno dei componenti ospitati dal Gateway.

I due progetti hanno adottato le idee migliori l'uno dell'altro. Ora entrambi associano i mittenti sconosciuti della chat a un codice, che devono fornire prima di poter comunicare con il bot. Entrambi consentono inoltre all'agent di creare autonomamente le proprie skill: Hermes tramite il relativo strumento skill_manage e OpenClaw tramite Skill Workshop. La distinzione centrale resta valida: Hermes è un worker con un'interfaccia chat, mentre OpenClaw è un hub di chat con un worker al suo interno.

Percorso di installazione e requisiti della VPS

Nessuno dei due progetti documenta un requisito minimo di RAM o CPU, quindi qui non ne viene inventato alcuno. Entrambi gli agenti hanno un consumo ridotto rispetto alle chiamate al modello che effettuano, e il carico effettivo sul server dipende da ciò che si chiede all'agente di eseguire. Quanta RAM e CPU richiede una VPS per un coding agent definisce il dimensionamento in base al carico di lavoro, non all'agente.

C'è un numero documentato che vale la pena conoscere. Quando Hermes usa il backend del terminale Docker, la documentazione imposta per impostazione predefinita i limiti del container sandbox a container_cpu: 1 e container_memory: 5120 (in MB). Si tratta dei limiti del container, non di un fabbisogno misurato, ma una VPS più piccola non può rispettarli.

Hermes si installa con uno script. Le installazioni attuali usano Python 3.14, che l'installer scarica tramite il proprio uv con versione fissata e checksum verificato, invece di usare quello del sistema. Su Linux, prima lo script richiede git, curl, tar e le utility SHA-256 (sha256sum, proveniente da coreutils). Sui sistemi glibc, Node.js gestito che configura richiede libatomic, e l'installer aggiunge quel pacchetto se manca.

sudo apt update && sudo apt install -y git curl tar coreutils
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
source ~/.bashrc
hermes doctor

Il codice viene installato in ~/.hermes/hermes-agent/ come checkout git modificabile e il comando in ~/.local/bin/hermes. Tutti i dati risiedono in ~/.hermes/. L'installer non richiede mai root: chiama sudo solo quando un utente non root non dispone di libatomic, e la documentazione indica di eseguirlo con l'utente che eseguirà l'agente, perché quell'utente è proprietario del checkout, della configurazione e del launcher. La pagina della documentazione non descrive il pinning, ma lo script dell'installer accetta --commit SHA, che fissa il checkout a un commit specifico dopo il clone o l'aggiornamento, e si interrompe se il commit non si trova sul branch installato. Recupera il commit associato al tag, esportalo come HERMES_SHA e passalo tramite:

git ls-remote --tags https://github.com/NousResearch/hermes-agent v2026.9.7
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --commit "$HERMES_SHA"

Se ls-remote stampa due righe, usa quella che termina con ^{}. Quello è il commit a cui punta il tag annotato, e --commit richiede uno SHA di commit, non un oggetto tag. Dopo l'installazione, hermes model seleziona il provider e il modello, hermes tools abilita gli strumenti, hermes setup esegue l'intera procedura guidata e hermes doctor verifica il risultato.

Anche OpenClaw si installa con uno script oppure tramite npm e richiede Node. La documentazione attuale richiede Node 24.22.1 o successivo nella linea 24, oppure 26.12.1 o successivo nella linea 26, con una libreria SQLite collegata compatibile con il reset del WAL; il requisito minimo è stato innalzato dalla release 2026.10.6. La documentazione indica che l'installer Linux scarica Node 24 LTS (supporto a lungo termine) quando non è presente. Sia l'installer ospitato sia npm accettano una versione esatta, che consente di applicare il pinning: il flag --version dell'installer accetta una versione npm, un dist-tag o una specifica di pacchetto e usa latest per impostazione predefinita; la pagina Updating riporta installazioni con versione esatta equivalenti per pnpm e Bun. La documentazione indica il flag --allow-scripts=openclaw per npm 12 o 11.16 e versioni successive; nelle versioni precedenti di npm, esegui lo stesso comando senza quel flag.

curl -fsSL https://openclaw.ai/install.sh | bash
# or, pinned through the installer:
curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version 2026.9.4
# or, pinned through npm:
npm install -g openclaw@2026.9.4 --allow-scripts=openclaw
openclaw onboard --install-daemon

openclaw onboard --install-daemon esegue la procedura guidata di configurazione e installa il Gateway come servizio systemd dell'utente su Linux. La configurazione risiede in ~/.openclaw/openclaw.json, che usa JSON5, quindi consente commenti e virgole finali. OpenClaw pubblica anche una linea Extended Stable per chi desidera meno cambiamenti ogni mese. Al 27 ottobre 2026, la release Extended Stable corrente è 2026.9.35, pubblicata il 27 ottobre 2026 come linea separata da quella stable principale, nella quale 2026.10.7 è contrassegnata come Latest. Le note di rilascio la definiscono una release esclusiva del gateway e l'equivalente attuale di LTS del progetto, descrivendola come OpenClaw di fine settembre 2026 con aggiornamenti di sicurezza critici, correzioni di affidabilità e prestazioni e funzionalità come il supporto per nuovi modelli. La documentazione descrive quattro canali, stable, extended-stable, beta e dev, e openclaw update --channel <name> per passare dall'uno all'altro.

La guida alla VPS di Hermes Agent e la guida al contenimento di OpenClaw descrivono l'installazione completa di ciascun agente, inclusi i controlli che ogni passaggio dovrebbe superare.

Cosa espone ciascuno sulla rete

Questa sezione determina la configurazione del firewall, quindi richiede la massima attenzione.

OpenClaw apre una porta per progettazione. Il Gateway è in ascolto sulla porta TCP 18789 per impostazione predefinita, scelta nel seguente ordine: --port, quindi OPENCLAW_GATEWAY_PORT, poi gateway.port nella configurazione e infine 18789. gateway.bind è impostato per impostazione predefinita su loopback; gli altri valori sono auto, lan (che significa 0.0.0.0), tailnet e custom. La Control UI usa la stessa porta, nel percorso radice: http://127.0.0.1:18789/. gateway.controlUi.basePath aggiunge un prefisso come /openclaw solo quando la UI viene pubblicata sotto un percorso gestito da un reverse proxy. La documentazione indica chiaramente il rischio: "I bind non loopback richiedono l'autenticazione del gateway. In pratica, questo significa un token/password condiviso oppure un reverse proxy con gestione dell'identità." gateway.auth.mode accetta none, token, password o trusted-proxy, e la procedura guidata di onboarding genera un token per impostazione predefinita. Lascia bind su loopback, accedi alla UI tramite un tunnel SSH ed esegui openclaw security audit per segnalare eventuali differenze rispetto a queste impostazioni predefinite.

Hermes non apre alcuna porta per il gateway principale. Il gateway si connette in uscita a ogni piattaforma di chat come client. La CLI comunica in uscita con un endpoint del modello e con un backend terminale. Il backend Docker comunica con il socket Docker locale. Il backend SSH comunica in uscita con un altro host sulla porta 22. Le porte indicate nella documentazione di Hermes appartengono a componenti opzionali: l'adattatore webhook (disabilitato per impostazione predefinita, WEBHOOK_PORT 8644), il webhook della WhatsApp Business Cloud API (8090 per impostazione predefinita) e il bridge WhatsApp, che usa la porta 3000 sul server. La pagina relativa a WhatsApp non specifica su quale indirizzo il bridge rimanga in ascolto, quindi mantieni chiusa quella porta nel firewall. Un server Hermes può quindi mantenere una policy in ingresso "solo SSH" senza modificare nulla nell'agent, a meno che tu non abiliti uno dei due webhook.

Le piattaforme di chat, nella maggior parte dei casi, non richiedono una porta in ingresso per nessuno dei due progetti. Entrambi usano il long polling o WebSocket in uscita per i canali principali. L'integrazione Slack di Hermes usa Socket Mode e la relativa documentazione specifica che l'istanza "non deve essere accessibile pubblicamente". L'integrazione WhatsApp di Hermes esegue un bridge Node.js che emula una sessione WhatsApp Web, associata tramite codice QR, e richiede Node.js v18 o versioni successive sul server. Il canale Telegram di OpenClaw indica che "il long polling è il trasporto predefinito. La modalità webhook è opzionale", mentre il canale WhatsApp usa esclusivamente il codice QR e funziona tramite WhatsApp Web, con il Gateway che gestisce il socket. Le eccezioni sono i percorsi che richiedono un URL pubblico: la modalità webhook di Telegram in OpenClaw (webhookUrl, webhookSecret, webhookPath), l'adattatore webhook generico di Hermes e l'opzione separata WhatsApp Business Cloud API di Hermes, che secondo la documentazione richiede un account Meta Business e un URL webhook pubblico. Evitali, salvo che tu ne abbia motivo.

Per impostazione predefinita, entrambi rifiutano i mittenti di chat sconosciuti. Hermes verifica, nell'ordine: un flag per consentire tutti i mittenti della piattaforma, l'elenco approvato per l'associazione, gli elenchi consentiti per piattaforma come TELEGRAM_ALLOWED_USERS, GATEWAY_ALLOWED_USERS globale, il flag globale per consentire tutti i mittenti e infine il rifiuto. Un mittente sconosciuto riceve tramite DM (messaggio diretto) un codice di associazione di 8 caratteri, che puoi approvare con hermes pairing approve <platform> <code>. Per OpenClaw, dmPolicy è impostato per impostazione predefinita su pairing in Telegram e WhatsApp, e l'approvazione viene eseguita con openclaw pairing approve <channel> <code>. Non impostare mai GATEWAY_ALLOW_ALL_USERS=true o dmPolicy: open su un bot che può eseguire comandi shell.

Come si applica il contenimento di OpenClaw a Hermes

Il contenimento descritto nella guida al contenimento di OpenClaw si basa su un utente non privilegiato dedicato, su un Gateway vincolato all'interfaccia di loopback e protetto dal firewall del VPS, su una sandbox Docker per l'esecuzione degli strumenti con agents.defaults.sandbox.mode impostato su all e su un token per tutto ciò che non usa loopback. La pagina dedicata alla sandbox di OpenClaw rende esplicito il confine: il processo Gateway viene sempre eseguito sull'host, mentre la sandbox sposta soltanto l'esecuzione degli strumenti. tools.elevated è un meccanismo di bypass che viene eseguito al di fuori della sandbox.

L'utente e il firewall si applicano direttamente anche a Hermes. L'utente dedicato fornisce la stessa barriera, e la checklist per la produzione di Hermes lo esprime in sei parole: "Non eseguire il gateway come root". La protezione del firewall è più semplice, perché il gateway principale non espone alcuna porta da vincolare e il token non deve proteggere nulla.

La sandbox corrisponde a terminal.backend in ~/.hermes/config.yaml. Hermes documenta sette backend: local, docker, ssh, singularity, modal, daytona e vercel_sandbox. Con docker, il container viene eseguito con --cap-drop ALL, quindi riaggiunge DAC_OVERRIDE, CHOWN e FOWNER e imposta --security-opt no-new-privileges e --pids-limit 256, con /tmp e /var/tmp su tmpfs montato in nosuid. Una differenza è importante. La documentazione di Hermes specifica che i controlli sui comandi pericolosi vengono saltati nei backend docker, singularity, modal, daytona e vercel_sandbox "perché il container stesso costituisce il confine di sicurezza". In Hermes, quindi, ogni backend offre una sola delle due barriere. Con il backend local si ottiene il controllo di approvazione, ma non il container. Con docker si ottiene il container, ma non il controllo di approvazione.

La documentazione di Hermes aggiunge una propria configurazione: "eseguire il gateway su una macchina o VM separata" (macchina virtuale) con terminal.backend: ssh. Il sistema che ospita il gateway conserva i token delle chat e la chiave del modello, ma non esegue mai comandi. Il sistema worker esegue i comandi e non conserva nulla di utile da sottrarre. Una VM usa e getta per gli agenti di coding è il worker naturale in questa configurazione, perché viene ricreato invece di essere ripulito.

Memoria: due file piccoli e congelati oppure uno spazio di lavoro attivo

I modelli di memoria differiscono più di ogni altro aspetto in questo confronto, e il confronto tra i due di mem0 è la spiegazione più chiara della differenza. La sintesi è questa: Hermes "ottimizza le sessioni lunghe con cache stabile", mentre "OpenClaw ottimizza la visibilità immediata". La documentazione di OpenClaw, verificata il 25 October 2026, conferma solo in parte questa seconda affermazione, come spiega il paragrafo su OpenClaw riportato di seguito.

[
  {
    "label": "Hermes MEMORY.md (hard cap)",
    "char_limit": "2,200"
  },
  {
    "label": "Hermes USER.md (hard cap)",
    "char_limit": "1,375"
  },
  {
    "label": "OpenClaw MEMORY.md (soft target)",
    "char_limit": "20,000"
  }
]

I dati relativi a Hermes provengono dalla sua documentazione sulla memoria. Il dato di OpenClaw è il budget predefinito di bootstrap per file, agents.defaults.bootstrapMaxChars, riportato nel riferimento di configurazione di OpenClaw, e corrisponde all'obiettivo indicativo riportato da mem0.

Hermes conserva due file in ~/.hermes/memories/. MEMORY.md contiene le note dell'agente ed è limitato a 2,200 caratteri. USER.md contiene informazioni su di te ed è limitato a 1,375 caratteri. La documentazione specifica che i limiti sono rigidi: una scrittura oltre il limite restituisce un errore invece di troncare il contenuto senza avviso. L'agente li modifica con tre azioni, add, patch e remove. patch sostituisce una parte all'interno di una voce e remove elimina una voce; entrambe individuano la destinazione tramite una sottostringa univoca. La documentazione specifica che l'azione replace non è più disponibile e che una chiamata replace restituisce un errore che rimanda a patch. Entrambi i file vengono caricati una volta all'avvio della sessione come blocco congelato nel prompt di sistema, mantenendo stabile il prefisso della prompt cache. Il costo di questo approccio è che una memoria scritta dall'agente durante la sessione viene salvata immediatamente su disco, ma non entra nel prompt fino alla sessione successiva. Per i fatti meno recenti, session_search esegue FTS5 (la ricerca full-text di SQLite) su tutte le conversazioni precedenti in ~/.hermes/state.db.

OpenClaw tratta la memoria come uno spazio di lavoro. ~/.openclaw/workspace/MEMORY.md è il file a lungo termine, che la documentazione descrive come "Caricato all'avvio di una sessione". Se il file supera il budget di bootstrap predefinito per file, pari a 20,000 caratteri, OpenClaw conserva intatto il file su disco e tronca la copia inserita nel contesto. Le note giornaliere si trovano in memory/YYYY-MM-DD.md. Non vengono inserite nel prompt a ogni turno; quelle di oggi e di ieri vengono caricate automaticamente con un /new o /reset senza argomenti. Uno strumento memory_search esegue il recupero ibrido, combinando similarità vettoriale e corrispondenza per parole chiave, su tutti i contenuti quando è configurato un provider di embedding. La spiegazione di mem0 afferma che MEMORY.md viene reinserito a ogni turno, e la documentazione di OpenClaw si avvicina a questo comportamento più di quanto lasci intendere la sua pagina sulla memoria. La pagina sul runtime dell'agente descrive l'inserimento dei file di bootstrap al primo turno di una nuova sessione, ma il riferimento di configurazione imposta agents.defaults.contextInjection su always per impostazione predefinita e offre una modalità continuation-skip che salta il reinserimento del bootstrap nei turni successivi; inoltre, la pagina sul modello utente afferma che le modifiche a USER.md "vengono acquisite nei turni successivi di una sessione di lunga durata". La documentazione non fa una promessa esplicita analoga per MEMORY.md, quindi va verificato il comportamento prima di contare sul fatto che una scrittura durante la sessione in quel file raggiunga il prompt al turno successivo.

La scelta migliore dipende dal lavoro. Un agente Hermes che esegue ogni notte lo stesso cron job vuole una prompt stabile e un insieme ridotto di fatti affidabili. Un assistente OpenClaw che gestisce cento chat brevi al giorno vuole uno spazio di lavoro ampio e note giornaliere ricercabili. Hermes elenca Mem0 tra i plugin dei provider di memoria esterni, che si aggiungono con hermes plugins install mem0 e si configurano con hermes memory setup, mentre mem0 pubblica un plugin @mem0/openclaw-mem0 per OpenClaw. Al 27 October 2026, le due integrazioni non sono equivalenti. Il plugin di Hermes offre una modalità server self-hosted che punta al server Mem0 tramite URL e chiave API; la relativa voce di catalogo descrive inoltre "l'estrazione dei fatti tramite LLM lato server". La pagina di mem0 per OpenClaw offre una modalità open source che configura il proprio LLM, embedder e vector store all'interno del plugin, salva i vettori localmente e non indica alcun server Mem0; afferma inoltre che "L'agente estrae fatti persistenti dalle conversazioni". Di conseguenza, un server di memoria Mem0 self-hosted si collega direttamente a Hermes, mentre il percorso self-hosted di OpenClaw viene eseguito localmente nel plugin. In entrambi i casi, i fatti a lungo termine vengono spostati in uno store esterno ai file di prompt con limite. Qualsiasi file in cui l'agente scrive diventa un input di cui in seguito si fida; pertanto il modo in cui la memoria dell'agente viene avvelenata si applica a entrambi i progetti e anche alle skill della sezione successiva.

Competenze: procedure scritte autonomamente o registro pubblico

Hermes scrive autonomamente le proprie competenze. Una competenza è una directory sotto ~/.hermes/skills/ con un file SKILL.md e le cartelle opzionali scripts/, references/, templates/ e examples/, nel formato agentskills.io. L'agente dispone di uno strumento skill_manage e il suo prompt di sistema indica tre condizioni per scriverne una: ha elaborato una procedura in più passaggi che vale la pena ripetere, ha trovato una soluzione alternativa dopo un errore oppure ha ricevuto una correzione da parte dell'utente. La documentazione descrive l'obiettivo come "lezioni, non log". Se non si vuole che un agente modifichi senza revisione il proprio insieme di istruzioni, impostare skills.write_approval: true; le nuove competenze vengono quindi preparate sotto ~/.hermes/pending/skills/ finché non vengono approvate. Hermes può anche installare competenze esterne tramite hermes skills install <identifier>: da repository GitHub come anthropics/skills, da skills.sh, da un URL diretto a un SKILL.md oppure direttamente da ClawHub. La documentazione specifica che ogni installazione dall'hub viene sottoposta a scansione per individuare esfiltrazione di dati, prompt injection e comandi distruttivi. Un rilevamento della community che non è pericoloso può essere ignorato con --force; un "verdetto di scansione pericoloso" blocca l'installazione anche con --force.

OpenClaw scarica competenze e plugin da ClawHub, il suo registro pubblico. openclaw skills search "calendar" ne trova una, openclaw skills install @openclaw/demo la installa, openclaw skills update --all le mantiene aggiornate e i plugin di codice vengono sottoposti a openclaw plugins install clawhub:<package>. Le competenze vengono caricate da un insieme ordinato di directory: <workspace>/skills ha la precedenza su <workspace>/.agents/skills e ~/.agents/skills, seguito da <state-dir>/skills, dalle competenze apprese dall'agente nel workshop e infine dall'insieme incluso. Il SKILL.md di una competenza può dichiarare metadata.openclaw.requires.bins e requires.env; OpenClaw esclude la competenza al momento del caricamento quando manca il binario o la variabile, producendo un errore più chiaro rispetto a una competenza che funziona solo in parte. Anche l'agente scrive autonomamente le proprie competenze. Il Skill Workshop contiene queste competenze apprese e la relativa documentazione specifica: "Ogni modifica viene applicata immediatamente, salva prima la versione precedente e può essere annullata." Per "immediatamente" si intende sul disco: la stessa pagina specifica che "Le competenze modificate vengono caricate nelle nuove sessioni. Una sessione in esecuzione conserva lo snapshot della competenza con cui è stata avviata." Con il valore predefinito skills.workshop.autonomous.mode: auto, una revisione in background le crea e le modifica autonomamente; per annullare una modifica, rispondere "undo" nella chat, dall'interfaccia Control UI oppure con openclaw skills workshop restore <name>. Impostando la modalità su propose, la revisione in background salva invece delle bozze, che possono essere applicate o scartate nella Control UI oppure esaminate con /learn drafts. Impostandola su off, la revisione in background viene arrestata, anche se l'agente continua a scrivere competenze quando glielo si chiede.

I modelli di revisione differiscono per il punto in cui viene eseguito il controllo. La documentazione di ClawHub specifica che "esegue controlli automatici sulle competenze pubblicate e sulle release dei plugin", che le release trattenute dalla scansione o bloccate possono scomparire dal catalogo pubblico, che gli utenti autenticati possono segnalare un pacchetto e che i moderatori possono nasconderlo; inoltre, per pubblicare è necessario un account GitHub abbastanza vecchio da superare il controllo di caricamento. Questa è la revisione a livello di registro. Hermes esegue la scansione al momento dell'installazione sul proprio computer e il controllo di approvazione della scrittura si applica alle competenze scritte dal suo agente. Le competenze apprese da OpenClaw non prevedono una fase di approvazione nella modalità predefinita auto, nella quale il controllo consiste nella cronologia degli annullamenti; la modalità propose conserva invece le modifiche in background come bozze finché non vengono applicate. La pagina delle competenze di OpenClaw si conclude comunque con la frase rilevante in entrambi i casi: "Trattare le competenze di terze parti come codice non attendibile. Leggerle prima di abilitarle."

Opzioni dei modelli e dell'autenticazione, e la questione dell'abbonamento Claude

Entrambi i progetti funzionano con una chiave API o con un modello locale ed entrambi passano attraverso OpenRouter. Le differenze riguardano i percorsi di abbonamento, che è ciò che la maggior parte delle persone che cerca informazioni su questo argomento vuole sapere.

Chiavi API. Hermes legge ANTHROPIC_API_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY e molte altre variabili da ~/.hermes/.env. hermes model consente di scegliere interattivamente un provider e un modello, mentre hermes config get model.default mostra la scelta effettuata. Nous Portal è un provider autonomo: hermes setup --portal è un unico accesso OAuth che fornisce un provider di modelli e il gateway degli strumenti ospitato. OpenClaw riceve ANTHROPIC_API_KEY tramite openclaw onboard --anthropic-api-key "$ANTHROPIC_API_KEY", mentre openclaw models list --provider anthropic mostra a cosa può accedere. La documentazione indica che una configurazione API nuova e la configurazione di Claude CLI usano per impostazione predefinita Opus 5.5 (anthropic/claude-opus-5-5), e include anche anthropic/claude-sonnet-5-5 e anthropic/claude-fable-5-1, che devono essere selezionati esplicitamente.

Modelli locali tramite Ollama. I due progetti indirizzano Ollama in modo diverso e confonderli causa effettivamente errori. Hermes usa l'endpoint compatibile con OpenAI: in config.yaml, imposta model.provider: custom e model.base_url: http://localhost:11434/v1 oppure seleziona "Custom endpoint" in hermes model. La documentazione specifica inoltre che Hermes "requires at least 64,000 tokens of context for agent use with tools". La lunghezza del contesto predefinita di Ollama dipende dalla VRAM: 4k sotto 24 GiB, 32k da 24 a 48 GiB e 256k da 48 GiB in su. Sotto 48 GiB, questo valore predefinito è inferiore al minimo richiesto da Hermes. La documentazione di Hermes specifica inoltre che la lunghezza del contesto non può essere impostata tramite l'API compatibile con OpenAI; avvia quindi Ollama con OLLAMA_CONTEXT_LENGTH=64000 ollama serve. OpenClaw segue l'approccio opposto. La pagina di OpenClaw dedicata a Ollama indica: "Do not use the /v1 OpenAI-compatible URL (http://host:11434/v1). It breaks tool calling and models can emit raw tool-call JSON as plain text." Per impostazione predefinita, OpenClaw comunica con l'endpoint nativo /api/chat di Ollama, usando un eventuale URL di base privo di percorso, come in http://host:11434, e modelli denominati ollama/<model>. Se ometti l'URL di base, usa l'host locale predefinito. Lo stesso daemon, URL opposti.

Un abbonamento Claude. Di seguito è riportato esattamente ciò che indicano le documentazioni dei due progetti, alla data di ottobre 2026, senza aggiunte.

Hermes: è disponibile un accesso OAuth tramite hermes model, selezionando Anthropic OAuth, oppure tramite hermes auth add anthropic --type oauth. Hermes inoltra quindi le richieste "as Claude Code against your Anthropic account". La documentazione aggiunge: "It only works if you're on a Claude Max plan and have purchased extra usage credits." La quota Max di base non viene consumata; l'utilizzo viene addebitato ai crediti aggiuntivi. Claude Pro non può usare questo percorso e la documentazione del provider indirizza gli abbonati Pro a un ANTHROPIC_API_KEY.

Hermes documenta anche un secondo percorso distinto, più recente del tag fissato da questo confronto: il plugin sperimentale claude-subscription-directsdk. Richiede Hermes 0.21.4 o versioni successive, quindi v2026.9.7 (v0.21.1) non può caricarlo. La relativa pagina richiede un abbonamento Claude Pro o Max e la CLI ufficiale Claude Code, installata e autenticata. Il plugin non conserva credenziali proprie e invia ogni turno tramite claude; non è quindi necessaria una chiave API separata e ogni turno utilizza la quota Agent SDK dell'abbonamento, contabilizzata alla stessa tariffa di claude -p. I crediti per l'utilizzo aggiuntivo vengono usati solo in un caso specifico: con Pro, Fable 5.1 addebita i crediti di utilizzo fin dalla prima richiesta e la pagina indica: "Disable extra usage in the account if you do not want overage billing." Installalo con hermes plugins install claude-subscription-directsdk, esegui claude auth login, quindi seleziona "Claude Subscription DirectSDK (Experimental)" in hermes model.

OpenClaw: la documentazione descrive il riutilizzo di "an existing Claude Code login through the installed executable on the same host". Installa la CLI di Claude sulla VPS, esegui claude auth login, quindi seleziona "Claude CLI" in openclaw onboard. Una seconda modalità usa un setup token: esegui claude setup-token, quindi openclaw models auth login --provider anthropic --method setup-token. Due frasi della stessa pagina definiscono i limiti: "Claude Code owns its existing login and subscription; OpenClaw does not persist or refresh that login", mentre l'utilizzo del piano di abbonamento tramite Agent SDK, claude -p e applicazioni di terze parti "still draw from the signed-in subscription's usage limits".

I due progetti descrivono in modo diverso la fatturazione di questo utilizzo e nessuna delle due pagine proviene da Anthropic. Prima di eseguire un carico di lavoro notturno con un accesso dell'abbonamento, leggi i termini correnti di Anthropic sull'uso di un piano Claude tramite applicazioni di terze parti. Entrambi i progetti documentano un percorso e tutti i percorsi passano dall'identità di Claude Code, non da un semplice accesso a claude.ai. Hermes limita il proprio percorso OAuth a Max con crediti aggiuntivi e il plugin sperimentale a Pro o Max tramite una CLI Claude autenticata. Il percorso Claude CLI di OpenClaw richiede che l'accesso sia disponibile sullo stesso host, mentre il percorso con setup token utilizza un token creato su una macchina qualsiasi con Claude Code installato.

Altri abbonamenti. Hermes documenta anche OpenAI Codex tramite OAuth con codice dispositivo associato a un piano ChatGPT e GitHub Copilot tramite il relativo flusso con codice dispositivo, anche se la pagina di Codex indica che i livelli di piano idonei "not currently documented". OpenClaw include Codex tra i propri harness sostituibili. Se paghi già uno di questi servizi, questo è un motivo concreto per preferire il progetto che lo documenta.

Postura di sicurezza, nelle parole di ciascun progetto

Hermes controlla i comandi. approvals.mode in config.yaml è smart per impostazione predefinita: un modello ausiliario valuta ogni comando. I comandi a basso rischio vengono eseguiti, mentre quelli chiaramente pericolosi vengono rifiutati. Se il livello di rischio non è chiaro, viene richiesta una conferma. manual richiede sempre una conferma quando rileva una corrispondenza pericolosa, mentre off disabilita il controllo. Lo scanner rileva le eliminazioni ricorsive, chmod 777 e i relativi comandi, mkfs, dd if=, i reindirizzamenti verso /etc/, systemctl stop, restart, disable o mask, DROP TABLE, curl ... | sh e le fork bomb. Nella chat, il gateway pubblica il comando e attende yes, y, approve, ok o go; per rifiutare sono disponibili no, n, deny o cancel. Dopo il timeout predefinito di 300 secondi, il comando viene negato. Il flag --yolo (oppure /yolo in una sessione o HERMES_YOLO_MODE=1) salta le richieste di conferma, ma anche in questo caso resta attivo un elenco di blocco rigido: rm -rf / e le sue varianti più ovvie, le fork bomb, mkfs su una root montata, dd da /dev/zero verso un disco e gli URL non attendibili inoltrati a sh. Come indicato nella sezione sul contenimento, questo controllo è disattivato sui backend dei container.

OpenClaw definisce i confini. La sua pagina sulla sicurezza afferma che il Gateway è «un confine attendibile per ogni gateway» e «non un confine di sicurezza multi-tenant ostile per utenti reciprocamente avversari». Di conseguenza, due persone che non si considerano reciprocamente attendibili devono usare due Gateway con due insiemi di credenziali. Le policy di autorizzazione e negazione degli strumenti vengono verificate prima delle regole della sandbox, quindi uno strumento negato globalmente resta negato anche all'interno di una sandbox. I profili di accesso per agente e una modalità di sola lettura restringono ciò che un agente può modificare. openclaw security audit confronta la configurazione attiva con impostazioni predefinite sicure. Per le skill, il controllo consiste nella revisione di ClawHub descritta sopra, nella cronologia degli annullamenti di Skill Workshop e nella modalità opzionale di bozza, oltre all'indicazione di leggere le skill di terze parti prima di abilitarle.

Nessuno dei due progetti sostiene di offrire più di questo. Hermes non afferma che il suo scanner rilevi ogni problema; la documentazione consiglia di usare un container o una seconda macchina quando il rischio aumenta. OpenClaw non afferma che la sandbox contenga il Gateway stesso e lo specifica nella pagina dedicata alla sandbox. Sono documentazioni trasparenti, un buon segnale per software che si intende lasciare in esecuzione senza supervisione.

Matrice decisionale

Flussi di lavoro ricorrenti: Hermes. Cron job con memoria, una skill che scrive dopo aver eseguito la stessa attività per la terza volta, una memoria che non può saturare e un backend terminale scelto in base al livello di rischio. Se la settimana dell’agente è composta soprattutto da job e solo occasionalmente da conversazioni, questa è la soluzione adatta.

Copertura della messaggistica: OpenClaw. Più di venti canali dietro un unico Gateway, associazione dei DM attiva per impostazione predefinita su Telegram e WhatsApp, una Control UI sulla stessa porta e un registry di skill e plugin già pronti. Se la settimana dell’agente è composta soprattutto da conversazioni tra applicazioni diverse e solo occasionalmente da job, questa è la soluzione adatta.

Un solo server: entrambe le opzioni, con il limite di sicurezza più adatto. OpenClaw su un singolo VPS con un utente dedicato, gateway.bind: loopback, un token e sandbox.mode: all. Hermes su un singolo VPS con terminal.backend: docker, sapendo che il controllo di approvazione è disattivato all’interno del container, oppure con terminal.backend: local e approvals.mode: manual, sapendo che un’approvazione errata viene eseguita sull’host.

Due server: Hermes, secondo la propria documentazione. Gateway su un VPS, terminal.backend: ssh verso un VPS worker, token delle chat e chiavi dei modelli sul primo server, senza nulla di importante da conservare sul secondo. OpenClaw può essere posizionato dietro un reverse proxy con autenticazione trusted-proxy, ma il Gateway continua a eseguire le attività sul proprio host, a meno che ogni agente non sia in esecuzione in una sandbox.

Solo modello locale: controlla due volte l’URL. Hermes richiede /v1 e un contesto da 64k. OpenClaw rifiuta /v1 e richiede l’API nativa.

Hai già Claude Max con crediti aggiuntivi: Hermes documenta questo percorso, con un ambito limitato. Se esegui già Claude Code sullo stesso host, OpenClaw documenta il riutilizzo di questa configurazione; lo fa anche il plugin sperimentale DirectSDK di Hermes 0.21.4 o versioni successive, con Pro o Max. Se paghi Claude Pro, il percorso OAuth di Hermes non è disponibile: usa il relativo plugin o una API key. Una API key funziona con entrambi i progetti.

Se non hai ancora scelto tra questi due e le altre soluzioni: la panoramica degli agenti self-hosted confronta entrambi con Agent Zero, OpenHands e le altre soluzioni secondo gli stessi criteri.

FAQ

Hermes Agent può usare un abbonamento Claude Max?

La documentazione di Hermes indica due modalità. L'accesso OAuth di Anthropic, tramite hermes model o hermes auth add anthropic --type oauth, viene instradato come Claude Code sul proprio account. La documentazione specifica che "funziona solo se si dispone di un piano Claude Max e si sono acquistati crediti aggiuntivi per l'utilizzo". Il consumo viene addebitato su questi crediti aggiuntivi, non sulla quota di base. Il plugin sperimentale claude-subscription-directsdk, disponibile con Hermes 0.21.4 o versioni successive, funziona con i piani Pro o Max tramite una CLI di Claude Code con accesso effettuato. Ogni turno viene scalato dalla quota dell'Agent SDK inclusa nell'abbonamento. A ottobre 2026, leggere i termini di Anthropic prima di usare una delle due modalità per attività non supervisionate.

OpenClaw richiede una porta aperta sul mio VPS?

Non per l'uso normale. Il Gateway è in ascolto sulla porta TCP 18789, ma gateway.bind ha come valore predefinito loopback, quindi risponde soltanto su 127.0.0.1. Accedere alla Control UI all'indirizzo http://127.0.0.1:18789 tramite un tunnel SSH. Telegram usa il long polling e WhatsApp funziona tramite una sessione WhatsApp Web aperta direttamente dal Gateway. Di conseguenza, nessun canale richiede una porta in ingresso, a meno di scegliere la modalità webhook opzionale di Telegram. Se si esegue il binding su lan o tailnet, la documentazione richiede l'autenticazione del gateway: un token o una password condivisi, oppure un proxy con gestione dell'identità davanti al gateway.

Quale dei due è più sicuro da lasciare in esecuzione senza supervisione?

Nessuno dei due è sicuro con un backend local e le approvazioni disabilitate. La configurazione più sicura per Hermes consiste nell'usare due server: il gateway su un VPS e terminal.backend: ssh su un VPS worker. È la configurazione raccomandata dalla documentazione di Hermes "per la massima sicurezza". Per OpenClaw, la configurazione più sicura prevede un utente dedicato senza privilegi, gateway.bind: loopback, un token e agents.defaults.sandbox.mode: all. In entrambi i casi, considerare i file di memoria dell'agent e la directory delle skill come input che un attaccante può modificare tramite un messaggio di chat.

Posso eseguire Hermes Agent e OpenClaw sullo stesso VPS?

Sì. Non condividono porte o directory. Hermes conserva tutti i dati in ~/.hermes/. Il suo gateway principale non apre porte in ascolto e il bridge WhatsApp opzionale usa la porta 3000. OpenClaw conserva tutti i dati in ~/.openclaw/ ed è in ascolto su 127.0.0.1:18789. Assegnare a ciascun progetto un utente Linux dedicato, in modo che un agent compromesso non possa leggere i token di chat dell'altro. Non configurare entrambi con lo stesso token del bot Telegram. Telegram consente un solo client long polling per bot e risponde al secondo con 409 Conflict: terminated by other getUpdates request.

Come posso bloccare ciascun progetto su una release?

L'installer di OpenClaw e npm accettano una versione esatta: curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version 2026.9.4 o npm install -g openclaw@2026.9.4 --allow-scripts=openclaw. npm view openclaw versions elenca ciò che è stato pubblicato. L'installer di Hermes accetta --commit SHA. Recuperare quindi il commit associato a v2026.9.7 con git ls-remote --tags https://github.com/NousResearch/hermes-agent v2026.9.7 e passarlo come bash -s -- --commit <sha>. Entrambi i progetti pubblicano diverse release al mese. Hermes ora identifica le release con un numero di versione anziché con la data. Annotare quindi il tag rispetto al quale è stato eseguito il test.