Modelli Ollama di Hermes non visualizzati: controlli del catalogo e del provider

Se i tuoi modelli Ollama sono scomparsi dal selettore Hermes, controlla prima la versione e solo dopo intervieni sulla configurazione: il bug della cache del catalogo nativo che produce esattamente questo sintomo è stato chiuso come completato il 17 settembre 2026 e la correzione è inclusa nel tag v2026.9.21 (hermes-agent 0.21.4), ma non in v2026.9.14. Tuttavia, quella segnalazione chiusa non racconta tutta la storia. Il 21 settembre 2026 erano ancora aperte altre due segnalazioni relative a modelli Ollama mancanti da un selettore; una terza segnalazione aperta descrive un meccanismo di Hermes Desktop che produce lo stesso sintomo per qualsiasi provider il cui elenco di modelli visibili sia stato personalizzato almeno una volta, e ho letto che tale comportamento era ancora presente nel codice distribuito di quello stesso tag. Una quarta causa comune non è affatto un difetto. Ognuna lascia un indizio diverso e questa pagina serve proprio a interpretarli.

Prima due distinzioni, perché nei risultati di ricerca si sovrappongono. Hermes Agent è l'agente Python di Nous Research (MIT, non archiviato, ultimo push il 21 settembre 2026 secondo l'API GitHub). Hermes 3 e Hermes 4 sono la famiglia di LLM open-weight dello stesso laboratorio, un prodotto completamente diverso; esiste inoltre un motore JavaScript non correlato chiamato Hermes: nessuno dei relativi numeri di versione si applica qui. E Ollama locale non è Ollama Cloud: Hermes raggiunge il runtime locale gratuito sulla porta 11434 tramite il flusso Custom Endpoint, mentre Ollama Cloud è un prodotto a pagamento separato, implementato come slug di provider autonomo con un proprio file di cache. La mancata visualizzazione di un modello in uno non dice nulla sull'altro.

Tre livelli devono essere coerenti e solo uno di essi è Ollama

"Il modello non è nel selettore" è un'affermazione sull'ultimo dei tre livelli e la diagnosi consiste nell'individuare il primo livello che non è coerente.

# 1. Does Ollama itself list the model? This is the native catalog
#    Hermes reads when the endpoint qualifies for the /api/tags branch.
curl -s http://127.0.0.1:11434/api/tags | jq '.models[].name'

# 2. Does the OpenAI-compatible surface list it too? This is what a
#    generic custom endpoint is probed on.
curl -s http://127.0.0.1:11434/v1/models | jq '.data[].id'

Una cosa da escludere al primo livello: ollama list include modelli di embedding, e un modello di embedding non è un modello di chat selezionabile da un agente di programmazione. Kunavo non offre neppure modelli di embedding, text-to-speech o speech-to-text, quindi una route ospitata non colma questa lacuna.

Controlla prima la versione e leggila attentamente

Il problema #112898 — "l'elenco dei modelli Ollama locali lampeggia nel selettore" — è chiuso come completato, aperto il 16 settembre 2026 e chiuso il 17 settembre 2026. La pull request #113129 ha integrato la correzione come commit d6d6565 e un confronto GitHub colloca quel commit dentro il tag v2026.9.21 e fuori da v2026.9.14: il confronto v2026.9.21…d6d6565 restituisce lo stato behind con zero commit in avanti, quindi il commit è un antenato di quel tag; il confronto v2026.9.14…d6d6565 restituisce lo stato ahead con zero commit indietro, quindi il tag è un antenato del commit, non il contrario. La #112900 dell'autore del contributo è ancora aperta, il che non indica che la correzione manchi da main: il suo contenuto è stato integrato con la paternità originale nella pull request unita. Tutti gli stati sono stati letti dall'API GitHub il 21 settembre 2026.

Ecco la trappola. All'interno di quell'unico tag vengono distribuiti due numeri di versione diversi: in v2026.9.21, pyproject.toml legge version = "0.21.4" mentre apps/desktop/package.json legge "version": "0.17.6". Una segnalazione intitolata "Hermes Desktop 0.17.6" descrive quindi una build attuale, non una vecchia; liquidarla come obsoleta farebbe risalire erroneamente le tue prove. Nota anche il limite del controllo della versione: si tratta del contenimento Git in un tag. Non è stato verificato se la release pip, la formula Homebrew, l'immagine del container o il canale di aggiornamento automatico del desktop che hai effettivamente installato contengano quel commit.

Cinque cause e l'indizio che le distingue

Due di queste cause meritano una frase a parte. Il blocco desktop è quello che più facilmente viene scambiato per un problema di cache: leggendo apps/desktop/src/store/model-visibility.ts al tag v2026.9.21, quando un provider possiede chiavi memorizzate il renderer evita completamente di unire i valori predefiniti del provider, quindi i modelli scoperti successivamente non entrano mai nel menu. Il problema #114369 ha riprodotto esattamente questo comportamento su un provider personalizzato con discover_models: true ed è stato chiuso come duplicato, non come risolto; la riproduzione usava un endpoint vLLM, quindi considera il meccanismo indipendente dal provider, non una riproduzione specifica di Ollama. Altri due problemi restano aperti e irrisolti: #89874 (zero modelli per un provider Ollama personalizzato, con etichetta needs-repro, quindi una segnalazione non confermata e non un difetto accertato) e #71169 (modelli presenti nell'API Ollama, assenti dal menu a discesa desktop). Non è stato stabilito se uno dei due condivida una causa radice con #112898.

Anche il sintomo desktop è più netto di quanto ci si aspetti. In model-catalog-menu.tsx a quel tag, un provider il cui elenco di famiglie compresso è vuoto viene saltato direttamente; per questo la segnalazione abituale è "il mio provider è scomparso" anziché "il mio provider mostra un elenco vuoto".

Perché una normale apertura del selettore mostra un elenco obsoleto

Questo è il meccanismo alla base dell'intera classe di problemi ed è utile comprenderlo una volta. In una normale apertura del selettore, solo l'endpoint personalizzato corrente viene verificato in tempo reale; ogni altro endpoint configurato riceve la risposta dalla cache su disco in $HERMES_HOME/provider_models_cache.json. HERMES_HOME ha come valore predefinito ~/.hermes ma può essere sovrascritto, quindi non dare per scontato il percorso. Tre finestre in hermes_cli al tag v2026.9.21 regolano le nuove verifiche:

Si tratta di costanti interne al codice sorgente, non di impostazioni documentate; in questa verifica non è emersa alcuna opzione visibile all'utente per queste tre. Vale la pena conoscere un'eccezione intenzionale nel codice: un catalogo nativo vuoto è considerato autorevole solo all'interno del TTL breve e non viene mai servito come obsoleto, proprio per evitare che un Ollama privo di modelli alla prima apertura ne nasconda uno appena scaricato per l'intera finestra di sette giorni. Inoltre, le righe della cache sono indicizzate sull'URL normalizzato più un'impronta della credenziale, della modalità API e delle intestazioni aggiuntive, perché più righe di provider possono legittimamente condividere un URL proxy con chiavi diverse. La conseguenza pratica è che la rotazione di una chiave, la modifica del trasporto o la modifica di extra_headers invalida la voce corrispondente nella cache e la successiva apertura senza verifica mostra un elenco vuoto finché qualcosa non la aggiorna.

I controlli, in ordine

1. Conferma che Ollama lo abbia. Esegui i due comandi curl sopra. Se /api/tags non elenca il modello, nulla a valle può farlo.
2. Conferma la versione. Se usi una build precedente al tag v2026.9.21 e il sintomo è un elenco che alterna tra corretto e vuoto, stai osservando un bug già risolto: esegui l'aggiornamento prima di eseguire il debug.
3. Forza un aggiornamento. Il flag --refresh di hermes model dichiara nel proprio testo di aiuto che cancella la cache su disco del selettore e recupera nuovamente l'elenco aggiornato di ogni provider; tieni presente che cancella tutti i provider, non uno solo. Nella sessione, il riferimento ai comandi slash documenta /model --refresh come comando che recupera nuovamente l'elenco dei modelli del provider, mentre l'app desktop dispone di un controllo esplicito "Refresh Models" che richiede un catalogo aggiornato, mentre le aperture normali utilizzano la cache oraria.
4. Verifica quale percorso di probing riceve il tuo endpoint. Il ramo nativo /api/tags viene utilizzato quando il provider si chiama ollama, quando il nome è custom:ollama o termina con -ollama, quando l'URL corrisponde all'URL di base Ollama configurato oppure quando un URL personalizzato ambiguo sulla porta 11434 risponde effettivamente a /api/tags. Un'istanza Ollama servita su un'altra porta con un semplice nome custom ricade invece nel probe generico /v1/models: questo è ciò che il percorso del codice sembra fare, ma qui non è stato eseguito per confermare che il fallback funzioni nella pratica.
5. Se il problema è la discovery stessa, smetti di eseguirla. discover_models è impostato per impostazione predefinita su true; impostarlo su false fa sì che il selettore mostri l'elenco configurato invece di eseguire un probe in tempo reale.
6. Se è errato solo il menu desktop, molto probabilmente rientri nel caso #107391, che nessun aggiornamento può risolvere: il backend restituisce il modello, ma il livello di curatela del renderer lo elimina.

providers:
  # The published reference documents `api` for a providers entry.
  local-ollama:
    api: http://127.0.0.1:11434/v1
    # No key for local Ollama. Discovery is on by default; turn it off and
    # hand-write the list when the probe is the thing that is failing.
    discover_models: false
    models:
      - qwen3-coder:30b

model:
  default: qwen3-coder:30b
  provider: custom:local-ollama

Un dettaglio di configurazione trae ripetutamente in inganno e vale la pena chiarirlo. La documentazione di riferimento indica api come chiave dell'URL di base per una voce providers:, e nell'elenco dei campi di quella voce indica base_url e url come alias accettati; base_url è invece la chiave nella mappatura model: di primo livello. Documenta inoltre che le configurazioni precedenti utilizzavano un elenco custom_providers: di primo livello con base_url invece di api, ancora funzionante e migrato automaticamente da hermes update nella versione di configurazione v12. I report di bug nel tracker sono scritti in entrambi i modi, come ci si aspetterebbe quando entrambi vengono letti. Pertanto, è improbabile che una voce providers: che non ha effetto fallisca a causa del nome di questa chiave: controlla l'endpoint e gli altri campi della voce.

Vale la pena citare un altro dettaglio: la pagina di Hermes di Ollama illustra il prompt di configurazione come "Context length in tokens [leave blank for auto-detect]", mentre la documentazione dei provider di Hermes richiede almeno 64.000 token per l'uso con gli agenti e afferma che un endpoint locale che ne serve meno viene rifiutato all'avvio. Entrambe le fonti sono state verificate il 21 settembre 2026. Lasciare vuoto il campo non è di per sé errato, ma non risolve nulla se il server serve solo una finestra ridotta: aumenta quindi la finestra sul server (oppure fissala nella configurazione di Hermes) al valore indicato da Hermes e ricorda che questo errore produce un rifiuto all'avvio che indica la finestra servita, non una riga mancante nel selettore.

Verificalo, poi decidi se il locale vale la pena

Dopo una modifica, esegui queste tre operazioni in ordine: riapri il selettore senza --refresh e conferma che il modello sia elencato in un'apertura fredda, selezionalo e invia una richiesta limitata che restituisca un completamento. Il passaggio intermedio è importante perché un elenco corretto solo subito dopo un probe è il segnale distintivo del bug della cache, non di una soluzione. Queste sono istruzioni da eseguire: per scrivere questa pagina non sono state utilizzate installazioni di Hermes, istanze Ollama né il selettore.

Se la risposta è che il locale non vale la pena per questa attività, la questione economica si divide chiaramente in due: quanto costa il software e quanto costa l'uso del modello.

Il piano Pro di Ollama Cloud è inoltre indicato a $200 all'anno con fatturazione annuale e i suoi piani includono crediti mensili per l'uso: $60 per Pro, $300 per Max, $1.000 condivisi per Team. Questi riguardano il prodotto cloud, non l'endpoint locale che stai correggendo.

Per il percorso a consumo, ecco un calcolo illustrativo dei token, non un costo misurato dell'attività né un limite massimo della fattura. Supponi una sessione che invia 200.000 token di input non memorizzati nella cache e riceve 12.000 token di output, senza letture dalla cache e senza costi per strumenti esterni. Le tariffe sono i prezzi attuali del catalogo Kunavo per milione di token.

Scala il valore in base al numero delle tue sessioni giornaliere prima di considerarlo un budget e nota che la tariffa più bassa nell'elenco e il costo minimo per completare l'attività sono affermazioni diverse: un modello economico che richiede tre tentativi può costare più di uno che ne richiede uno. L'importo del catalogo Kunavo è una soglia di fatturazione, non un tetto massimo: quando l'upstream comunica il proprio addebito, la fattura è il maggiore tra il costo del catalogo e il costo upstream moltiplicato per il markup applicabile. Vedi i dettagli sulla fatturazione.

Quale percorso conviene dipende dal lavoro. Ollama locale conviene per attività piccole, private o offline senza costi per richiesta, con l'hardware e il minimo di 64.000 token come vincoli effettivi. Un'API diretta del provider conviene quando utilizzi il modello di punta di un singolo provider e vuoi usufruire della sua cache e delle sue condizioni per i batch. Un gateway conviene quando cambi modello in base all'attività e vuoi una sola chiave e un solo saldo. Un abbonamento conviene quando l'uso intenso quotidiano a tariffa fissa è più adatto a te dei token a consumo.

Indirizzare Hermes altrove

Se decidi di aggiungere un endpoint ospitato accanto a quello locale, la procedura è lo stesso flusso per i provider personalizzati; c'è però un limite che vale la pena conoscere prima di iniziare: l'aggiunta di un provider avviene con hermes model fuori da una sessione, perché durante una sessione /model passa da provider già configurati e non può aggiungerne uno né accettare una chiave. L'API personalizzata di Hermes Agent descrive in dettaglio la struttura della voce, i trasporti e il rollback; I prezzi di Hermes Agent descrivono le quattro fatture separate. Kunavo pubblica riferimenti di configurazione, non test di compatibilità: in questo lavoro Hermes non è mai stato testato in runtime con l'endpoint Kunavo, quindi nulla di quanto segue dimostra che la discovery di Hermes funzioni con esso. Mantieni operativo il percorso attuale mentre fai la prova. L'API compatibile con OpenAI di Ollama spiega perché lo stesso codice client raggiunge entrambi, e crea un account Kunavo quando vuoi finanziare una chiave.

Stai ancora scegliendo un client invece di eseguire il debug? Alternative a Hermes Agent e API compatibile con OpenAI coprono il panorama più ampio.

Domande frequenti

Cosa è stato verificato il 21 settembre 2026 e come: gli stati di issue e pull request, la presenza dei tag per entrambe le correzioni, il tag dell'ultima release e lo stato della licenza e dell'archiviazione del repository provengono dall'API di GitHub; le costanti della cache, la logica di abilitazione della discovery, l'archivio della visibilità desktop, la stringa di aiuto --refresh e le citazioni della documentazione sono state lette dal codice sorgente al tag v2026.9.21; la pagina dei prezzi di Ollama, la pagina di integrazione di Hermes di Ollama e l'elenco dei piani Nous Portal sono stati recuperati lo stesso giorno. Non è stato verificato se l'artefatto di aggiornamento automatico di pip, Homebrew, del container o dell'app desktop installato includa una delle due correzioni. Nulla di quanto riportato è stato testato in runtime: non è stata eseguita alcuna installazione di Hermes, non è stato avviato Ollama e non è stato aperto alcun selettore. Le tariffe dei token Kunavo provengono dal catalogo attuale e l'esempio in dollari è un calcolo illustrativo dei token, non un costo misurato dell'attività.