Trying To Add Specialized LLM Model To OpenClaw Agent As His Default But It Won't Take | Friends of the Crustacean 🦞🤝 | Page 1

potent harbor Apr 13, 2026, 1:06 PM

#

I am trying to build an OpenClaw subagent that I want to use a specific model (RingoSystems/RingoLLM) but for some reason my set up just keeps choking on it. I can't get it to work, my orchestator has broken everything twice trying, and I can't seem to get it to work. The model is available on Ollama so I thought maybe the model call should be ollama/ringosystems/ringollm but that doesn't work. If I try to a provider block with ollama referenced and use ringosystems/ringollm it doesn't work. It either breaks the comms altogether with the bot or the bot just rolls to the fallback. Out of ideas here...

"clouds",

"workspace": "/home/cambot/.openclaw/workspace-clouds",

"model": {

"primary": "ringosystems/ringollm:latest",

"fallbacks": [

"ollama/minimax-m2.7:cloud"

wet cradleBOT Apr 13, 2026, 1:06 PM

#

west sierraBOT Apr 13, 2026, 1:06 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

wet cradleBOT Apr 13, 2026, 1:06 PM

#

smoky hearthBOT Apr 13, 2026, 1:08 PM

#

Yep, I think I see the main problem.

OpenClaw parses model refs as provider/model on the first slash. So this:

"primary": "ringosystems/ringollm:latest"

gets read as:

provider = ringosystems
model = ringollm:latest

not as “an Ollama model named ringosystems/ringollm:latest”.

If that model lives in Ollama, the ref should be:

#

model: {
  primary: "ollama/ringosystems/ringollm:latest",
  fallbacks: []
}

A few Ollama gotchas that matter here:

If you define models.providers.ollama explicitly, auto-discovery turns off. Then you must manually add the model under models.providers.ollama.models[].
If you use an Ollama provider block, use the native API:
- baseUrl: "http://host:11434"
- api: "ollama"
- not /v1
If agents.defaults.models is set, add the full ref there too, or OpenClaw may reject it / fall through.

For a remote/manual Ollama setup, it should look more like:

#

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://your-ollama-host:11434",
        api: "ollama",
        apiKey: "ollama-local",
        models: [
          { id: "ringosystems/ringollm:latest", name: "RingoLLM" }
        ]
      }
    }
  },
  agents: {
    list: [

#

      {
        id: "clouds",
        workspace: "/home/cambot/.openclaw/workspace-clouds",
        model: {
          primary: "ollama/ringosystems/ringollm:latest",
          fallbacks: []
        }
      }
    ]
  }
}

Can you paste these 3 outputs next?

#

openclaw --version
openclaw models list --provider ollama --plain
openclaw models status

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

If you want, paste your models.providers.ollama block too and I’ll sanity-check it.

potent harbor Apr 13, 2026, 1:13 PM

#

openclaw --version
OpenClaw 2026.4.11 (769908e)

smoky hearthBOT Apr 13, 2026, 1:13 PM

#

Nice, 2026.4.11 is recent, so this probably isn’t a stale-version problem.

At this point I’d isolate model resolution from agent/tool-calling.

Turn off fallback while testing, otherwise it hides the real failure:

model: {
  primary: "ollama/ringosystems/ringollm:latest",
  fallbacks: []
}

Check the exact Ollama model ID OpenClaw sees:

#

openclaw models list --provider ollama --plain
openclaw models status

Test the model directly, outside the agent runtime:

openclaw infer model run \
  --model ollama/ringosystems/ringollm:latest \
  --prompt "Reply with just: ok" \
  --json

That split tells us a lot:

If that direct infer fails, it’s still a provider/model config issue.

#

If direct infer works but the agent still chokes, then the model is probably weak at OpenClaw agent/tool calling. That happens a lot with local/Ollama models.

Also, one big Ollama gotcha: if you added an explicit models.providers.ollama block, OpenClaw stops auto-discovering models. Then you must manually list this model in:

models.providers.ollama.models[]

And if you do have that provider block, make sure it uses:

baseUrl: "http://your-host:11434",
api: "ollama"

not /v1.

#

If you paste these next, I can usually spot it fast:

openclaw models list --provider ollama --plain
openclaw models status
your models.providers.ollama block, if you have one

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

potent harbor Apr 13, 2026, 1:14 PM

#

openclaw models list --provider ollama --plain

🦞 OpenClaw 2026.4.11 (769908e)
I'm the reason your shell history looks like a hacker-movie montage.

ollama/glm-5.1:cloud
cambot@LegionBox:~/.openclaw$

smoky hearthBOT Apr 13, 2026, 1:14 PM

#

That output is the smoking gun.

Right now OpenClaw only sees one Ollama model:

ollama/glm-5.1:cloud

So ollama/ringosystems/ringollm:latest is not in the model catalog at all, which is why it falls through or breaks.

Most likely one of these is true:

ringosystems/ringollm:latest is not actually installed locally in Ollama, or
you defined models.providers.ollama explicitly, which disables auto-discovery, and your manual models[] only contains glm-5.1:cloud.

Fastest checks

#

Run these next:

ollama list
openclaw models status

If `ollama list` shows `ringosystems/ringollm:latest`

Then fix it one of these two ways:

Option A, easiest: remove the explicit models.providers.ollama block, set Ollama opt-in, restart gateway.

export OLLAMA_API_KEY=ollama-local
openclaw gateway restart

#

Then OpenClaw should auto-discover local Ollama tags.

Option B, keep manual provider config: add the model explicitly:

models: {
  providers: {
    ollama: {
      baseUrl: "http://127.0.0.1:11434",
      api: "ollama",
      apiKey: "ollama-local",
      models: [
        { id: "ringosystems/ringollm:latest", name: "RingoLLM" },
        { id: "glm-5.1:cloud", name: "GLM 5.1 Cloud" }
      ]
    }

#

}
}

Then your agent model should be:

model: {
  primary: "ollama/ringosystems/ringollm:latest",
  fallbacks: []
}

If `ollama list` does not show it

Then pull it first:

#

ollama pull ringosystems/ringollm:latest

Also, make sure your Ollama URL is the native one, not /v1:

baseUrl: "http://127.0.0.1:11434",
api: "ollama"

If you paste ollama list, openclaw models status, and your models.providers.ollama block, I can tell you exactly which branch you’re in.

potent harbor Apr 13, 2026, 1:15 PM

#

openclaw models status

🦞 OpenClaw 2026.4.11 (769908e)
I'm the middleware between your ambition and your attention span.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/glm-5.1:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (1): ollama/glm-5.1:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none
cambot@LegionBox:~/.openclaw$

smoky hearthBOT Apr 13, 2026, 1:15 PM

#

Ah, one more important clue: that status is for main, not your clouds agent.

You can see it here:

Agent dir : ~/.openclaw/agents/main/agent
Configured models (1): ollama/glm-5.1:cloud
source=models.json: ~/.openclaw/agents/main/agent/models.json

So right now we know:

the main agent only has ollama/glm-5.1:cloud in its catalog
that catalog is coming from models.json
ringosystems/ringollm:latest is nowhere in that catalog

Next command, specifically for your subagent

#

openclaw models status --agent clouds

Also run:

ollama list

What I suspect

Your clouds agent is probably also inheriting a models.json / explicit Ollama provider config that only contains the cloud model, which means OpenClaw literally cannot select Ringo.

If ollama list shows ringosystems/ringollm:latest but openclaw models status --agent clouds does not, then the fix is:

either remove the explicit Ollama model catalog so local models auto-discover

#

or add ringosystems/ringollm:latest manually to that agent’s models.providers.ollama.models[]

And while testing, definitely keep:

fallbacks: []

so it fails loud instead of silently rolling to GLM.

If you paste the output of openclaw models status --agent clouds, I think we’re very close to the exact fix.

potent harbor Apr 13, 2026, 1:16 PM

#

cambot@LegionBox:~/.openclaw$ openclaw models status
ollama list
NAME ID SIZE MODIFIED
embeddinggemma:latest 85462619ee72 621 MB 3 days ago
glm-5.1:cloud 59472abf9d0a - 3 days ago
minimax-m2.7:cloud 06daa293c105 - 3 days ago
VindicatedArtistry/lola:latest 338835bc1851 2.0 GB 3 days ago
ringosystems/ringollm:latest 8fa257b13715 5.9 GB 3 days ago
cambot@LegionBox:~/.openclaw$

smoky hearthBOT Apr 13, 2026, 1:17 PM

#

Perfect, that confirms the root cause.

ollama list does have:

ringosystems/ringollm:latest

but OpenClaw’s model catalog does not. So this is not a bad model name anymore, it’s a pinned catalog problem.

Your earlier status already showed the giveaway:

Configured models (1): ollama/glm-5.1:cloud
source=models.json: ~/.openclaw/agents/main/agent/models.json

#

So OpenClaw is reading a manual models.json catalog that only contains glm-5.1:cloud. In that state, it will never pick ollama/ringosystems/ringollm:latest, even though Ollama itself has it installed.

Fix

If you want to keep manual mode

Then you must explicitly add ringosystems/ringollm:latest to that agent’s models.providers.ollama.models[]. Right now the manual catalog only knows about glm-5.1:cloud.

And your agent config should be:

#

model: {
  primary: "ollama/ringosystems/ringollm:latest",
  fallbacks: []
}

One extra wrinkle: you’ve been showing main agent status, but your problem agent is clouds, so definitely run:

openclaw models status --agent clouds

If you paste that output, I can tell you exactly which file to fix.

potent harbor Apr 13, 2026, 1:26 PM

#

.openclaw$ openclaw models status --agent clouds

🦞 OpenClaw 2026.4.11 (769908e)
Your personal assistant, minus the passive-aggressive calendar reminders.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/clouds/agent
Default (agent): ringosystems/ringollm:latest
Fallbacks (1) (agent): ollama/minimax-m2.7:cloud
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (0) : -
Configured models (1): ollama/glm-5.1:cloud

Auth overview
Auth store : ~/.openclaw/agents/clouds/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/clouds/agent/models.json

Missing auth

ringosystems openclaw configure or set an API key env var.

OAuth/token status

none

smoky hearthBOT Apr 13, 2026, 1:26 PM

#

Nice, this fully explains it.

You have two separate problems:

Your agent model is set to:

ringosystems/ringollm:latest

So OpenClaw treats ringosystems as the provider, which is why you get:

Missing auth
- ringosystems

#

Your Ollama catalog for clouds still only contains:

Configured models (1): ollama/glm-5.1:cloud

So even if you fix the ref, OpenClaw still won’t select Ringo until it exists in the Ollama model catalog OpenClaw is using.

The fix

1) Fix the agent model ref

Change it to the full Ollama ref:

model: {
  primary: "ollama/ringosystems/ringollm:latest",

#

  fallbacks: []
}

(Use fallbacks: [] for now so it stops hiding the real error.)

2) Fix the Ollama catalog

Right now ~/.openclaw/agents/clouds/agent/models.json only knows about ollama/glm-5.1:cloud.

You need one of these approaches:

Option A, recommended

Stop pinning a manual Ollama model catalog for clouds, let OpenClaw auto-discover local Ollama models.

That means removing the explicit Ollama models[] catalog source for that agent, then restarting:

#

openclaw gateway restart

Option B

Keep manual catalog mode, but add this model to the ollama provider’s models[] for the clouds agent:

ringosystems/ringollm:latest

What you should see after the fix

openclaw models status --agent clouds

#

should show something like:

Default (agent): ollama/ringosystems/ringollm:latest
no Missing auth: ringosystems
Configured models includes ollama/ringosystems/ringollm:latest

So the short version is:

yes, the correct ref is ollama/ringosystems/ringollm:latest
and your clouds agent’s Ollama catalog is currently pinned wrong

If you paste the ollama section from ~/.openclaw/agents/clouds/agent/models.json (or the models.providers.ollama block that generated it), I can point to the exact line to change.

potent harbor Apr 13, 2026, 1:41 PM

#

is it possible that ringosystems/ringollm isn't compatible with openclaw?

smoky hearthBOT Apr 13, 2026, 1:41 PM

#

Yes, absolutely possible, but that is not the first thing breaking here.

Right now the confirmed blockers are still:

wrong model ref (ringosystems/... instead of ollama/ringosystems/...)
OpenClaw’s Ollama catalog for clouds does not include the model yet

So you have to fix those first, otherwise you’re not actually testing compatibility, you’re testing misconfiguration.

After that, compatibility can still be a real issue.

A lot of Ollama/local models are:

fine for plain chat
shaky with tool calling
shaky with long system prompts
shaky with structured message content

#

That means a model can “work in Ollama” and still be a bad fit for a full OpenClaw agent.

Good way to test it

After you fix the catalog/ref:

Test it as a plain text model first
Keep the subagent narrow
Disable fallback while testing
Prefer few or no tools at first

If it works for simple chat but falls apart once tools are involved, then yes, the model is probably not a good OpenClaw agent model, even though Ollama can run it.

So my honest answer is:

Yes, it might be incompatible for agent use
No, you haven’t proven that yet

#

Your current failure is still mostly config/catalog, not compatibility

If you want, I can help you do the next step in the cleanest order:

get ollama/ringosystems/ringollm:latest actually selectable in clouds
then test whether it works as a no-tools specialist agent vs a full tool-using agent

potent harbor Apr 13, 2026, 1:43 PM

#

[4/13/2026 8:35 AM] CAM2_Clouds: Logs confirm — OpenClaw knows ringollm exists, but the session_status tool is blocking it with "not allowed." This suggests the tool has its own model allowlist that's separate from the agent config.

Let me check the actual session state:
[4/13/2026 8:36 AM] CAM2_Clouds: Found the session. The issue is clear — session_status tool itself has a model allowlist that's blocking ringollm, separate from your agent config.

Let me check where that validation comes from:
[4/13/2026 8:37 AM] CAM2_Clouds: Found the actual source of the error. The session_status tool has its own model validation separate from the agent config. The tool is in agent-command-BUw17dbz.js and it's rejecting the model because it checks against an "allowed model keys" set.

smoky hearthBOT Apr 13, 2026, 1:44 PM

#

That log is directionally close, but I don’t think this is a weird session_status-only allowlist.

It matches the normal documented model allowlist behavior.

Your own status output already showed the real problem:

Configured models (1): ollama/glm-5.1:cloud

When OpenClaw has a configured model catalog / allowlist, model overrides and related tool checks only accept refs from that set. So ringollm getting rejected as “not allowed” is exactly what I’d expect from this state.

Also, your clouds agent still says:

Default (agent): ringosystems/ringollm:latest

#

Missing auth: ringosystems

That means it is still treating ringosystems as a provider, not as an Ollama model ref.

So the fix is still the same

Change the agent model to:

model: {
  primary: "ollama/ringosystems/ringollm:latest",
  fallbacks: []
}

#

Make sure that exact ref is in the allowed catalog for clouds, or remove the manual Ollama catalog so it can auto-discover it.

Right now your clouds agent catalog only allows:

ollama/glm-5.1:cloud

So OpenClaw is behaving correctly by blocking the override.

My recommendation

Don’t chase session_status internals yet. Fix the canonical model ref + allowed catalog first.

After that:

if it still falls back, then yes, we test runtime compatibility

#

if it works, then this was just allowlist/catalog mismatch all along

Docs:
https://docs.openclaw.ai/concepts/models#model-is-not-allowed-and-why-replies-stop
https://docs.openclaw.ai/providers/ollama

If you want, paste the ollama block from ~/.openclaw/agents/clouds/agent/models.json, and I can tell you exactly what line needs to become ollama/ringosystems/ringollm:latest.

lime tartan Apr 13, 2026, 1:49 PM

#

ran into something similar - the model string in your agent config has to match exactly what your provider expects. check your models.yaml and make sure the provider routing is pointing at the right endpoint. sometimes the issue is the model isn't in the gateway's known models list so it falls back to default.

smoky hearthBOT Apr 13, 2026, 1:49 PM

#

Yep, that’s basically the issue. Small OpenClaw-specific correction though, it’s not models.yaml here.

For this setup the relevant files are:

~/.openclaw/openclaw.json
agent-local ~/.openclaw/agents/clouds/agent/models.json

And the current outputs already show the two problems:

Default (agent): ringosystems/ringollm:latest
Configured models (1): ollama/glm-5.1:cloud
Missing auth: ringosystems

So the exact fix is:

#

use the full Ollama ref in the agent config

primary: "ollama/ringosystems/ringollm:latest"

make sure that exact model exists in the clouds agent’s allowed model catalog, or remove the manual Ollama catalog so OpenClaw auto-discovers local tags

Right now OpenClaw only allows:

ollama/glm-5.1:cloud

So it’s falling back exactly the way the docs describe.

If they fix those two things and it still chokes, then I’d start suspecting RingoLLM’s tool/runtime compatibility.

potent harbor Apr 13, 2026, 2:00 PM

#

I have to post this in parts because of Discord character limitations

PART 1:

{
"providers": {
"codex": {
"baseUrl": "https://chatgpt.com/backend-api",
"auth": "token",
"api": "openai-codex-responses",
"models": [
{
"id": "gpt-5.4",
"name": "gpt-5.4",
"api": "openai-codex-responses",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 272000,
"maxTokens": 128000,
"compat": {
"supportsReasoningEffort": true,
"supportsUsageInStreaming": true
}
},
{
"id": "gpt-5.4-mini",
"name": "GPT-5.4-Mini",
"api": "openai-codex-responses",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 272000,
"maxTokens": 128000,
"compat": {
"supportsReasoningEffort": true,
"supportsUsageInStreaming": true
}
},
{
"id": "gpt-5.4-mini",
"name": "GPT-5.4-Mini",
"api": "openai-codex-responses",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 272000,
"maxTokens": 128000,
"compat": {
"supportsReasoningEffort": true,
"supportsUsageInStreaming": true
}
},
{

smoky hearthBOT Apr 13, 2026, 2:00 PM

#

Stop there, the codex block isn’t the part we need 🙂

For this bug, only the ollama provider block matters, from:

"ollama": {
  ...
}

inside:

~/.openclaw/agents/clouds/agent/models.json

If Discord is being annoying, this one-liner will print just that block:

#

python3 - <<'PY'
import json, pathlib
p = pathlib.Path("~/.openclaw/agents/clouds/agent/models.json").expanduser()
data = json.loads(p.read_text())
print(json.dumps(data.get("providers", {}).get("ollama"), indent=2))
PY

That’s the bit that will tell us why OpenClaw only knows about ollama/glm-5.1:cloud and not ollama/ringosystems/ringollm:latest.

If ollama comes back as null / missing, that’s useful too.

potent harbor Apr 13, 2026, 2:02 PM

#

{
"baseUrl": "http://127.0.0.1:11434",
"apiKey": "OLLAMA_API_KEY",
"api": "ollama",
"models": [
{
"id": "kimi-k2.5:cloud",
"name": "kimi-k2.5:cloud",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "minimax-m2.7:cloud",
"name": "minimax-m2.7:cloud",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 204800,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "glm-5.1:cloud",
"name": "glm-5.1:cloud",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 202752,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "ringosystems/ringollm:latest",
"name": "ringosystems/ringollm:latest",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 40960,
"maxTokens": 8192,
"api": "ollama"
}
]
}

smoky hearthBOT Apr 13, 2026, 2:03 PM

#

Nice, this is actually really helpful.

That ollama block looks basically correct, and it does include:

"id": "ringosystems/ringollm:latest"

So the Ollama provider config itself is not the main problem now.

What’s left to fix

1) Your agent model ref is still wrong

Your clouds agent was reporting:

#

Default (agent): ringosystems/ringollm:latest
Missing auth: ringosystems

That means the agent config still needs to be changed to:

primary: "ollama/ringosystems/ringollm:latest"

not:

primary: "ringosystems/ringollm:latest"

#

2) You probably still have an allowlist issue

Earlier, OpenClaw showed:

Configured models (1): ollama/glm-5.1:cloud

That strongly suggests there is still an agents.defaults.models allowlist somewhere that only permits GLM.

So even though the Ollama provider knows about Ringo now, OpenClaw may still reject it as “not allowed” until you either:

add ollama/ringosystems/ringollm:latest to the allowed models list, or
remove that allowlist entirely

So my read now is

provider block: looks fine

#

model compatibility: still unproven
current blocker: wrong primary ref, plus likely allowlist mismatch

Next exact check

Can you paste the agents.defaults.models section from ~/.openclaw/openclaw.json?

That’s the piece I want next, because I think that’s where ollama/glm-5.1:cloud is being pinned as the only allowed model.

potent harbor Apr 13, 2026, 2:03 PM

#

thanks @lime tartan, didn't want you to think I didn't see you up there 😉

#

{
"agents": {
"defaults": {
"workspace": "/home/cambot/.openclaw/workspace",
"model": {
"primary": "ollama/glm-5.1:cloud"
},
"models": {
"ollama/glm-5.1:cloud": {}
},
"compaction": {
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 4000
}
},
"memorySearch": {
"provider": "ollama",
"model": "embeddinggemma:latest"
}
},
"list": [
{
"id": "main",
"model": {
"primary": "ollama/glm-5.1:cloud",
"fallbacks": [
"ollama/minimax-m2.7:cloud"
]
}
},
{
"id": "clouds",
"workspace": "/home/cambot/.openclaw/workspace-clouds",
"model": {
"primary": "ollama/ringosystems/ringollm:latest",
"fallbacks": [
"ollama/minimax-m2.7:cloud"
]
}
},
{
"id": "cx1",
"workspace": "/home/cambot/.openclaw/workspace-cx1",
"model": {
"primary": "ollama/glm-5.1:cloud",
"fallbacks": [
"ollama/minimax-m2.7:cloud"

smoky hearthBOT Apr 13, 2026, 2:09 PM

#

There it is. That’s the bug. 🎯

This line is your global model allowlist:

"models": {
  "ollama/glm-5.1:cloud": {}
}

So even though clouds has:

"primary": "ollama/ringosystems/ringollm:latest"

OpenClaw still only considers GLM “allowed”. That matches the not allowed behavior exactly.

#

Fix

Either remove agents.defaults.models entirely, or expand it to include every model you actually want to use, for example:

"models": {
  "ollama/glm-5.1:cloud": {},
  "ollama/minimax-m2.7:cloud": {},
  "ollama/ringosystems/ringollm:latest": {}
}

Since clouds falls back to MiniMax, I’d include that too.

After changing it

save config

#

restart gateway

openclaw gateway restart

re-check:

openclaw models status --agent clouds
openclaw models list --provider ollama --plain

At that point I’d expect:

ollama/ringosystems/ringollm:latest to be allowed
session_status / model checks to stop complaining

#

clouds to actually attempt Ringo first

So yeah, it wasn’t Ollama incompatibility first. It was the global allowlist pinning you to GLM.

Docs:
https://docs.openclaw.ai/concepts/models#model-is-not-allowed-and-why-replies-stop

Glad we caught that. If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

potent harbor Apr 13, 2026, 2:12 PM

#

so just to confirm, to "remove agents.defaults.models", you mean this right? "agents": {
"defaults": {
"workspace": "/home/cambot/.openclaw/workspace",
"model": {
"primary": "ollama/glm-5.1:cloud"
},

smoky hearthBOT Apr 13, 2026, 2:12 PM

#

Close, but no. Keep agents.defaults.model.

Remove only this block:

"models": {
  "ollama/glm-5.1:cloud": {}
}

So this:

"agents": {
  "defaults": {
    "workspace": "/home/cambot/.openclaw/workspace",

#

    "model": {
      "primary": "ollama/glm-5.1:cloud"
    },
    "models": {
      "ollama/glm-5.1:cloud": {}
    }
  }
}

becomes:

"agents": {
  "defaults": {

#

    "workspace": "/home/cambot/.openclaw/workspace",
    "model": {
      "primary": "ollama/glm-5.1:cloud"
    }
  }
}

So:

defaults.model = your default model choice
defaults.models = the allowlist/catalog that was blocking Ringo

If you want, you can also keep defaults.models and just expand it instead of removing it. But if your goal is “stop blocking Ringo”, yes, remove only the models object. Then restart the gateway.

potent harbor Apr 13, 2026, 3:06 PM

#

so i killed all the sessions for clouds agent and now I can't reach him on telegram and i tried talking to him on webchat (where it does indicate he is on ringollm) but its just dots no chat yet.

smoky hearthBOT Apr 13, 2026, 3:06 PM

#

Oof, that sounds like you got past the allowlist problem and into a runtime stall.

If webchat now shows ringollm but only sits on typing dots, I’d treat that as:

model selection is probably happening
the actual run is hanging or choking once the agent prompt starts

Do this in order

openclaw gateway restart
openclaw status --all
openclaw models status --agent clouds

Then, while sending one test message to clouds, tail logs:

#

openclaw logs --follow

Very important isolation test

Run the model directly, outside Telegram/webchat/session state:

openclaw infer model run \
  --model ollama/ringosystems/ringollm:latest \
  --prompt "Reply with exactly: ok" \
  --json

That tells us a lot:

#

if this hangs/errors, ringollm is the problem for OpenClaw runtime
if this works, but chat still hangs, then it’s the full agent/session/tool prompt path that ringollm is choking on

For now

Keep:

"fallbacks": []

while testing, otherwise it muddies the signal again.

So my guess now is: we fixed the allowlist, and now we’re finally seeing the real compatibility question. If you paste the first error lines from openclaw logs --follow, I can help decode them fast.

Docs:
https://docs.openclaw.ai/gateway/troubleshooting

potent harbor Apr 13, 2026, 3:12 PM

#

5:01:12+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"c8c48fed-995d-47f1-b248-bc520735125f","decision":"candidate_failed","requestedProvider":"ollama","requestedModel":"ringosystems/ringollm:latest","candidateProvider":"ollama","candidateModel":"minimax-m2.7:cloud","attempt":2,"total":2,"reason":"format","status":400,"errorPreview":"No available auth profile for ollama (all in cooldown or unavailable).","errorHash":"sha256:99f4b56ebad0","isPrimary":false,"requestedModelMatched":false,"fallbackConfigured":true} model fallback decision
15:01:12+00:00 error Embedded agent failed before reply: All models failed (2): ollama/ringosystems/ringollm:latest: LLM request failed: provider rejected the request schema or tool payload. (format) | ollama/minimax-m2.7☁️ No available auth profile for ollama (all in cooldown or unavailable). (format) | No available auth profile for ollama (all in cooldown or unavailable).
15:07:37+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 72ms conn=b0d87120…14dc id=62b6e2fb…59cb

smoky hearthBOT Apr 13, 2026, 3:13 PM

#

Yep, this log is the smoking gun.

The good news is, OpenClaw is now actually selecting:

ollama/ringosystems/ringollm:latest

The bad news is, it then dies with:

provider rejected the request schema or tool payload. (format)

So your earlier suspicion was right, for full agent use, RingoLLM looks incompatible right now, or at least incompatible with OpenClaw’s normal tool/schema payloads.

The MiniMax error is secondary. That only happened because fallback kicked in after Ringo failed.

#

What I’d try next

1) Disable fallback while testing

"fallbacks": []

2) Mark Ringo as no-tools

On that model entry, try adding:

"compat": {
  "supportsTools": false
}

so it becomes roughly:

#

{
  "id": "ringosystems/ringollm:latest",
  "name": "ringosystems/ringollm:latest",
  "reasoning": false,
  "input": ["text"],
  "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
  "contextWindow": 40960,
  "maxTokens": 8192,
  "api": "ollama",
  "compat": {
    "supportsTools": false
  }
}

Then restart the gateway and retest.

#

3) Do the direct model test

openclaw infer model run \
  --model ollama/ringosystems/ringollm:latest \
  --prompt "Reply with exactly: ok" \
  --json

How to interpret that

if direct infer works, but agent chat still fails without tools, then Ringo is still a bad fit for OpenClaw agent runtime
if direct infer fails too, then it’s basically not usable here via OpenClaw/Ollama for this purpose

So at this point I’d say:

routing problem: fixed
allowlist problem: fixed

#

real remaining issue: model/runtime compatibility

Docs:
https://docs.openclaw.ai/gateway/troubleshooting

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

potent harbor Apr 13, 2026, 3:23 PM

#

10:22:12-05:00 [agent/embedded] embedded run agent end: runId=ce7cddde-957d-4a9b-914c-51e0da954aba isError=true model=ringosystems/ringollm:latest provider=ollama error=LLM request failed: provider rejected the request schema or tool payload. rawError=400 {"error":"registry.ollama.ai/ringosystems/ringollm:latest does not support tools"}
10:22:12-05:00 [agent/embedded] auth profile failure state updated: runId=ce7cddde-957d-4a9b-914c-51e0da954aba profile=sha256:9c018ec112cf provider=ollama reason=format window=cooldown reused=false
10:22:12-05:00 [agent/embedded] embedded run failover decision: runId=ce7cddde-957d-4a9b-914c-51e0da954aba stage=assistant decision=fallback_model reason=format provider=ollama/ringosystems/ringollm:latest profile=sha256:9c018ec112cf
10:22:12-05:00 [diagnostic] lane task error: lane=main durationMs=5705 error="FailoverError: LLM request failed: provider rejected the request schema or tool payload."
10:22:12-05:00 [diagnostic] lane task error: lane=session:agent:main:main durationMs=5708 error="FailoverError: LLM request failed: provider rejected the request schema or tool payload."

#

10:22:12-05:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=ollama/ringosystems/ringollm:latest candidate=ollama/ringosystems/ringollm:latest reason=format next=ollama/minimax-m2.7:cloud detail=LLM request failed: provider rejected the request schema or tool payload.
10:22:14-05:00 [diagnostic] lane task error: lane=main durationMs=1650 error="FailoverError: No available auth profile for ollama (all in cooldown or unavailable)."
10:22:14-05:00 [diagnostic] lane task error: lane=session:agent:main:main durationMs=1651 error="FailoverError: No available auth profile for ollama (all in cooldown or unavailable)."
10:22:14-05:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=ollama/ringosystems/ringollm:latest candidate=ollama/minimax-m2.7:cloud reason=format next=none detail=No available auth profile for ollama (all in cooldown or unavailable).
FallbackSummaryError: All models failed (2): ollama/ringosystems/ringollm:latest: LLM request failed: provider rejected the request schema or tool payload. (format) | ollama/minimax-m2.7☁️ No available auth profile for ollama (all in cooldown or unavailable). (format)

smoky hearthBOT Apr 13, 2026, 3:24 PM

#

That’s definitive.

"registry.ollama.ai/ringosystems/ringollm:latest does not support tools"

So yes, RingoLLM is not compatible as a normal tool-using OpenClaw agent model.

OpenClaw is doing the right thing now:

it selects ollama/ringosystems/ringollm:latest
Ollama rejects the request because the model does not support tools
failover kicks in

What this means

If you want clouds to be a normal agent with tools, don’t use RingoLLM as its primary.

#

If you want to use RingoLLM anyway, use it as a text-only / no-tools specialist.

Best next move

On the Ringo model entry, add:

"compat": {
  "supportsTools": false
}

Then keep clouds narrow and retest.

If that still doesn’t behave, I’d stop fighting it and use a different model for the actual agent loop.

So the final diagnosis is

#

model naming: fixed
allowlist: fixed
root cause: RingoLLM does not support tools

The auth/cooldown noise after that is just fallout from the first failure.

If you want, I can help you turn clouds into either:

a no-tools Ringo specialist, or
a tool-using agent on a different model with Ringo kept for narrow text work

If this solved the mystery, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

#

Yep, that’s the same conclusion, just with the full failover chain visible now.

What’s happening is:

ollama/ringosystems/ringollm:latest is selected
it fails with does not support tools
OpenClaw tries fallback
the Ollama auth profile is already in cooldown / unavailable, so fallback dies too

So the real failure is still the first one:

ollama/ringosystems/ringollm:latest does not support tools

The second error is mostly fallout.

#

Practical takeaway

While testing Ringo, set:

"fallbacks": []

Otherwise the fallback noise makes the logs look worse than they are.

Then either:

mark Ringo as no-tools with

"compat": { "supportsTools": false }

#

or

stop using it as an agent model and switch clouds to a tool-capable model

If you still see the auth profile cooldown poisoning the fallback path after that, I’d honestly consider that suspicious enough to file a GitHub issue:
https://github.com/openclaw/openclaw/issues

But for the root cause, I think we have it pinned now.

potent harbor Apr 13, 2026, 3:40 PM

#

so before when i sent that result the added text didn't save. I made sure it saved this time and now it says

FallbackSummaryError: All models failed (2): ollama/ringosystems/ringollm:latest: LLM request failed: provider rejected the request schema or tool payload. (format) | ollama/minimax-m2.7☁️ No available auth profile for ollama (all in cooldown or unavailable). (format)

smoky hearthBOT Apr 13, 2026, 3:41 PM

#

That tells me the effective config still isn’t the one you think it is.

Why I’m saying that:

it’s still trying 2 models, so fallbacks: [] is not active yet
it’s still sending tools to Ringo, so compat.supportsTools: false is not active yet either

If those two changes had actually taken, this error would look different.

Quick sanity checks

After saving, run:

openclaw models status --agent clouds

#

You want to see:

Fallbacks (0) for clouds

Then restart the gateway:

openclaw gateway restart

And use a fresh session for clouds.

Relevant files

~/.openclaw/openclaw.json → agent primary + fallbacks
~/.openclaw/agents/clouds/agent/models.json → model compat flags like:

#

"compat": {
  "supportsTools": false
}

The key point

Right now the logs prove OpenClaw is still running with:

fallback still enabled
tool support still enabled for Ringo

So before we conclude anything new, I’d verify the active config is actually loaded.

If openclaw models status --agent clouds still shows a fallback after your edit, you’re either editing the wrong file or the gateway hasn’t reloaded it yet.

potent harbor Apr 13, 2026, 3:47 PM

#

why would my addition of the above "compat" flags keep disappearing?

smoky hearthBOT Apr 13, 2026, 3:48 PM

#

Because you’re almost certainly editing the generated file, not the source of truth.

In OpenClaw, the agent-local:

~/.openclaw/agents/clouds/agent/models.json

gets regenerated from config, so manual edits there can get wiped.

Put the `compat` flag in the source config instead

Not here:

agents.defaults.models ← this is the allowlist

But here:

#

top-level models.providers.ollama.models[] ← this is the provider model catalog

So the ringollm entry in ~/.openclaw/openclaw.json should look like:

"models": {
  "providers": {
    "ollama": {
      "baseUrl": "http://127.0.0.1:11434",
      "apiKey": "OLLAMA_API_KEY",
      "api": "ollama",
      "models": [
        {
          "id": "ringosystems/ringollm:latest",
          "name": "ringosystems/ringollm:latest",
          "reasoning": false,

#

          "input": ["text"],
          "cost": {
            "input": 0,
            "output": 0,
            "cacheRead": 0,
            "cacheWrite": 0
          },
          "contextWindow": 40960,
          "maxTokens": 8192,
          "api": "ollama",
          "compat": {
            "supportsTools": false
          }
        }
      ]

#

    }
  }
}

Then restart:

openclaw gateway restart

Short version

agents.defaults.models = allowlist
models.providers.ollama.models[] = actual model definitions
agent/.../models.json = generated output, edits there may disappear

#

That’s why your flag keeps vanishing.

potent harbor Apr 13, 2026, 4:14 PM

#

now it's giving me syntax errors for the " in "api"

smoky hearthBOT Apr 13, 2026, 4:14 PM

#

Yep, that’s almost certainly just a missing comma.

Inside that model object, this part needs to look exactly like this:

{
  "id": "ringosystems/ringollm:latest",
  "name": "ringosystems/ringollm:latest",
  "reasoning": false,
  "input": ["text"],
  "cost": {
    "input": 0,
    "output": 0,
    "cacheRead": 0,
    "cacheWrite": 0
  },

#

  "contextWindow": 40960,
  "maxTokens": 8192,
  "api": "ollama",
  "compat": {
    "supportsTools": false
  }
}

The most common mistake is this:

"maxTokens": 8192
"api": "ollama"

#

when it needs to be:

"maxTokens": 8192,
"api": "ollama",

So:

comma after 8192
comma after "ollama"
compat stays inside the same model object

If you want, paste just the 10 lines around the ringollm entry and I’ll fix the exact syntax.

potent harbor Apr 13, 2026, 7:29 PM

#

we fixed it thanks!

smoky hearthBOT Apr 13, 2026, 7:29 PM

#

Hell yes, glad you got it unstuck 🎉

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

#Trying To Add Specialized LLM Model To OpenClaw Agent As His Default But It Won't Take