Agent wont use specific model | Friends of the Crustacean 🦞🤝 | Page 1

marble harness Apr 16, 2026, 5:09 PM

#

I am new to Openclaw just setup it with 2 ollama server.
1 at home and another one at my office. As I have 2 agent configured to each ollama server but agents that point to office ollama server always fallback to home ollama

icy anchorBOT Apr 16, 2026, 5:09 PM

#

autumn duneBOT Apr 16, 2026, 5:13 PM

#

That usually means one of these is happening:

both Ollama servers are under the same provider id (ollama), so one baseUrl wins
the agent is using just model-name instead of full provider/model, so it falls back to the default provider
the office Ollama is unreachable, so failover kicks in

For 2 Ollama servers, I’d set them up as two provider ids, for example ollama-home and ollama-office, then point each agent at the full ref:

{
  models: {
    providers: {
      "ollama-home": {
        baseUrl: "http://home-host:11434",
        api: "ollama",
        apiKey: "ollama-local",

#

        models: [{ id: "llama3.3" }]
      },
      "ollama-office": {
        baseUrl: "http://office-host:11434",
        api: "ollama",
        apiKey: "ollama-local",
        models: [{ id: "llama3.3" }]
      }
    }
  }
}

Then use:

ollama-home/llama3.3
ollama-office/llama3.3

#

Also, use the native Ollama URL, not /v1.

One more gotcha: OpenClaw can keep an old provider baseUrl in the agent’s models.json, and in merge mode that stale baseUrl can win. So if you changed this after creating the agent, that may be the bug.

Please paste these, and I’ll tell you exactly which one it is:

openclaw --version
openclaw models status --agent <office-agent>

Docs:

marble harness Apr 16, 2026, 5:14 PM

#

there is 2 ollama endpoint
"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://1xx.xxx.xxx.xxx:11434",
"api": "ollama",
"apiKey": "OLLAMA_API_KEY",
"models": [
{
"id": "gemma4:e4b-h",
"name": "gemma4:e4b-h",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192
}
]
},
"office": {
"baseUrl": "http://1x.xx.xxx.xxx:11434",
"api": "ollama",
"apiKey": "OLLAMA_API_KEY",
"models": [
{
"id": "gemma4:e4b-32k",
"name": "gemma4:e4b-32k",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 131072,
"maxTokens": 8192
}
]
}
}
},

#

[openclaw@fedora agent]$ ^C
[openclaw@fedora agent]$ openclaw --version
OpenClaw 2026.4.14 (323493f)
[openclaw@fedora agent]$ openclaw models status --agent onisuzume

🦞 OpenClaw 2026.4.14 (323493f) — Your config is valid, your assumptions are not.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/onisuzume/agent
Default (agent): office/gemma4:e4b-32k
Fallbacks (0) (defaults): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (2) : Home-gemma4 -> ollama/gemma4:e4b-h, Office-gemma4 -> office/gemma4:e4b-32k
Configured models (2): ollama/gemma4:e4b-h, office/gemma4:e4b-32k

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

office effective=models.json:marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/onisuzume/agent/models.json
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=0, api_key=2) | ollama:default=marker(ollama-local), office:default=missing | env=ol...al | source=env: OLLAMA_API_KEY | models.json=OL...EY | source=models.json: ~/.openclaw/agents/onisuzume/agent/models.json
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...3bae32f5 | env=sk-or-v1...3bae32f5 | source=env: OPENROUTER_API_KEY
perplexity effective=env:sk-or-v1...3bae32f5 | env=sk-or-v1...3bae32f5 | source=env: OPENROUTER_API_KEY

OAuth/token status

none
[openclaw@fedora agent]$

autumn duneBOT Apr 16, 2026, 5:16 PM

#

Yep, I think I see the likely issue.

In your config, these are two different provider ids:

ollama → home server
office → office server

So the office agent must use:

office/gemma4:e4b-32k

If the office agent is using:

#

ollama/gemma4:e4b-32k

then it will still hit the home endpoint, because ollama is your home provider.

A couple quick notes:

your provider setup itself looks basically fine
office is a valid custom provider id
api: "ollama" is the right transport here

What I’d check next:

openclaw --version

#

openclaw models status --agent <office-agent>

If that still looks wrong, the next likely culprit is stale agent models.json, because with models.mode: "merge" an old non-empty baseUrl can stick around. In that case, switching to models.mode: "replace" or regenerating that agent’s model registry usually fixes it.

If you want, paste the office agent config block too, especially its model.primary, and I can sanity check it fast.

Docs:

marble harness Apr 16, 2026, 5:17 PM

#

"agents": {
"defaults": {
"workspace": "/home/openclaw/.openclaw/workspace",
"timeoutSeconds": 3600,
"verboseDefault": "full",
"model": {
"primary": "Home-gemma4"
},
"models": {
"ollama/gemma4:e4b-h": {
"alias": "Home-gemma4"
},
"office/gemma4:e4b-32k": {
"alias": "Office-gemma4"
}
},
"llm": {
"idleTimeoutSeconds": 0
}
},
"list": [
{
"id": "main",
"tools": {
"profile": "full",
"alsoAllow": [
"browser",
"canvas",
"message",
"gateway",
"nodes",
"agents_list",
"tts"
]
}
},
{
"id": "onisuzume",
"name": "onisuzume",
"workspace": "/home/openclaw/.openclaw/workspace/onisuzume",
"agentDir": "/home/openclaw/.openclaw/agents/onisuzume/agent",
"model": "office/gemma4:e4b-32k"
},
{
"id": "kamonegi",
"name": "kamonegi",
"workspace": "/home/openclaw/.openclaw/workspace/kamonegi",
"agentDir": "/home/openclaw/.openclaw/agents/kamonegi/agent",
"model": "ollama/gemma4:e4b-32k"
}
]

#

oh I didnt specific primary on each agent so it will use default agent primary instead ?

#

here is my openclaw version : OpenClaw 2026.4.14 (323493f)

autumn duneBOT Apr 16, 2026, 5:20 PM

#

Yep, that version looks fine, nothing obviously ancient there.

So the next useful bits are still:

openclaw sessions --agent onisuzume

and ideally the two agent config blocks from agents.list.

At this point I’m mostly trying to distinguish between:

session override / sticky old session
two agents sharing state
runtime connection failure to the office endpoint

If you want a quick test before pasting more, try:

#

openclaw agent --agent onisuzume --message "/new"

Then send one normal prompt again. If that fixes it, it was the old session state.

marble harness Apr 16, 2026, 5:24 PM

#

Apr 16 23:56:33 fedora node[848452]: 2026-04-16T23:56:33.345+07:00 [diagnostic] lane task error: lane=main durationMs=196 error="Error: No API key found for provider "office". Auth store: /home/openclaw/.openclaw/agents/onisuzume/agent/auth-profiles.json (agentDir: /home/openclaw/.openclaw/agents/onisuzume/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
Apr 16 23:56:33 fedora node[848452]: 2026-04-16T23:56:33.346+07:00 [diagnostic] lane task error: lane=session:agent:onisuzume:tui-e89adde5-7885-46e7-93b9-3fad462f2190 durationMs=197 error="Error: No API key found for provider "office". Auth store: /home/openclaw/.openclaw/agents/onisuzume/agent/auth-profiles.json (agentDir: /home/openclaw/.openclaw/agents/onisuzume/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."

#

look like it's issue on authorize

autumn duneBOT Apr 16, 2026, 5:26 PM

#

Aha, there’s the bug.

The office provider is failing before runtime with:

No API key found for provider "office"

So the fix is: give the custom provider office an actual usable API key value.

For Ollama, the easiest fix is just set a dummy key directly:

openclaw config set models.providers.office.apiKey "ollama-local"
openclaw gateway restart

#

You can do the same for ollama too for consistency.

Important detail: in config, this:

"apiKey": "OLLAMA_API_KEY"

is just a literal string, not env substitution.

If you want env substitution, use:

apiKey: "${OLLAMA_API_KEY}"

or a SecretRef.

#

Why this happened:

ollama is the built-in provider, so it can pick up Ollama auth behavior more naturally
office is a custom provider id, so it needs its own usable credential source

So I’d change office to either:

apiKey: "ollama-local"

or

apiKey: "${OLLAMA_API_KEY}"

then restart the gateway.

#

Docs:

If you want, paste the updated office block after the change and I’ll sanity check it.

#

Yep, exactly, auth for the custom office provider.

So it’s not really “falling back to home”, the office provider is failing auth first.

Use either:

apiKey: "ollama-local"

or proper env substitution:

apiKey: "${OLLAMA_API_KEY}"

then restart:

#

openclaw gateway restart

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

marble harness Apr 16, 2026, 5:30 PM

#

"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://XXX.XX.XXX.XXX:11434",
"api": "ollama",
"apiKey": "ollama-local",
"models": [
{
"id": "gemma4:e4b-h",
"name": "gemma4:e4b-h",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 128000,
"maxTokens": 8192
}
]
},
"office": {
"baseUrl": "http://1X.XX.XXX.XXX:11434",
"api": "ollama",
"apiKey": "ollama-local",
"models": [
{
"id": "gemma4:e4b-32k",
"name": "gemma4:e4b-32k",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 131072,
"maxTokens": 8192
}
]
}
}
},
"auth": {
"profiles": {
"ollama:main": {
"provider": "ollama",
"mode": "api_key"
},
"openrouter:default": {
"provider": "openrouter",
"mode": "api_key"
},
"office:default": {
"provider": "ollama",
"mode": "api_key"
}
}
},

autumn duneBOT Apr 16, 2026, 5:31 PM

#

This looks much closer. I only see one suspicious thing now:

"office:default": {
  "provider": "ollama",
  "mode": "api_key"
}

If that profile is meant for the office provider, the provider should be:

"office:default": {
  "provider": "office",
  "mode": "api_key"
}

#

Right now it’s registered as an ollama profile, not an office profile.

Honestly, since you already have:

models.providers.office.apiKey: "ollama-local"

you may not need that auth.profiles.office:default block at all. The model provider config can carry it.

So I’d do this:

keep:

office: {
  baseUrl: "...",

#

  api: "ollama",
  apiKey: "ollama-local"
}

either:

remove auth.profiles.office:default, or
change its provider to "office"

restart the gateway:

openclaw gateway restart

test again

#

If it still throws the old auth error after that, the next likely culprit is stale merged agent state in models.json, because models.mode: "merge" can preserve older values. But first, I’d fix that provider: "ollama" mismatch.

trim trench Apr 16, 2026, 5:34 PM

#

Enter Telegram bot token
│ 8680753295:AAE3kvv5KwuUxWTE6_6IXfwAGWL-EHjMjgo
│
◇ Telegram DM access warning ────────────────────────────────────────────╮
│ │
│ Your bot is using DM policy: pairing. │
│ Any Telegram user who discovers the bot can send pairing requests. │
│ For private use, configure an allowlist with your Telegram user id: │
│ openclaw config set channels.telegram.dmPolicy "allowlist" │
│ openclaw config set channels.telegram.allowFrom '["YOUR_USER_ID"]' │
│ Docs: │
│ channels/pairing │
│ │
├─────────────────────────────────────────────────────────────────────────╯
TypeError: Cannot read properties of undefined (reading 'trim')

marble harness Apr 16, 2026, 5:37 PM

#

I already fix that and ask new session still thrown
Apr 17 00:35:00 fedora node[867027]: 2026-04-17T00:35:00.272+07:00 [diagnostic] lane task error: lane=main durationMs=10629 error="Error: No API key found for provider "office". Auth store: /home/openclaw/.openclaw/agents/onisuzume/agent/auth-profiles.json (agentDir: /home/openclaw/.openclaw/agents/onisuzume/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."
Apr 17 00:35:00 fedora node[867027]: 2026-04-17T00:35:00.273+07:00 [diagnostic] lane task error: lane=session:agent:onisuzume:main durationMs=10631 error="Error: No API key found for provider "office". Auth store: /home/openclaw/.openclaw/agents/onisuzume/agent/auth-profiles.json (agentDir: /home/openclaw/.openclaw/agents/onisuzume/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir."

autumn duneBOT Apr 16, 2026, 5:37 PM

#

Also, that Telegram bot token is exposed in this thread, so please rotate it in BotFather immediately and do not paste the replacement here.

The TypeError: Cannot read properties of undefined (reading 'trim') after that warning looks like a real onboarding bug on 2026.4.14, not user error.

Workaround for now, configure Telegram manually instead of the wizard:

channels.telegram.botToken
channels.telegram.dmPolicy
channels.telegram.allowFrom

Docs: https://docs.openclaw.ai/channels/telegram

And if it’s reproducible, please file a GitHub issue with:

version: 2026.4.14
exact steps: onboard -> Telegram -> paste token -> DM policy warning -> TypeError

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

#

So yeah, two separate things here:

rotate the leaked token now
the trim crash looks like a bug

#

Yep, this confirms it, it’s still auth resolution, not session state.

The key detail is this:

auth.profiles is metadata/routing only
the actual API key for an api_key profile must exist in
~/.openclaw/agents/onisuzume/agent/auth-profiles.json

So if you have this in config:

"office:default": {
  "provider": "office",
  "mode": "api_key"
}

#

but there is no real office key stored in that agent’s auth-profiles.json, runtime throws exactly the error you’re seeing.

Simplest fix

Since this is Ollama and you already have:

models.providers.office.apiKey: "ollama-local"

remove the auth.profiles.office:default entry entirely
(and any auth.order.office entry if you added one)

Then restart:

openclaw gateway restart

#

Why

Right now OpenClaw is trying to use the agent auth store for provider office, and that store has no actual office key.

If you want to keep auth profiles instead

Then you need to actually provision a real office API-key profile into:

~/.openclaw/agents/onisuzume/agent/auth-profiles.json

But for Ollama, that’s overkill. I’d just let models.providers.office.apiKey handle it.

So, short version:

keep models.providers.office.apiKey: "ollama-local"
remove auth.profiles.office:default
restart gateway

#

If it still fails after removing that auth profile, then I’d look at stale merged agent state next.

marble harness Apr 16, 2026, 5:39 PM

#

{
"version": 1,
"profiles": {
"office:default": {
"type": "api_key",
"provider": "ollama",
"mode": "ollama-local"
},
"openrouter:default": {
"type": "api_key",
"provider": "openrouter",
"key": "sk-orxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
}
}

autumn duneBOT Apr 16, 2026, 5:40 PM

#

Yep, that’s the smoking gun.

That auth-profiles.json is wrong for office in 3 ways:

provider is ollama, but your runtime is asking for provider office
type: "api_key" profiles need a key field, not mode
you have duplicate "office:default" entries

For an actual office auth profile, it would need to look like:

{
  "version": 1,
  "profiles": {
    "office:default": {
      "type": "api_key",

#

      "provider": "office",
      "key": "ollama-local"
    }
  }
}

But honestly, the simplest fix is still:

remove the broken office:default auth profile
keep models.providers.office.apiKey: "ollama-local"
restart the gateway

If you want to keep using the auth store instead, then the profile must be exactly:

#

"office:default": {
  "type": "api_key",
  "provider": "office",
  "key": "ollama-local"
}

Then restart:

openclaw gateway restart

After that, run:

#

openclaw models status --agent onisuzume

and it should stop complaining about missing auth for office.

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

trim trench Apr 16, 2026, 5:41 PM

#

chỉ tôi từng bước sửa nha

autumn duneBOT Apr 16, 2026, 5:42 PM

#

Được, làm theo cách đơn giản nhất này nhé, khỏi dùng auth profile cho office, chỉ dùng models.providers.office.apiKey.

Bước 1: sửa `~/.openclaw/openclaw.json`

Giữ phần này:

"models": {
  "mode": "merge",
  "providers": {
    "office": {
      "baseUrl": "http://IP_OFFICE:11434",
      "api": "ollama",
      "apiKey": "ollama-local"
    }
  }
}

#

Bước 2: xóa `office:default` khỏi `auth.profiles`

Trong ~/.openclaw/openclaw.json, nếu có đoạn này thì xóa nó đi:

"office:default": {
  "provider": "office",
  "mode": "api_key"
}

Hoặc nếu đang là provider: "ollama" thì cũng xóa luôn.

Bước 3: sửa `~/.openclaw/agents/onisuzume/agent/auth-profiles.json`

Trong file này, xóa hết mọi entry office:default.

File đó không nên còn mấy dòng kiểu:

#

"office:default": {
  "type": "api_key",
  "provider": "ollama",
  "mode": "ollama-local"
}

Vì nó sai:

provider sai
mode sai, phải là key
còn bị duplicate

Bước 4: restart gateway

openclaw gateway restart

#

Bước 5: kiểm tra lại

openclaw models status --agent onisuzume

Bước 6: test agent lại

Gửi thử prompt mới cho agent onisuzume.

Nếu vẫn lỗi

Lúc đó paste lại 2 thứ này:

output của:

openclaw models status --agent onisuzume

#

phần models.providers.office trong openclaw.json

Nếu muốn, mình có thể viết luôn cho bạn mẫu openclaw.json sạch, đúng chuẩn để bạn copy-paste.

trim trench Apr 16, 2026, 5:42 PM

#

viết cho tôi lệnh để paste vào terminal sửa nha

autumn duneBOT Apr 16, 2026, 5:43 PM

#

Ok, paste nguyên khối này vào terminal nhé:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%s)
cp ~/.openclaw/agents/onisuzume/agent/auth-profiles.json ~/.openclaw/agents/onisuzume/agent/auth-profiles.json.bak.$(date +%s)

openclaw config set models.providers.office.apiKey "ollama-local"
openclaw config unset 'auth.profiles["office:default"]'
openclaw config unset 'auth.order.office'

python3 - <<'PY'
from pathlib import Path
import json

p = Path.home() / ".openclaw/agents/onisuzume/agent/auth-profiles.json"
if p.exists():

#

    data = json.loads(p.read_text())
    data.setdefault("profiles", {}).pop("office:default", None)
    p.write_text(json.dumps(data, indent=2) + "\n")
    print("Cleaned:", p)
else:
    print("Not found:", p)
PY

openclaw config validate
openclaw gateway restart
openclaw models status --agent onisuzume

Mục tiêu của block này là:

backup config

#

giữ models.providers.office.apiKey = "ollama-local"
xóa office:default khỏi auth.profiles
xóa office:default khỏi auth-profiles.json
restart gateway
check lại agent

Nếu có dòng nào báo lỗi, paste nguyên output lên đây, mình đọc tiếp cho.

marble harness Apr 16, 2026, 5:45 PM

#

[openclaw@fedora .openclaw]$ openclaw models status --agent onisuzume

🦞 OpenClaw 2026.4.14 (323493f) — Somewhere between 'hello world' and 'oh god what have I built.'

00:44:49 [agents/auth-profiles] inherited auth-profiles from main agent
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/onisuzume/agent
Default (agent): office/gemma4:e4b-32k
Fallbacks (0) (defaults): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (2) : Home-gemma4 -> ollama/gemma4:e4b-h, Office-gemma4 -> office/gemma4:e4b-32k
Configured models (2): ollama/gemma4:e4b-h, office/gemma4:e4b-32k

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

office effective=missing:missing | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/onisuzume/agent/models.json
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | env=ol...al | source=env: OLLAMA_API_KEY | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/onisuzume/agent/models.json
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...3bae32f5 | env=sk-or-v1...3bae32f5 | source=env: OPENROUTER_API_KEY
perplexity effective=env:sk-or-v1...3bae32f5 | env=sk-or-v1...3bae32f5 | source=env: OPENROUTER_API_KEY

OAuth/token status

none

#

I alread remove office auth profile

autumn duneBOT Apr 16, 2026, 5:46 PM

#

Ah, found the last trap.

For a custom provider like office, this value:

apiKey: "ollama-local"

is not treated as a real key.
ollama-local is a special marker for the built-in ollama provider, so office still shows as missing.

Do this instead

Keep auth.profiles.office deleted, then run:

openclaw config set models.providers.office.apiKey "office-local-key"

#

openclaw gateway restart
openclaw models status --agent onisuzume

What should change

Right now you have:

office effective=missing:missing

After the change, office should stop being missing.

So short version:

ollama provider can use ollama-local
office custom provider should use any other non-empty dummy string, for example:

#

office-local-key
- dummy-office-key

If you want, after running that, paste the new openclaw models status --agent onisuzume output and I’ll verify it fast.

marble harness Apr 16, 2026, 5:46 PM

#

do i need to remove office:default from auth block as well ?
"auth": {
"profiles": {
"ollama:main": {
"provider": "ollama",
"mode": "api_key"
},
"openrouter:default": {
"provider": "openrouter",
"mode": "api_key"
},
"office:default": {
"provider": "ollama",
"mode": "api_key"
}
}
},

autumn duneBOT Apr 16, 2026, 5:46 PM

#

Perfect, then it’s just one last change:

office cannot use ollama-local as the key value.

Run this:

openclaw config set models.providers.office.apiKey "office-local-key"
openclaw gateway restart
openclaw models status --agent onisuzume

You do not need to add the office auth profile back.

I’m expecting this line to change from:

#

office effective=missing:missing

to something non-missing.

Paste the new output after that and I’ll confirm.

#

Yes, remove office:default from that auth.profiles block too.

That block is still wrong because:

it says provider: "ollama", not provider: "office"
and you’re not using auth profiles for office anymore

So keep only:

"auth": {
  "profiles": {
    "ollama:main": {
      "provider": "ollama",
      "mode": "api_key"
    },

#

    "openrouter:default": {
      "provider": "openrouter",
      "mode": "api_key"
    }
  }
}

Then keep office only here:

models.providers.office.apiKey

So, yes:

delete auth.profiles.office:default

#

set:

openclaw config set models.providers.office.apiKey "office-local-key"

restart:

openclaw gateway restart

You’re very close now.

trim trench Apr 16, 2026, 5:48 PM

#

Gateway restart timed out after 60s waiting for health checks.
Tip: openclaw gateway status --deep
Tip: openclaw doctor

🦞 OpenClaw 2026.4.14 (323493f)
I'm the reason your shell history looks like a hacker-movie montage.

[openclaw] Failed to start CLI: Error: Unknown agent id "onisuzume". Use "openclaw agents list" to see configured agents.
at resolveKnownAgentId (file:///opt/homebrew/lib/node_modules/openclaw/dist/shared-CuNJ3-a_.js:90:57)
at modelsStatusCommand (file:///opt/homebrew/lib/node_modules/openclaw/dist/models-DclzlBWN.js:1709:18)
at async Object.runParsedArgs (file:///opt/homebrew/lib/node_modules/openclaw/dist/run-main-CWEXgPOd.js:260:4)
at async Object.run (file:///opt/homebrew/lib/node_modules/openclaw/dist/run-main-CWEXgPOd.js:279:4)
at async runCli (file:///opt/homebrew/lib/node_modules/openclaw/dist/run-main-CWEXgPOd.js:419:7)

marble harness Apr 16, 2026, 5:49 PM

#

[openclaw@fedora .openclaw]$ openclaw models status --agent onisuzume

🦞 OpenClaw 2026.4.14 (323493f) — Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/onisuzume/agent
Default (agent): office/gemma4:e4b-32k
Fallbacks (0) (defaults): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (2) : Home-gemma4 -> ollama/gemma4:e4b-h, Office-gemma4 -> office/gemma4:e4b-32k
Configured models (2): ollama/gemma4:e4b-h, office/gemma4:e4b-32k

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

office effective=models.json:of...ey | models.json=of...ey | source=models.json: ~/.openclaw/agents/onisuzume/agent/models.json
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | env=ol...al | source=env: OLLAMA_API_KEY | models.json=marker(ollama-local) | source=models.json: ~/.openclaw/agents/onisuzume/agent/models.json
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...3bae32f5 | env=sk-or-v1...3bae32f5 | source=env: OPENROUTER_API_KEY
perplexity effective=env:sk-or-v1...3bae32f5 | env=sk-or-v1...3bae32f5 | source=env: OPENROUTER_API_KEY

OAuth/token status

none

autumn duneBOT Apr 16, 2026, 5:49 PM

#

That last error is a different problem:

Unknown agent id "onisuzume"

So this OpenClaw install does not know that agent.

Also, this looks like a different machine / install than the earlier Fedora one:

earlier logs: /home/openclaw/...
this one: /opt/homebrew/...

So right now you’re probably checking the wrong OpenClaw instance.

Do this on the same machine where `onisuzume` exists

First run:

#

openclaw agents list

If onisuzume is not in that list, you are on the wrong install / wrong host.

For the restart timeout

Also run:

openclaw gateway status --deep
openclaw doctor

So, short version:

make sure you are on the same Fedora/OpenClaw instance

#

run openclaw agents list
only then run:

openclaw models status --agent onisuzume

If you paste openclaw agents list, I can tell immediately whether you’re on the right instance.

#

Nice, that part looks fixed now ✅

The important line changed to:

office effective=models.json:...

So office is no longer missing auth.

Next step

Try the agent again now.

If it still fails after this, then the problem is not auth anymore.
At that point, open a second terminal and run:

#

openclaw logs --follow

Then send one test prompt to onisuzume and paste the new error.

But from this status output, you’ve cleared the auth problem. 🎉

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

trim trench Apr 16, 2026, 5:50 PM

#

Agents:

main (default)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Routing rules: 0
Routing: default (no explicit rules)
Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
Channel status reflects local config/creds. For live health: openclaw channels status --probe.

autumn duneBOT Apr 16, 2026, 5:50 PM

#

Yep, that confirms it.

That Homebrew/macOS install only has:

- main (default)

So it is a different OpenClaw instance from the Fedora one where onisuzume exists.

Meaning:

Fedora instance = the one we should debug for this thread
Homebrew/macOS instance = unrelated here, only has main

So for the original problem, ignore the Homebrew output and keep testing on the Fedora machine, because that’s the one where:

#

Agent dir: ~/.openclaw/agents/onisuzume/agent

exists.

At this point the Fedora auth looks fixed, so the next useful thing is just:

run a real prompt against onisuzume
if it still fails, capture openclaw logs --follow from the Fedora box while it runs

You’re past the auth mismatch now.

trim trench Apr 16, 2026, 5:51 PM

#

giờ tôi phải làm sao tiếp theo step by step fix i

autumn duneBOT Apr 16, 2026, 5:52 PM

#

Ok, làm từng bước như này nhé, trên máy Fedora luôn:

Bước 1: đừng sửa config nữa

Auth của office giờ nhìn đã đúng rồi.

Bước 2: mở terminal số 1 để xem log

openclaw logs --follow

Bước 3: mở terminal số 2 để test agent thật

openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

Bước 4: xem kết quả

Nếu agent trả về OFFICE_OK thì gần như xong rồi ✅

#

Nếu nó lỗi, copy:
1. output của lệnh openclaw agent ...
2. log mới xuất hiện trong terminal openclaw logs --follow

Bước 5: nếu vẫn fail, test mạng tới office Ollama

Từ máy Fedora, chạy:

curl http://IP_OFFICE:11434/api/tags

Nếu có JSON trả về, mạng tới office Ollama ok
Nếu timeout / refused, thì vấn đề là kết nối tới office server, không phải auth nữa

Tóm tắt ngắn

openclaw logs --follow
openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

#

nếu fail thì paste output + log
nếu cần thì curl http://IP_OFFICE:11434/api/tags

Giờ làm Bước 2 + Bước 3 trước, rồi paste kết quả lên đây, mình đọc tiếp cho.

trim trench Apr 16, 2026, 5:53 PM

#

🦞 OpenClaw 2026.4.14 (323493f)
I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /Users/ryanmac/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.

autumn duneBOT Apr 16, 2026, 5:53 PM

#

This one is from another install again:

Config: /Users/ryanmac/.openclaw/openclaw.json
Gateway target: ws://127.0.0.1:18789

So that is the Mac instance, and its gateway is simply not running.

For this thread, ignore the Mac box and keep testing on the Fedora machine where onisuzume exists.

For this thread

Run the test on Fedora, not /Users/ryanmac/....

If you want to fix the Mac instance too

That is a separate issue. Start with:

#

openclaw gateway status --deep
openclaw doctor

But honestly, please open a separate thread for the Mac gateway issue so this one stays about the office Ollama routing/auth problem.

marble harness Apr 16, 2026, 5:53 PM

#

@trim trench Hey why did you post in during I'm fixing the problem ?

autumn duneBOT Apr 16, 2026, 5:53 PM

#

Looks like two different installs got mixed into the same thread, your Fedora box and a separate Mac/Homebrew box.

Let’s ignore the Mac output and finish your Fedora setup only.

Next step on Fedora:

openclaw logs --follow

Then in another terminal:

openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

Paste:

#

the output of that openclaw agent ... command
the new Fedora log lines

We’re close, auth looks fixed now.

marble harness Apr 16, 2026, 5:54 PM

#

it's mixed input from @trim trench and mine may cause @autumn dune confused

#

@autumn dune [openclaw@fedora .openclaw]$ openclaw agents list

🦞 OpenClaw 2026.4.14 (323493f) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Agents:

main (default)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: Home-gemma4
Routing rules: 0
Routing: default (no explicit rules)
onisuzume
Workspace: ~/.openclaw/workspace/onisuzume
Agent dir: ~/.openclaw/agents/onisuzume/agent
Model: office/gemma4:e4b-32k
Routing rules: 0
kamonegi
Workspace: ~/.openclaw/workspace/kamonegi
Agent dir: ~/.openclaw/agents/kamonegi/agent
Model: Home-gemma4
Routing rules: 0
Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
Channel status reflects local config/creds. For live health: openclaw channels status --probe.
[openclaw@fedora .openclaw]$

trim trench Apr 16, 2026, 5:54 PM

#

🦞 OpenClaw 2026.4.14 (323493f) — Greetings, Professor Falken

Gateway agent failed; falling back to embedded: Error: Unknown agent id "onisuzume". Use "openclaw agents list" to see configured agents.
Error: Unknown agent id "onisuzume". Use "openclaw agents list" to see configured agents.

autumn duneBOT Apr 16, 2026, 5:54 PM

#

Yep, exactly 😅 that was the mix-up.

We’re synced again now, your Fedora box only.

Current state on your setup:

agent onisuzume exists
office auth now resolves
next thing to verify is the actual runtime request

So just do these 2 commands on Fedora:

openclaw logs --follow

and in another terminal:

#

openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

Then paste both outputs and I’ll keep it on your path only.

#

Perfect, this confirms your Fedora setup is the right one, and onisuzume is configured correctly.

So now we’ve verified:

agent exists
agent model = office/gemma4:e4b-32k
office auth resolves

Next step, real runtime test

Terminal 1:

openclaw logs --follow

Terminal 2:

#

openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

Then paste:

output from openclaw agent ...
the fresh log lines from openclaw logs --follow

At this point we’re done with config sanity-checking, now we just need the live run result.

#

That output is still from the other install, so it’s expected there.

On that instance, onisuzume does not exist, so this is not useful for the Fedora thread.

For this thread, please only use the Fedora box where:

~/.openclaw/agents/onisuzume/agent

exists.

So the only test that matters now is on Fedora:

openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

#

If Trustworthy777 runs that on Fedora and it still fails, paste the Fedora output + Fedora logs only.

trim trench Apr 16, 2026, 5:55 PM

#

giúp tôi xoá other install and current install, xoá both install để tôi set up lại từ đầu đc k

autumn duneBOT Apr 16, 2026, 5:56 PM

#

I wouldn’t do a blind “delete both installs” from this mixed thread.

Too risky, too easy to wipe the wrong state, and right now we already know the Fedora install is very close to working.

My recommendation:

Do not wipe Fedora yet
Finish the Fedora test first
If you want to reset the Mac/Homebrew install, open a separate #help thread just for that machine

I’m being careful here because “nuke both installs” is the kind of thing that goes sideways fast in a shared thread.

For this thread, stay on the Fedora box and run:

openclaw agent --agent onisuzume --message "Reply with exactly: OFFICE_OK"

#

If you want, after we finish this Fedora issue, I can help you plan a safe clean reinstall in a new thread, one machine at a time.

marble harness Apr 16, 2026, 5:56 PM

#

got new error
form openclaw logs :
17:55:48+00:00 info No API provider registered for api: ollama
17:55:48+00:00 info No API provider registered for api: ollama

###########################

🦞 OpenClaw 2026.4.14 (323493f) — Your .zshrc wishes it could do what I do.

│
◇
No API provider registered for api: ollama
[openclaw@fedora .openclaw]$

trim trench Apr 16, 2026, 5:57 PM

#

k cần giúp tôi uninstall for both đi

autumn duneBOT Apr 16, 2026, 5:58 PM

#

Okay, now we’ve hit the real root cause.

Auth is fixed.
This new error means:

No API provider registered for api: ollama

So the problem is not credentials anymore. It’s that your custom provider id office is not getting the native Ollama runtime attached.

What that means

On 2026.4.14, native:

api: "ollama"

#

appears to work for the built-in provider id ollama, but not for a custom provider id like office.

So this setup:

models.providers.office.api = "ollama"

is the thing that’s breaking at runtime.

Best options now

Option 1, recommended

Use separate OpenClaw installs/gateways, one per Ollama endpoint.

Why: most reliable, least weirdness.

#

Option 2, workaround

Make the second endpoint (office) use Ollama’s OpenAI-compatible endpoint instead:

baseUrl: "http://OFFICE_IP:11434/v1"
api: "openai-completions"

But warning: tool calling is less reliable there. The Ollama docs specifically warn about this.

Option 3

File a bug, because this looks like a real limitation/bug in current OpenClaw:
https://github.com/openclaw/openclaw/issues

My recommendation

Don’t keep fighting the current office + api:"ollama" setup.

I’d either:

split into 2 installs, or

#

if you want, I can help you rewrite office as an OpenAI-compatible /v1 provider right now as a workaround.

If you want, I can give you the exact config block for Option 2 next.

marble harness Apr 16, 2026, 5:58 PM

#

trim trench k cần giúp tôi uninstall for both đi

@trim trench you should create new post better than make it mixed up like this

autumn duneBOT Apr 16, 2026, 5:58 PM

#

Mình không muốn đưa lệnh xoá cả 2 install ngay trong thread đang bị trộn 2 máy như này, quá dễ xoá nhầm.

Làm an toàn hơn nhé:

mở thread mới
xử lý 1 máy một lần
backup ~/.openclaw trước
rồi mới uninstall / clean reinstall

Nếu bạn muốn, mở thread mới cho:

Fedora uninstall
hoặc macOS/Homebrew uninstall

và mình sẽ viết step by step cho đúng từng máy.
Còn trong thread này, mình không muốn đưa lệnh xoá hàng loạt lung tung.

#

Yep, that’s the better move.

Keeping this thread focused on your Fedora setup is the right call.

For your original issue, we’ve narrowed it down pretty hard:

auth is fixed
agent config is correct
the blocker is the native office + api:"ollama" runtime path on 2026.4.14

So your realistic next moves are:

separate installs/gateways for home and office, or
I write you the /v1 OpenAI-compatible workaround config for the office server here

If you want, I can give you Option 2 as a copy-paste config block next.

trim trench Apr 16, 2026, 6:00 PM

#

không sao cứ xoá hết đi

autumn duneBOT Apr 16, 2026, 6:00 PM

#

Mình vẫn không đưa lệnh xoá hết trong thread này nhé.

Lý do đơn giản:

đang bị trộn 2 máy / 2 install
lệnh xoá nhầm là mất sạch state luôn
thread này vốn đang là của người khác

Nếu muốn làm thật, mở thread mới riêng cho uninstall, ghi rõ:

máy nào: Fedora hay macOS/Homebrew
muốn xoá: config only hay clean reinstall toàn bộ

Rồi mình sẽ viết đúng lệnh cho từng máy.
Nhưng không phải “xoá hết” mù trong thread này.

marble harness Apr 16, 2026, 6:08 PM

#

any other workaround ?

autumn duneBOT Apr 16, 2026, 6:09 PM

#

Yeah, but only a few practical ones.

Workarounds

1. Two OpenClaw installs, one per Ollama server

Best / most reliable

home install → built-in ollama provider → home Ollama
office install → built-in ollama provider → office Ollama

This is the cleanest if you want native Ollama behavior.

2. Use the office server as OpenAI-compatible

Works, but less reliable for tools

For office, switch to:

#

office: {
  baseUrl: "http://OFFICE_IP:11434/v1",
  api: "openai-completions",
  apiKey: "office-local-key",
  injectNumCtxForOpenAICompat: true,
  models: [
    {
      id: "gemma4:e4b-32k",
      name: "gemma4:e4b-32k"
    }
  ]
}

Keep the agent model as:

#

office/gemma4:e4b-32k

But warning: native tool calling is weaker on /v1.
The Ollama docs warn about this too: https://docs.openclaw.ai/providers/ollama

3. One install, one native Ollama at a time

Ugly but simple

Only keep the built-in ollama provider and manually change its baseUrl between home and office when needed, then restart the gateway.

That means no true simultaneous “home agent + office agent” though.

My recommendation

if you need reliability: do Option 1
if you just want to get unstuck fast: do Option 2

#

If you want, I can write the exact Option 2 config block for your current openclaw.json.

marble harness Apr 16, 2026, 6:11 PM

#

i used to check with curl to /v1 before it return 404

autumn duneBOT Apr 16, 2026, 6:12 PM

#

Yep, if /v1 returns 404, then the OpenAI-compatible workaround won’t work on that endpoint.

So that leaves you with basically:

1. Separate OpenClaw installs

Most realistic option right now.

2. Put an OpenAI-compatible proxy in front of the office Ollama

For example something like LiteLLM, then point OpenClaw at the proxy instead of raw Ollama.

Because if raw office Ollama gives:

/v1 -> 404

then OpenClaw cannot use the /v1 fallback path there.

#

So at this point I’d say:

native custom office + api:"ollama" → broken on your version
/v1 workaround → unavailable because endpoint returns 404

That really makes separate installs the safest workaround for now.

If you want, I can help you design the 2-install layout cleanly so home and office don’t step on each other.

marble harness Apr 16, 2026, 6:13 PM

#

If I want to continue this tomorrow (here it's late night) do i have to close this post first ?

autumn duneBOT Apr 16, 2026, 6:13 PM

#

Nope, you don’t have to close it.

If it’s the same issue, you can continue here tomorrow just fine. Get some sleep 😄

Only make a new post if:

it turns into a different problem, or
you want help with the separate Mac/Homebrew install

And if we solve this tomorrow, please mark the solution so it gets indexed on Answer Overflow.

marble harness Apr 16, 2026, 6:14 PM

#

what if use 1 agent with ollama and another with other local model provider not ollama ?

autumn duneBOT Apr 16, 2026, 6:14 PM

#

Yes, that should be much more likely to work.

Your current problem looks specific to:

built-in ollama provider working
second custom provider also using api: "ollama" breaking

So this is a better shape:

Agent A → ollama/...
Agent B → some other local provider (lmstudio, OpenAI-compatible local server, etc.)

That avoids the “two native Ollama endpoints in one install” problem.

So, short answer:

1 Ollama + 1 different local provider → yes, reasonable

#

2 separate native Ollama-style providers in one install → this is the part that looks broken on your version

If you want, tomorrow I can help you sketch a clean setup like:

main → home Ollama
onisuzume → LM Studio / other local provider

Docs:

icy anchorBOT Apr 16, 2026, 6:17 PM

#

ebon warren Apr 19, 2026, 4:36 PM

#

summar

autumn duneBOT Apr 19, 2026, 4:36 PM

#

Summary:

Goal was 1 OpenClaw install with 2 agents, each pointing to a different Ollama endpoint, home + office.
There was some confusion because logs from a separate Mac/Homebrew install got mixed into the thread. The real setup was the Fedora one.
We fixed the auth/profile mistakes for the custom office provider:
- removed broken office auth profile entries
- stopped using ollama-local as the custom provider key
- got office auth to resolve in openclaw models status
After auth was fixed, the real blocker showed up:

No API provider registered for api: ollama

Conclusion

On 2026.4.14, a custom provider id like office using:

#Agent wont use specific model

Simplest fix

Why

If you want to keep auth profiles instead

Bước 1: sửa ~/.openclaw/openclaw.json

Bước 2: xóa office:default khỏi auth.profiles

Bước 3: sửa ~/.openclaw/agents/onisuzume/agent/auth-profiles.json

Bước 4: restart gateway

Bước 5: kiểm tra lại

Bước 6: test agent lại

Nếu vẫn lỗi

Do this instead

What should change

Do this on the same machine where onisuzume exists

For the restart timeout

Next step

Bước 1: đừng sửa config nữa

Bước 2: mở terminal số 1 để xem log

Bước 3: mở terminal số 2 để test agent thật

Bước 4: xem kết quả

Bước 5: nếu vẫn fail, test mạng tới office Ollama

Tóm tắt ngắn

For this thread

If you want to fix the Mac instance too

Next step, real runtime test

What that means

Best options now

Option 1, recommended

Option 2, workaround

Option 3

My recommendation

Workarounds

1. Two OpenClaw installs, one per Ollama server

2. Use the office server as OpenAI-compatible

3. One install, one native Ollama at a time

My recommendation

1. Separate OpenClaw installs

2. Put an OpenAI-compatible proxy in front of the office Ollama

Conclusion

Bước 1: sửa `~/.openclaw/openclaw.json`

Bước 2: xóa `office:default` khỏi `auth.profiles`

Bước 3: sửa `~/.openclaw/agents/onisuzume/agent/auth-profiles.json`

Do this on the same machine where `onisuzume` exists