Hermes Ollama models not showing: catalog and provider checks

If your Ollama models have disappeared from the Hermes picker, check the version before you touch the config: the native-catalog cache bug that produces exactly this symptom was closed as completed on September 17, 2026, and its fix is contained in tag v2026.9.21 (hermes-agent 0.21.4) but not in v2026.9.14. That closed report is not the whole story, though. Two further reports of Ollama models missing from a picker were still open on September 21, 2026; a third open issue describes a Hermes Desktop mechanism that produces the same symptom on any provider whose visible-model list has ever been customized, and I read that behaviour still present in the shipped source at that same tag. A fourth common cause is not a defect at all. Each leaves a different tell, and the tells are what this page is for.

Two disambiguations first, because both collide in search results. Hermes Agent is the Python agent from Nous Research (MIT, not archived, last pushed September 21, 2026 per the GitHub API). Hermes 3 and Hermes 4 are that same lab's open-weight LLM family, a different product entirely, and there is also an unrelated JavaScript engine called Hermes — none of their version numbers apply here. And local Ollama is not Ollama Cloud: Hermes reaches the free local runtime on port 11434 through its Custom Endpoint flow, while Ollama Cloud is a separate paid product implemented as its own provider slug with its own cache file. A missing model in one says nothing about the other.

Three layers have to agree, and only one of them is Ollama

"The model is not in the picker" is a statement about the last of three layers, and the diagnosis is a matter of finding the first one that disagrees.

# 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'

One thing to rule out at layer one: ollama list includes embedding models, and an embedding model is not a chat model a coding agent can select. Kunavo serves no embedding, text-to-speech or speech-to-text model either, so that is not a gap a hosted route closes here.

Check your version first, and read it carefully

Issue #112898 — "local Ollama model list flickers in the picker" — is closed as completed, opened September 16, 2026 and closed September 17, 2026. Pull request #113129 merged the fix as commit d6d6565, and a GitHub compare places that commit inside tag v2026.9.21 and outside v2026.9.14: comparing v2026.9.21…d6d6565 returns status behind with zero commits ahead, so the commit is an ancestor of that tag, while v2026.9.14…d6d6565 returns status ahead with zero behind, so the tag is an ancestor of the commit rather than the other way round. The contributor's own #112900 is still open, which is not a sign the fix is missing from main: its content was cherry-picked with authorship into the merged pull request. All states read from the GitHub API on September 21, 2026.

Now the trap. Two different version numbers ship inside that one tag: at v2026.9.21, pyproject.toml reads version = "0.21.4" while apps/desktop/package.json reads "version": "0.17.6". A bug report headed "Hermes Desktop 0.17.6" is therefore describing a current build, not an old one — and dismissing such a report as stale will date your own evidence wrong. Note the limit of the version check, too: this is git containment in a tag. Whether the pip release, Homebrew formula, container image or desktop auto-update channel you actually installed carries that commit was not verified here.

Five causes, and the tell that separates them

Two of those deserve their own sentence. The desktop freeze is the one most likely to be misread as a cache problem: reading apps/desktop/src/store/model-visibility.ts at tag v2026.9.21, once a provider has any stored keys the renderer skips merging provider defaults entirely, so models discovered later never enter the menu. Issue #114369 reproduced exactly that on a custom provider with discover_models: true and was closed as a duplicate, not as fixed; its reproduction used a vLLM endpoint, so treat the mechanism as provider-agnostic rather than as an Ollama repro. Two more remain open and unresolved: #89874 (zero models for a custom Ollama provider, carrying a needs-repro label, so an unconfirmed report rather than an established defect) and #71169 (models present in the Ollama API, absent from the desktop dropdown). Whether either shares a root cause with #112898 is not established.

The desktop symptom is also sharper than people expect. In model-catalog-menu.tsx at that tag, a provider whose collapsed family list is empty is skipped outright — which is why the complaint is usually "my provider disappeared" rather than "my provider shows an empty list".

Why a normal picker open shows you a stale list

This is the mechanism under the whole failure class, and it is worth understanding once. On a plain picker open, only the current custom endpoint is probed live; every other configured endpoint is answered from the disk cache at $HERMES_HOME/provider_models_cache.json. HERMES_HOME defaults to ~/.hermes but is overridable, so do not assume the path. Three windows in hermes_cli at tag v2026.9.21 govern re-probing:

These are internal source constants rather than documented settings; no user-facing knob for these three turned up in this check. One deliberate exception in that code is worth knowing: an empty native catalog counts as authoritative only inside the short TTL and is never stale-served, precisely so an Ollama that had no models at first open does not hide a freshly pulled one for the whole seven-day window. And cache rows are keyed on the normalized URL plus a fingerprint of the credential, API mode and extra headers, because several provider rows can legitimately share one proxy URL with different keys. The practical consequence: rotating a key, changing the transport or editing extra_headers invalidates that row's cache entry, and the next no-probe open renders it empty until something refreshes it.

The checks, in order

1. Confirm Ollama has it. Run the two curls above. If /api/tags does not list the model, nothing downstream can.
2. Confirm the version. If you are on a build older than tag v2026.9.21 and the symptom is a list that flickers between correct and empty, you are looking at a bug that is already fixed — upgrade before debugging.
3. Force a refresh. The --refresh flag on hermes model states in its own help text that it wipes the picker disk cache and re-fetches every provider's live listing; note that it clears every provider, not one. In-session, the slash-commands reference documents /model --refresh as re-fetching the provider's model list, and the desktop has an explicit "Refresh Models" control that requests a fresh catalog while normal opens stay on the hour cache.
4. Check which probe path your endpoint gets. The native /api/tags branch is taken when the provider is named ollama, when the name is custom:ollama or ends in -ollama, when the URL matches the configured Ollama base URL, or when an ambiguous custom URL on port 11434 actually answers /api/tags. An Ollama served on another port under a plain custom name falls through to the generic /v1/models probe instead — that is what the code path reads as doing, and it was not run here to confirm the fallback works in practice.
5. If discovery itself is the problem, stop discovering. discover_models defaults to true; setting it false makes the picker show the list you configured instead of a live probe.
6. If only the desktop menu is wrong, you are most likely in #107391 territory, which no refresh clears — the backend returns the model and the renderer's curation layer drops it.

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

One configuration detail trips people repeatedly, and it is worth settling. The reference documents api as the base-URL key for a providers: entry, and its field list for that entry names base_url and url as accepted aliases for it; base_url is separately the key under the top-level model: mapping. It also records that older configs used a top-level custom_providers: list with base_url instead of api, still working and auto-migrated on hermes update at config v12. Bug reports in the tracker are written both ways, which is what you would expect when both are read. So a providers: entry that is not taking effect is unlikely to be failing on the name of this key — look at the endpoint and the entry's other fields.

A separate detail worth naming: Ollama's own Hermes page walks through the setup prompt as "Context length in tokens [leave blank for auto-detect]", while Hermes' provider documentation requires at least 64,000 tokens for agent use and says a local endpoint serving less is refused at startup. Both checked September 21, 2026. Leaving the field blank is not itself wrong, but it does nothing about a server that only serves a small window — so raise the window on the server (or pin it in Hermes' config) to Hermes' number, and remember that this failure produces a startup refusal naming the served window, not a missing picker row.

Verify it, then decide whether local is worth it

After a change, do three things in order: reopen the picker without --refresh and confirm the model is listed on a cold open, select it, and send one bounded request that returns a completion. The middle step matters because a list that is only correct immediately after a probe is the signature of the cache bug rather than a fix. These are instructions for you to run — no Hermes installation, Ollama instance or picker was exercised in writing this page.

If the answer is that local is not worth the trouble for this task, the money question splits cleanly in two: what the software costs, and what model usage costs.

Ollama Cloud's Pro tier is also listed at $200 per year billed annually, and its plans include monthly usage credits — $60 on Pro, $300 on Max, $1,000 shared on Team. Those belong to the cloud product, not to the local endpoint you are fixing.

For the metered route, here is illustrative token arithmetic, not a measured task cost and not a bill ceiling. Assume one session that sends 200,000 uncached input tokens and receives 12,000 output tokens, with no cache reads and no external tool charges. Rates are live Kunavo catalog prices per million tokens.

Scale by your own sessions per day before treating that as a budget, and note that cheapest listed rate and lowest cost to finish the task are different claims — a cheap model that needs three attempts can cost more than one that needs one. Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. See billing details.

Which route wins depends on the work. Local Ollama wins for small, private or offline tasks at no per-request charge, with hardware and the 64,000-token minimum as the real constraints. A direct vendor API wins when you live in one vendor's flagship and want its own caching and batch terms. A gateway wins when you switch models per task and want one key and one balance. A subscription wins when flat-rate heavy daily use suits you better than metered tokens.

Pointing Hermes somewhere else

If you decide to add a hosted endpoint beside the local one, the mechanics are the same custom-provider flow — and one boundary is worth knowing before you try: adding a provider happens in hermes model run outside a session, because in-session /model switches between already-configured providers and cannot add one or accept a key. Hermes Agent custom API covers the entry shape, transports and rollback in detail; Hermes Agent pricing covers the four separate bills. Kunavo publishes configuration references rather than compatibility tests: Hermes has never been runtime-tested against Kunavo's endpoint in this work, so nothing here establishes that Hermes' discovery succeeds against it. Keep your working route in place while you try. Ollama's OpenAI-compatible API explains why the same client code reaches both, and create a Kunavo account when you want to fund a key.

Still choosing a client rather than debugging one? Hermes Agent alternatives and OpenAI-compatible API cover the wider field.

FAQ

What was checked on September 21, 2026, and how: issue and pull-request states, tag containment for both fixes, the latest release tag and the repository's licence and archive status came from the GitHub API; the cache constants, the discovery gating, the desktop visibility store, the --refresh help string and the documentation quotes were read from source at tag v2026.9.21; Ollama's pricing page, Ollama's own Hermes integration page and the Nous Portal plan list were fetched the same day. Not checked: whether the pip, Homebrew, container or desktop auto-update artefact you installed carries either fix. Nothing here was runtime tested — no Hermes install was run, no Ollama started and no picker opened. Kunavo token rates come from the live catalog, and the dollar example is illustrative token arithmetic rather than a measured task cost.