Cleaning Noise from provider spam in Session Chat Controls | Friends of the Crustacean 🦞🤝 | Page 1

jaunty sky Apr 15, 2026, 6:14 PM

#

I only have Ollama to use, and I was hoping to make use of the autodetect for model testing but lo and behold when I try to switch models on the fly,

My ollama models are disorganized in the dropdown, and
every provider under the sun is in the list, and it will break my setup if any of them get picked.

I've set model mode to replace,
"models": {
"mode": "replace",
"providers": {
"ollama": {

but i'm still getting everything that could exist coming through.

ornate dragonBOT Apr 15, 2026, 6:16 PM

#

Yep, models.mode: "replace" is the wrong knob for this.

It only controls how models.providers rewrites models.json. It does not limit what shows up in /model or the Discord picker.

The picker is filtered by agents.defaults.models, which acts as the allowlist.

{
  agents: {
    defaults: {
      model: { primary: "ollama/gemma4" },
      models: {
        "ollama/gemma4": { alias: "Gemma 4" },
        "ollama/qwen3:8b": { alias: "Qwen 3 8B" },
        "ollama/llama3.2:3b": { alias: "Llama 3.2 3B" },
      },

#

    },
  },
}

Fastest way to set it is:

openclaw configure --section model

That wizard has a multi-select for the /model allowlist.

One important Ollama gotcha, if you want auto-discovery, do not define an explicit models.providers.ollama entry unless you want to manage the model list manually. Explicit Ollama provider config disables auto-discovery.

For the “disorganized” ordering, I don’t see a config knob for custom sort order right now. The catalog is sorted automatically, so the practical fix is usually to shrink it to just your Ollama allowlist.

#

Can you paste openclaw --version too? If you still see every provider after setting agents.defaults.models, that’s the next thing I’d check.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/cli/configure
https://docs.openclaw.ai/providers/ollama

jaunty sky Apr 15, 2026, 6:29 PM

#

"agents": {
"defaults": {
"model": { primary: "ollama/gemma4"}
"workspace": "/home/bob/.openclaw/workspace",
"memorySearch": {
"enabled": true
},
"models": {
"ollama/gemma4": {}
}
},
"list": [
{
"id": "main",
"tools": {
"profile": "full"
}
}
]
},

openclaw --version
OpenClaw 2026.4.14 (323493f)

Still showing

ornate dragonBOT Apr 15, 2026, 6:31 PM

#

Huh, on 2026.4.14 that should be filtering already.

A couple things to check:

Assuming the missing comma after "ollama/gemma4" was just paste damage, confirm OpenClaw is actually reading the allowlist:

openclaw config get agents.defaults.models
openclaw models list

Expected:

config get shows only ollama/gemma4
models list also only shows that allowlisted model

If you edited the config file directly, restart once to rule out stale state:

#

openclaw gateway restart

How to interpret the results

If openclaw models list shows only ollama/gemma4, but Discord /model still shows every provider, that smells like a Discord picker bug.
If openclaw models list still shows everything, then the allowlist is not being applied, usually wrong config file, invalid JSON5, or old state.

One more Ollama gotcha, if you want autodiscovery, don’t keep an explicit models.providers.ollama block unless you want to manage the model catalog manually. The Ollama docs call out that explicit provider config disables autodiscovery.

If you want, paste the output of:

openclaw config get agents.defaults.models
openclaw models list

#

and I can tell you in one pass whether this is config or a real bug.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/providers/ollama

jaunty sky Apr 15, 2026, 6:47 PM

#

config invalid
File: ~/.openclaw/openclaw.json
Problem:

models.providers.ollama.models: Invalid input: expected array, received undefined

ornate dragonBOT Apr 15, 2026, 6:48 PM

#

Yep, that error is the smoking gun.

Your config is invalid because once you define models.providers.ollama, OpenClaw expects:

models.providers.ollama.models

to be an array.

Best fix, if you want autodetect

Remove the entire models.providers.ollama block and keep just the allowlist:

#

  agents: {
    defaults: {
      model: { primary: "ollama/gemma4" },
      models: {
        "ollama/gemma4": {},
      },
    },
  },
}

Then make sure Ollama auth is present, any placeholder value works:

export OLLAMA_API_KEY="ollama-local"

#

openclaw gateway restart
openclaw models list

If you want an explicit Ollama provider block

Then it needs models: [] at minimum:

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        api: "ollama",

#

        models: [],
      },
    },
  },
}

Also, for Ollama use the native URL, no /v1.

What I’d do here

Since you want autodetect + only Ollama in /model:

remove models.providers.ollama
keep agents.defaults.models
set OLLAMA_API_KEY

#

restart gateway
run openclaw models list

If openclaw models list still shows every provider after that, paste that output, because then I’d call it a real bug.

Docs:
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/concepts/models

jaunty sky Apr 15, 2026, 7:04 PM

#

that did work, but I wanna make sure, that only is going to list things ollama has loaded on an ollama PS call?

ornate dragonBOT Apr 15, 2026, 7:04 PM

#

Not ollama ps, no.

ollama ps is only the models currently loaded/running.

OpenClaw’s Ollama autodiscovery is based on what Ollama reports in its model catalog, so think ollama list, not ollama ps.

So the rough rule is:

ollama ps = currently in memory
ollama list = installed/pulled locally
OpenClaw autodetect = closer to ollama list

One small gotcha, if you explicitly put a model in agents.defaults.models, OpenClaw can still show that configured model even if it is not currently loaded.

So in your setup, with:

#

"models": {
  "ollama/gemma4": {}
}

you’re basically pinning the picker to that model, not to whatever happens to be active in ollama ps.

Docs: https://docs.openclaw.ai/providers/ollama

Glad we caught it 🙂

jaunty sky Apr 15, 2026, 7:06 PM

#

i removed that. maybe they are being removed via "models": {
"ollama/gemma4": {}
}

#

"models": {
"mode": "replace",
"providers": {
"ollama": {
"baseUrl": "http://labratory:11434",
"api": "ollama",
"models": [],
"apiKey": "OLLAMA_API_KEY"
}
}
},

ornate dragonBOT Apr 15, 2026, 7:06 PM

#

Yep, exactly.

That block:

agents: {
  defaults: {
    models: {
      "ollama/gemma4": {}
    }
  }
}

is the /model allowlist.

So with only that entry, the picker hides everything except ollama/gemma4.

#

A few rules of thumb:

one entry = only that model shows
multiple ollama/... entries = only those Ollama models show
remove agents.defaults.models entirely = picker falls back to the full discovered catalog

So if your goal is “show all Ollama models, but no non-Ollama models”, I don’t think there’s a provider-only filter knob right now. The current filter is model-by-model.

If you want, I can help you build a clean multi-model Ollama allowlist from your local model list.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person 🙂

#

Yep, that config looks sane now.

A few important bits:

baseUrl: "http://labratory:11434" is good, no /v1
api: "ollama" is correct
models: [] makes the provider entry valid
that block tells OpenClaw where to discover Ollama models from

Then this separate block still decides what /model shows:

agents: {
  defaults: {
    models: {
      "ollama/gemma4": {}

#

    }
  }
}

So the split is:

models.providers.ollama = discovery source / provider config
agents.defaults.models = picker allowlist

If you remove the allowlist, it should show the discovered model catalog from that remote Ollama host, basically closer to ollama list on labratory, not ollama ps.

If you keep the allowlist with only ollama/gemma4, then only that one shows, even if discovery finds more.

So yes, your current provider block is fine. The thing hiding the rest is the allowlist.

jaunty sky Apr 15, 2026, 7:10 PM

#

no, i fat fingered and you are misunderstanding. I've removed the model list. I only have gemma4 assigned as a default. the conversation is in qwen3.5 ollama is running but no models are in memory. I only see qwen3.5 and gemma4 while I have numerous other models downloaded. Is this due to "models": {
"mode": "replace",
"providers": {

ornate dragonBOT Apr 15, 2026, 7:11 PM

#

Ah, yep, that makes sense now.

This is not because the models aren’t in memory, and it’s not really mode: "replace" by itself.

It’s because you have an explicit remote Ollama provider here:

models: {
  mode: "replace",
  providers: {
    ollama: {
      baseUrl: "http://labratory:11434",
      api: "ollama",
      models: [],
      apiKey: "OLLAMA_API_KEY"
    }

#

}
}

Per the Ollama docs, once models.providers.ollama is set explicitly, auto-discovery is skipped. For a non-local host/port, that means you need to define the models manually.

So the behavior you’re seeing fits:

gemma4 = your configured default
qwen3.5 = current session/conversation model
other downloaded Ollama models on labratory = not auto-discovered

So yes, the explicit models.providers.ollama block is the reason.

Your options

#

Local Ollama + autodiscovery
- remove models.providers.ollama
- use local 127.0.0.1:11434
- OpenClaw discovers models automatically
Remote Ollama (labratory)
- keep models.providers.ollama
- manually populate models.providers.ollama.models

If you want, paste the ollama list output from that remote box and I’ll turn it into the exact models.providers.ollama.models JSON5 block for you.

Docs: https://docs.openclaw.ai/providers/ollama

jaunty sky Apr 15, 2026, 7:12 PM

#

okay no back up....

the ONLY way autodiscovery works is if ollama is running on the same machine as openclaw?

ornate dragonBOT Apr 15, 2026, 7:13 PM

#

On the current docs, yes.

Ollama autodiscovery is local-only:

OpenClaw + Ollama on the same machine
Ollama at the implicit local endpoint, basically http://127.0.0.1:11434
no explicit models.providers.ollama block

If Ollama is on another host, like http://labratory:11434, then you’re in explicit provider mode, and today that means manual model entries under models.providers.ollama.models.

So the short version is:

same machine = autodiscovery
remote machine = manual model list

Docs: https://docs.openclaw.ai/providers/ollama

#

If that cleared it up, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for future folks.

jaunty sky Apr 15, 2026, 7:13 PM

#

why is that broken?

ornate dragonBOT Apr 15, 2026, 7:13 PM

#

Honestly, I think “broken” is a fair reaction 😅

From the docs, it looks intentional, but it’s a pretty rough limitation:

implicit Ollama = local-only, autodiscovery on
explicit Ollama config = remote/custom host, autodiscovery off

So once you point OpenClaw at a custom baseUrl, it stops treating Ollama like the easy local path and starts treating it like a manually-defined provider.

Why they drew the line there, I can only infer, but it’s probably some mix of:

keeping the “local Ollama just works” path simple
not auto-probing arbitrary remote hosts by default
expecting remote/custom providers to have a stable manual catalog

That said, for real users it definitely feels wrong. “Remote Ollama, but still autodiscover models” is a pretty reasonable expectation.

If you want that behavior, I’d call it a feature request / UX gap and file it here:

#

https://github.com/openclaw/openclaw/issues

If you want, I can help you phrase a tight issue report so it’s easy for maintainers to act on.

jaunty sky Apr 15, 2026, 7:14 PM

#

i'd rather you point me to where it exists in the code so I can fix it

ornate dragonBOT Apr 15, 2026, 7:16 PM

#

Yep, and I need to correct myself a bit, the current code is more nuanced than the docs.

If you want to chase/fix it, these are the spots I’d start with:

1) Ollama provider discovery entrypoint

extensions/ollama/index.ts

Relevant section is the discovery handler, around the block starting with:

const explicit = ctx.config.models?.providers?.ollama;
const hasExplicitModels = ...
const hasMeaningfulExplicitConfig = ...
const provider = await buildOllamaProvider(explicit?.baseUrl, ...)

That code path suggests:

if explicit.models.length > 0, it uses the manual list

#

otherwise it still calls buildOllamaProvider(explicit?.baseUrl, ...)

So baseUrl + models: [] is supposed to still try discovery.

2) Actual `/api/tags` fetch

extensions/ollama/src/provider-models.ts

Look at:

fetchOllamaModels(baseUrl)
fetchWithSsrFGuard({ url: \${apiBase}/api/tags` ... })`
enrichOllamaModelsWithContext(...)

This is where Ollama discovery actually happens.

3) What the picker receives

src/gateway/server-methods/models.ts

#

This is the server side for models.list, which the picker uses.

It does:

const catalog = await context.loadGatewayModelCatalog();
then applies buildAllowedModelSet(...)

So if only 2 models are showing, either:

the Ollama catalog only has 2 models by the time it gets here, or
the allowlist logic is filtering more than expected

4) Existing tests that already cover this area

These are especially useful:

extensions/ollama/index.test.ts
- has a test literally named "treats non-default baseUrl as explicit discovery config"
src/agents/models-config.providers.ollama.test.ts

#

has coverage around /api/tags
- explicit models vs discovery behavior
- remote base URLs

So if you patch this, those are the first tests I’d update/run.

My read of it

The docs say remote explicit config disables autodiscovery, but the code looks like it should still try discovery when models: [].

So I’d start by instrumenting:

extensions/ollama/index.ts
extensions/ollama/src/provider-models.ts

and check whether fetchOllamaModels("http://labratory:11434") is returning only those two models, or whether something later is collapsing the catalog.

#Cleaning Noise from provider spam in Session Chat Controls

How to interpret the results

Best fix, if you want autodetect

If you want an explicit Ollama provider block

What I’d do here

Your options

1) Ollama provider discovery entrypoint

2) Actual /api/tags fetch

3) What the picker receives

4) Existing tests that already cover this area

My read of it

2) Actual `/api/tags` fetch