[FIX] Hermes AI Desktop – “No LLM provider configured” When Ollama Works in the CLI

Have you configured Hermes Agent to use a local Ollama model, confirmed that it works from the command line, only for Hermes Desktop to present you with the following rather unhelpful error?

No LLM provider configured. Run `hermes model` to select a provider,
or run `hermes setup` for first-time configuration.

You may also receive a variation along these lines:

Unknown provider 'custom:ollama---gemma-4-12b'.

If so, all may not be lost. More importantly, your Ollama installation and local model may be perfectly fine.

I recently ran into this exact problem whilst configuring Hermes Desktop to use a Gemma 4 model running locally through Ollama. The model appeared in the Desktop model picker, the Hermes backend could see it, and the Hermes CLI could even get a response from it. Yet Desktop still insisted that there was no LLM provider configured.

As it turned out, the problem was not Ollama, Docker networking or the model. It was the way the provider configuration was scoped to a separate Hermes profile, combined with provider information already stored against the Desktop session.

This post explains how I tracked it down, how I fixed it without deleting my Hermes data, and the checks I used to make sure the fix survived a Desktop restart.

Tested configuration: Hermes Desktop source/development build v0.20.6, Hermes backend v0.20.6 in Docker, macOS, Ollama and gemma4:12b. This is the configuration on which I reproduced, repaired and restart-tested the problem; the menus, file paths and behaviour may change in later Hermes releases.

My Hermes and Ollama Setup

Before getting into the fix, it is worth briefly explaining how my installation is arranged. This matters because localhost does not always mean what you might expect once Docker becomes involved.

My setup consists of:

• Hermes Desktop running as the source-built Electron application on my Mac.
• The Hermes backend and gateway running inside a Docker container.
• Ollama running natively on macOS, with gemma4:12b installed locally.
• Hermes profiles named default and local, each with its own configuration and session data.

The request path therefore looks like this:

Hermes Desktop on macOS
        ↓
Hermes backend inside Docker
        ↓
Ollama on the Mac host
        ↓
gemma4:12b

I chose this arrangement because it keeps Hermes and its dependencies contained inside Docker, making the backend easier to manage or replace without cluttering the Mac installation. Ollama remains on macOS so it can run the local models directly on the host and make use of the Mac’s hardware. The gemma4:12b tag used here is also listed in the official Ollama Gemma 4 library.

There is one important consequence: from inside the Hermes container, localhost refers to the container itself rather than the Mac. Docker Desktop’s own networking guidance recommends the special host.docker.internal address when a container needs to reach a service on the host. Hermes therefore reaches Ollama using:

http://host.docker.internal:11434/v1

If you installed both Hermes and Ollama directly on the same machine without Docker, your endpoint may instead be http://localhost:11434/v1. That is the base URL shown in Ollama’s official OpenAI-compatibility examples. The profile problem described below can affect either arrangement, though the correct endpoint will be different.

Why I Am Running the Pre-Release Hermes Desktop

You may be wondering why I am using a source-built version of Hermes Desktop rather than simply downloading the normal Mac installer.

At the time of writing, the downloadable macOS installer follows a local-first setup path. If it cannot find Hermes locally, it offers to install the complete Hermes runtime, including the supporting command-line components and dependencies.

That makes sense for somebody starting with a blank Mac. It did not make sense for me because I already had a fully configured Hermes backend running inside Docker. I did not want a second Hermes installation with another set of configuration files, providers and sessions merely to obtain the Desktop interface.

What I wanted was closer to a thin client:

Hermes Desktop interface only
        ↓
Connect to my existing Hermes backend in Docker

The newer Hermes Desktop documentation now supports this. Under Settings → Gateways, its Remote gateway connection mode can point the interface at an existing hermes serve backend instead of starting and managing another local backend.

In this context, “remote” does not have to mean a server in another building—or even another physical computer. My Hermes backend is in a Docker container on the same Mac, but it is still a separate service which Desktop reaches through a network address.

The slight complication is that this capability reached the current Hermes source after the publicly downloadable Mac installer was built. Hermes issue #85422 documents that release mismatch: the public installer still pushes new users through local bootstrap, whilst the newer source contains the Connect to existing Hermes path.

I therefore built and ran the current Desktop code from source. It is reasonable to call this a pre-release or development build: it contains newer Desktop functionality, though it has not gone through the same packaged, signed and branded release process as the normal download. That distinction is worth remembering because development builds may also contain unfinished changes or new bugs.

Why Does It Appear as Electron on the Mac?

Electron is the framework used to build the Hermes Desktop interface. It packages web technologies—HTML, CSS and JavaScript—inside a desktop application using Chromium and Node.js. Applications such as Visual Studio Code, Slack and GitHub Desktop use the same general approach.

When an Electron application is prepared for normal distribution, it is packaged and branded with the product’s name, icon and macOS application details. When it is launched directly from source during development, some of that final packaging is absent. macOS can therefore show the generic name Electron in places such as Activity Monitor or the Dock.

/imag

So, in my setup, the process called Electron really is the running Hermes Desktop interface. It is not a second AI model, a replacement for Docker or evidence that Hermes has stopped. Electron is simply the desktop shell displaying the Hermes user interface and connecting it to my existing Dockerised backend.

The Short Answer

If Hermes CLI works with Ollama but Hermes Desktop does not, check which Hermes profile owns the failing Desktop session.

Hermes describes a profile as a separate Hermes home. Each profile has its own:

• config.yaml
• environment and credentials
• sessions
• logs
• state.db database

A provider configured in the default file at ~/.hermes/config.yaml is not automatically available to a separate profile stored under ~/.hermes/profiles/<profile-name>/. This separation is documented in the official Hermes profiles guide.

In my case, the working Ollama provider existed in the default configuration, but the failing sessions belonged to a profile called local. That profile still had a different model configuration and did not contain the named Ollama provider that Desktop had saved with the session.

The fix was to add the working Ollama model and matching custom-provider definition to the local profile’s own config.yaml. I did not change the already-working root configuration, delete the Desktop cache or edit the session database.

Why This Problem Is So Confusing

There were several clues suggesting that everything should have worked:

1. Ollama was running on the Mac.
2. The Gemma model was installed and available.
3. The Hermes Docker container could reach Ollama.
4. Hermes CLI could initialise the agent and get a response.
5. Hermes Desktop showed the model in its picker.

Normally, if the CLI and Desktop are using the same backend and configuration, you would expect them to behave in the same way. In this instance they were not using quite the same state.

The easiest way to think about a Hermes profile is as a separate Hermes home. It may use the same application and gateway, but it has its own configuration and its own session history. Pointing Desktop at a profile does not make that profile inherit everything from the default one.

Desktop had remembered a provider identity similar to:

custom:ollama---gemma-4-12b

That identity was valid only if the profile which owned the session also had the matching named custom provider. Mine did not, so Desktop could display the model whilst the backend was unable to build a working runtime for it.

There are related reports in the Hermes issue tracker where custom-provider identity is lost or cannot be reconstructed when Desktop resumes a session. In those reports, the CLI continues to work because it follows the configured default-provider path rather than the same Desktop session-restoration path.

Before You Change Anything: Make a Backup

I would strongly recommend making a backup before clearing caches, changing a profile or touching a database. Repeatedly changing the main Ollama configuration can make the original problem harder to see, especially when that configuration already works.

First, completely quit Hermes Desktop. If you are running the source-built Electron version, it may appear in macOS as Electron rather than Hermes, so check that it has really closed.

Open Terminal and create a timestamped backup folder:

backup_dir="$HOME/Documents/hermes-repair-backup-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup_dir"

Back up the Hermes Desktop Electron data:

ditto "$HOME/Library/Application Support/Hermes" \
  "$backup_dir/Hermes-Desktop"

If your affected profile is called local, back up its configuration:

cp "$HOME/.hermes/profiles/local/config.yaml" \
  "$backup_dir/local-config.yaml"

You can also ask SQLite to make a consistent backup of the profile’s session database:

sqlite3 "$HOME/.hermes/profiles/local/state.db" \
  ".backup '$backup_dir/local-state.db'"

Change local in these paths if your profile has a different name.

Important: Do not publish or casually share your .env, auth.json, OAuth tokens, dashboard secrets or complete Hermes data directory. These can contain credentials and private conversation data.

With that out of the way… on with the troubleshooting!

Step 1 – Prove That Ollama and the Hermes Backend Work

Before digging into Desktop storage, test the actual model through Hermes CLI.

For my Docker container, which was named hermes, I used the following. Replace the first hermes if your container has a different name:

docker exec -it hermes hermes chat \
  -q "Reply with exactly: LOCAL MODEL WORKING" \
  --max-turns 1

The important result was:

LOCAL MODEL WORKING

This is a useful dividing line:

• If the CLI also fails, you probably still have an Ollama, Docker networking or main Hermes provider problem.
• If the CLI works but Desktop fails, stop changing Ollama for the moment. Concentrate on Desktop, profiles and session restoration.

In my case, this test proved the complete path from Hermes to Docker, Ollama and Gemma was working.

Step 2 – Check Which Profile Owns the Session

Open Hermes Desktop and look at the Profiles section in the left sidebar. In my setup I had both default and local profiles available through the gateway.

The broken sessions belonged to local, not default.

This small distinction was the key to the whole problem. I had been checking the working configuration here:

~/.hermes/config.yaml

But the failing session was resolved using:

~/.hermes/profiles/local/config.yaml

Those are independent configuration files.

If you created a profile using a blank profile rather than cloning an existing one, this is particularly worth checking. The Hermes documentation confirms that each profile has its own config, credentials, sessions and state./image

Step 3 – Compare the Model and Provider Configuration

You can use the following command to print only the most relevant model/provider lines from the default configuration:

grep -nE '^[[:space:]]*(model:|custom_providers:|default:|provider:|base_url:|api_mode:|- name:)' \
  "$HOME/.hermes/config.yaml"

Now compare it with the profile configuration:

grep -nE '^[[:space:]]*(model:|custom_providers:|default:|provider:|base_url:|api_mode:|- name:)' \
  "$HOME/.hermes/profiles/local/config.yaml"

My default configuration correctly contained the Ollama endpoint:

model:
  default: gemma4:12b
  provider: custom
  base_url: http://host.docker.internal:11434/v1
  api_mode: chat_completions

It also had the named custom provider:

custom_providers:
  - name: Ollama - Gemma 4 12B
    base_url: http://host.docker.internal:11434/v1
    model: gemma4:12b
    api_mode: chat_completions

The local profile, however, still selected GPT/Codex and had no corresponding Ollama provider definition.

Desktop had saved custom:ollama---gemma-4-12b with the sessions in that profile, but the profile had no way to resolve it. In this v0.20.6 installation, the three hyphens came from the normalised display name Ollama - Gemma 4 12B; the spaces surrounding the existing hyphen became additional hyphens. Treat the exact spelling as version- and configuration-specific rather than typing it blindly into another installation.

The configuration shape itself is supported by Hermes: its custom and self-hosted provider documentation describes provider: custom, a base_url ending in /v1, named custom_providers entries and api_mode: chat_completions for OpenAI-compatible endpoints. Ollama’s OpenAI compatibility documentation confirms that it implements /v1/chat/completions on port 11434.

Optional Deep-Dive – Inspect the Stored Session Provider

You do not normally need to edit the database, though a read-only query can help confirm what Desktop saved. Hermes documents state.db as its SQLite session store, including the model and model_config fields used here.

With Hermes Desktop closed, run:

sqlite3 -header -column \
  "file:$HOME/.hermes/profiles/local/state.db?mode=ro&immutable=1" \
  "SELECT id, model, model_config FROM sessions ORDER BY started_at DESC LIMIT 10;"

In my affected sessions, model_config contained a provider similar to:

{
  "model": "gemma4:12b",
  "provider": "custom:ollama---gemma-4-12b"
}

That does not mean the database itself is corrupt. It means the session expects its owning profile to be able to resolve that provider identity.

If the recent session is missing from the query, it may still be in SQLite’s write-ahead log. Do not start copying or deleting database files at random; make a proper backup and close the processes using the database first.

Step 4 – Apply the Correct Fix for Your Profile

There are two likely situations here.

The profile is supposed to use Ollama

This was my situation. I added the working Ollama model and provider to the local profile’s own config.yaml.

The model section became:

model:
  default: gemma4:12b
  provider: custom
  base_url: http://host.docker.internal:11434/v1
  api_mode: chat_completions

I also added the named provider expected by the stored Desktop sessions:

custom_providers:
  - name: Ollama - Gemma 4 12B
    base_url: http://host.docker.internal:11434/v1
    model: gemma4:12b
    api_mode: chat_completions
    models:
      gemma4:12b: {}
      gemma4:26b: {}
    models_discovered: true

The models catalogue and models_discovered flag above were present in the known-working provider entry copied from my default profile. They preserve the exact configuration I tested, but they were not the central part of the repair. The essential point was that the local profile gained the matching named provider, endpoint, model and API mode. For a new installation, Hermes recommends using hermes model to create a custom endpoint rather than inventing discovery metadata by hand.

If Ollama runs directly on the same non-containerised machine as Hermes, your URL may instead be:

http://localhost:11434/v1

In my setup Hermes ran inside Docker, so localhost would have meant the container itself. I therefore needed:

http://host.docker.internal:11434/v1

Do not blindly copy that URL without considering where Hermes and Ollama are running.

Also make sure the provider name matches the identity already stored with the session. Renaming a provider may be tidier for future sessions, but it will not necessarily repair an older session that expects the previous name.

The profile is not supposed to use Ollama

Do not overwrite a cloud or work profile just to make an accidentally selected Ollama session run.

Instead, switch Desktop to the profile which actually owns the Ollama configuration and create a new session there. A visible model selection is not proof that the active profile can execute it.

Step 5 – Test a Brand-New Desktop Session

Reopen Hermes Desktop, select the repaired profile and start a completely new session.

The model indicator in my session showed:

custom: gemma4:12b

I sent:

Reply with exactly: LOCAL MODEL WORKING

Gemma returned:

LOCAL MODEL WORKING

The first response took 48 seconds because the local model needed time to load and begin generating. The important part was that Hermes had moved beyond the provider-initialisation error and was now waiting on gemma4:12b.

Step 6 – Make Sure Session Restore Is Fixed

Do not stop at a successful new chat. Session restoration was the path that had caused trouble, so I wanted to test that specifically.

I completely quit Electron/Hermes Desktop, relaunched it, selected the local profile and reopened the exact session that had just worked.

I then sent:

Reply with exactly: RELOAD WORKING

The restored session returned:

RELOAD WORKING

This was the decisive test. It proved that the provider could be reconstructed from the persisted session after Desktop restarted, not merely used by an agent which happened to be left running in memory.

Why I Am Confident This Was the Correct Fix

There is an important difference between a plausible workaround and a fix which has been isolated and tested.

In this case I changed only the affected local profile’s configuration. I deliberately left the working root configuration, Ollama installation, Docker container, Electron storage and session database untouched.

The evidence then fell into a useful sequence:

1. The CLI returned LOCAL MODEL WORKING before the Desktop repair, proving that the Docker-to-Ollama route and model were already functional.
2. Inspection showed that the failing Desktop sessions belonged to local, whilst the working provider configuration existed under the default Hermes home.
3. The affected session expected custom:ollama---gemma-4-12b, but its owning profile did not define that named provider.
4. Adding the matching endpoint and provider to the owning profile allowed a brand-new Desktop session to return LOCAL MODEL WORKING.
5. After completely quitting and relaunching Electron, the exact same session returned RELOAD WORKING.

That final restart test is particularly important. It exercises the persisted session/provider reconstruction path rather than merely proving that an already-running process retained some temporary state.

The official documentation independently supports each underlying part of the diagnosis: profiles have separate homes, custom providers are resolved from configuration, Ollama exposes an OpenAI-compatible chat endpoint, and Docker Desktop uses host.docker.internal to reach services on the Mac host. Related Hermes issues also document the same general failure family around Desktop session restoration and named custom-provider identity.

This does not mean every occurrence of No LLM provider configured has the same cause. It does mean that, for the configuration described in this article, the repair is supported by both the observed state and two successful end-to-end tests, including a full Desktop restart.

What I Did Not Need to Change

It is just as useful to record what was left alone:

• I did not change the working root ~/.hermes/config.yaml.
• I did not reinstall Ollama or re-download the Gemma model.
• I did not recreate the Docker container.
• I did not delete the Hermes Desktop LevelDB directory.
• I did not edit or replace the Hermes session database.
• I did not remove my OAuth/Codex authentication.

Clearing all Electron storage can be a useful last-resort test for stale UI state, though in this case it would have treated the symptom rather than the profile mismatch. Repairing the profile allowed Hermes to retain the existing conversations and resolve the provider correctly.

Quick Troubleshooting Table

Is This a Hermes Bug or a Configuration Problem?

In my particular setup it was a combination of the two.

The immediate repair was configuration-related: the separate local profile did not contain the provider expected by its sessions. However, Desktop made the situation difficult to understand because it could show and persist a provider selection that the owning profile could not successfully resolve.

This is not entirely unique. Hermes issue #44022 documents Desktop/TUI session restoration failing with No LLM provider configured whilst the same custom provider works through the CLI. Issue #44108 describes named custom-provider identity being reduced to bare custom during persistence, and issue #7054 covers differences between the provider catalogue/picker and runtime configuration paths.

Some related issues are now closed, though an issue’s status alone does not prove that every release and every stored session has been repaired. I would not assume every current Hermes installation has exactly the same fault. The useful diagnostic lesson remains the same: when CLI works and Desktop fails, verify the profile and session boundary before rebuilding your local AI stack.

Frequently Asked Questions

Why does Hermes CLI work when Hermes Desktop fails?

The CLI may use the default profile and its configured provider directly. Desktop can use a different profile and may also restore provider information saved with a particular session. If those sources disagree, CLI can work whilst Desktop fails.

Does a Hermes profile inherit the default config.yaml?

No. A profile has its own Hermes home containing its own configuration, credentials, sessions, logs and state database. Configure or clone the provider into the profile which will use it.

Why does Hermes say custom:ollama---gemma-4-12b?

In this tested v0.20.6 session, Hermes created a normalised identity for the named custom provider. The spaces in Ollama - Gemma 4 12B became hyphens alongside the hyphen already present in the display name. Treat that exact identity as evidence from this installation; its format may differ with another provider name or Hermes version.

Should I delete ~/Library/Application Support/Hermes?

Not as a first step. Back it up, identify the active profile and compare the profile’s provider configuration first. Deleting Desktop state may remove useful evidence and does not repair a missing provider definition inside a Hermes profile.

Should I edit state.db?

Usually not. Querying it read-only can help diagnose the stored provider, but repair the owning profile configuration first. Direct database changes should be a carefully backed-up last resort.

Which Ollama URL should I use with Hermes?

If Hermes runs directly on the same machine, it may use http://localhost:11434/v1. If Hermes runs inside Docker and Ollama runs on the Mac host, http://host.docker.internal:11434/v1 is normally the relevant address.

Final Thoughts

This was one of those problems where all the individual pieces appeared to be working, though the complete Desktop session still failed. The biggest clue was that the same model and backend worked from Hermes CLI.

Once I stopped changing Ollama and followed the session into its owning profile, the cause became much clearer: the model was configured in one Hermes home, whilst the failing Desktop session belonged to another.

If you run into this error, back everything up, confirm the CLI path, check the active profile, and compare that profile’s provider definition with the provider stored in the session. Hopefully that will save you some of the head-scratching I went through. 🙂

If you have seen a variation of this problem on Windows, Linux, or a newer Hermes release, leave a comment with your Desktop version, backend version and profile layout. It will no doubt help others who come across the same rather misleading error.

Hope this guide helps. Good luck!

Useful References

• Hermes Agent profiles documentation
• Hermes Desktop documentation, including remote-backend mode
• Hermes custom and self-hosted provider documentation
• Hermes session-storage documentation
• Hermes issue #85422 – downloadable macOS installer predates remote-client onboarding
• Hermes issue #38602 – Desktop client-only installation
• Hermes issue #44022 – Desktop/TUI session resume and bare custom-provider state
• Hermes issue #44108 – named custom-provider identity lost during Desktop/TUI persistence
• Hermes issue #7054 – provider picker and runtime configuration-path differences
• Docker Desktop networking – connecting a container to a host service
• Ollama OpenAI compatibility documentation
• Ollama Gemma 4 model library
• Electron introduction
• Electron application packaging and rebranding