I am using a combo of minimax and Claude-sonnet-4-xxx | Friends of the Crustacean 🦞🤝 | Page 1

reef siloBOT Feb 26, 2026, 6:47 PM

#

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

steep tangleBOT Feb 26, 2026, 6:48 PM

#

Most common cause: your “2nd agent” doesn’t actually have Anthropic creds / model defaults, so when it tries Claude it can’t authenticate (or the model id isn’t allowed), and it falls back to whatever is available (your MiniMax setup) — which looks like “it keeps reverting”.

A few quick checks to pinpoint which case you’re in:

Version first (matters for config semantics)

openclaw --version

Are you talking about a real 2nd configured agent, or a spawned sub-agent?

If you created it via openclaw agents add ... → it’s a separate agent.
If you mean “the subagent I spawn in chat” → that’s controlled separately (see #5 below).

Verify routing: are messages even hitting the 2nd agent?

openclaw agents list --bindings

#

If the binding for this Discord channel/thread/account still points at main, you’ll always get the main agent (MiniMax), no matter what you set on the other agent.

Docs: https://docs.openclaw.ai/concepts/multi-agent

Verify what model + auth the 2nd agent resolves to

openclaw models status --agent <yourSecondAgentId>

If this shows missing Anthropic auth for that agent, that’s your answer: auth profiles are per-agent (~/.openclaw/agents/<agentId>/agent/auth-profiles.json), not shared automatically. (FAQ calls this out explicitly.)

Docs: https://docs.openclaw.ai/help/faq (search “No API key found for provider after adding a new agent”)

If you meant “sub-agent” (spawned worker), not “2nd agent”
Then check what you set for subagents — they can have their own default model:

Config key: agents.defaults.subagents.model (so your main chat can be cheap, subagents can be Claude, or vice versa).

Docs: https://docs.openclaw.ai/help/faq (section on sub-agents) + https://docs.openclaw.ai/tools/subagents

#

If you changed config but it “doesn’t stick” after restart
Double-check you’re editing the same config the service is running:

openclaw gateway status

If it shows Config (cli) and Config (service) diverging, you’re updating the wrong file/profile.

If you paste the output of:

openclaw --version
openclaw agents list --bindings
openclaw models status --agent <secondAgentId>

…I can tell you exactly which of the above it is and what to change (no secrets needed—just redact tokens).

drifting isle Feb 26, 2026, 6:55 PM

#

/Users/jhat/.openclaw/completions/openclaw.zsh:3719: command not found: compdef
jhat@Jhats-Mac-mini ~ % openclaw models status --agent <workerbee>
zsh: parse error near `\n'
jhat@Jhats-Mac-mini ~ % agents.defaults.subagents.model
zsh: command not found: agents.defaults.subagents.model

steep tangleBOT Feb 26, 2026, 6:57 PM

#

Two separate things going on there: zsh syntax + OpenClaw config paths.

1) `openclaw models status --agent <workerbee>` → zsh parse error

<workerbee> in docs is a placeholder. In zsh, < is treated like input-redirection, so you get a parse error.

Use your real agent id without angle brackets, e.g.:

openclaw agents list --bindings
openclaw models status --agent workerbee

(Replace workerbee with whatever agents list shows.)

2) `agents.defaults.subagents.model` → “command not found”

That’s a config path, not a shell command.

#

To read/set it, use openclaw config:

openclaw config get agents.defaults.subagents
# (or, if it exists in your version)
openclaw config get agents.defaults.subagents.model

To change it:

openclaw config set agents.defaults.subagents.model "anthropic/claude-sonnet-4-5"
openclaw gateway restart

3) `/Users/jhat/.openclaw/completions/openclaw.zsh: … compdef`

That’s just your zsh completions being sourced before zsh completion is initialized. Fix in ~/.zshrc by ensuring compinit runs before sourcing that file:

#

autoload -Uz compinit
compinit
source /Users/jhat/.openclaw/completions/openclaw.zsh

(or comment out the source ...openclaw.zsh line if you don’t care about completions.)

If you paste the output of these two (redact tokens if any show up):

openclaw agents list --bindings
openclaw models status --agent workerbee

…I can tell you whether the “revert to mini” is actually:

the Discord channel/thread still bound to the main agent, or

#

the worker agent is missing Anthropic auth (so it silently falls back), or
it’s a sub-agent default model issue.

drifting isle Feb 26, 2026, 7:00 PM

#

jhat@Jhats-Mac-mini ~ % openclaw models status --agent workerbee

🦞 OpenClaw 2026.2.25 (4b5d4a4)
I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

18:58:53 [model-selection] Model "claude-sonnet-4-20250514" specified without provider. Falling back to "anthropic/claude-sonnet-4-20250514". Please use "anthropic/claude-sonnet-4-20250514" in your config.
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/workerbee/agent
Default (agent): anthropic/claude-sonnet-4-20250514 (from claude-sonnet-4-20250514)
Fallbacks (0) (defaults): -
Image model (defaults): -
Image fallbacks (0) (defaults): -
Aliases (1) : Minimax -> minimax/MiniMax-M2.5
Configured models (2): minimax/MiniMax-M2.5, anthropic/claude-sonnet-4-20250514

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

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-ant-a...kzQU5gAA | models.json=sk-ant-a...kzQU5gAA | source=models.json: ~/.openclaw/agents/workerbee/agent/models.json
minimax effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | minimax:default=sk-cp-Tn...rEE8UUDM

OAuth/token status

none

steep tangleBOT Feb 26, 2026, 7:01 PM

#

That output is actually good news: it shows workerbee’s default model is Claude, not MiniMax.

Key lines:

Default (agent): anthropic/claude-sonnet-4-20250514
Fallbacks (0) (so it shouldn’t “silently” fall back to MiniMax on errors)

So if you’re seeing MiniMax in practice, it’s almost always one of these:

A) You’re not actually talking to the `workerbee` agent (routing/binding issue)

Your Discord channel/thread may still be bound to main, so you get MiniMax even though workerbee is configured correctly.

Run on the gateway host:

openclaw agents list --bindings

#

and confirm the binding for your Discord channel/account points to workerbee.

B) The Discord session is “pinned” to MiniMax via a session override (`/model`)

Even if the agent default is Claude, the session can be set to MiniMax and will stay there until you change/reset it.

In the Discord thread where it “reverts”, run:

/model status
then (if needed) /model anthropic/claude-sonnet-4-20250514
or just /new to fully reset the thread’s session

C) Minor: fix the config warning (won’t cause reverting, but do it anyway)

You have claude-sonnet-4-20250514 without provider. Set it explicitly so you stop getting:

“specified without provider… falling back to anthropic/…”

Use:

#

openclaw config set agents.list[INDEX].model "anthropic/claude-sonnet-4-20250514"
openclaw gateway restart

(First get the index with openclaw config get agents.list.)

If you paste:

openclaw agents list --bindings
the Discord output of /model status from the thread where it happens

…I can tell you immediately whether it’s (A) routing or (B) session override.

drifting isle Feb 26, 2026, 7:03 PM

#

jhat@Jhats-Mac-mini ~ % openclaw agents list --bindings

🦞 OpenClaw 2026.2.25 (4b5d4a4) — Type the command with confidence—nature will provide the stack trace if needed.

Agents:

main (default)
Identity: 🦊 Fred (IDENTITY.md)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: minimax/MiniMax-M2.5
Routing rules: 0
Routing: default (no explicit rules)
workerbee (WorkerBee)
Workspace: ~/.openclaw/workspace-workerbee
Agent dir: ~/.openclaw/agents/workerbee/agent
Model: claude-sonnet-4-20250514
Routing rules: 1
Routing rules:
- 1476073500430041252
  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.

#

Current: anthropic/claude-sonnet-4-20250514 (selected)
Active: minimax/MiniMax-M2.5 (runtime)
Default: anthropic/claude-sonnet-4-20250514
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[anthropic] endpoint: https://api.anthropic.com/ api: anthropic-messages auth: anthropic:default=sk-ant-a...N48bjQAA (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• anthropic/claude-sonnet-4-20250514

[minimax] endpoint: https://api.minimax.io/anthropic api: anthropic-messages auth: minimax:default=sk-cp-Tn...rEE8UUDM (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• minimax/MiniMax-M2.5 (Minimax)

steep tangleBOT Feb 26, 2026, 7:05 PM

#

That explains it: workerbee is bound to a different Discord channel/thread ID than the one you’re chatting in.

From your output:

workerbee routing rule: 1476073500430041252
This Discord thread/channel (from the thread header you pasted) is: 1476651790366802053

So when you talk in 147665…, routing doesn’t match workerbee, and you fall back to the default agent main → which is MiniMax. Nothing is “reverting”; you’re just not hitting the workerbee binding.

Fix

Edit ~/.openclaw/openclaw.json and update/add a binding for the channel/thread you actually want workerbee to own.

You want something like:

bindings: [

#

  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      peer: { kind: "channel", id: "1476651790366802053" },
    },
  },

  // optional: everything else stays on main
  // { agentId: "main", match: { channel: "discord" } },
]

Then:

#

openclaw gateway restart

(If you want workerbee only for this thread, bind the thread id; if you want it for the whole Discord channel + all its threads, bind the parent channel id.)

Quick sanity check (in Discord)

In the thread where it “reverts”, run:

/status (should show which agent you’re on)
/model status (should show which model is active)

Once the binding is right, those should show workerbee + Claude consistently.

Also: your workerbee model is configured as claude-sonnet-4-20250514 without provider — not fatal, but clean it up to anthropic/claude-sonnet-4-20250514 to remove the warning.

#

Your /model status output is the smoking gun:

Agent: main
Active: minimax/MiniMax-M2.5 (runtime)

So in this thread you’re not hitting workerbee at all — you’re still routed to main, which is why it “keeps going back to mini”.

And your binding confirms the mismatch:

workerbee is currently bound to 1476073500430041252
but this channel/thread you’re chatting in is 1476651790366802053

Fix: bind `workerbee` to the channel/thread you actually use

Edit ~/.openclaw/openclaw.json and add/update a binding for the right Discord peer id (1476651790366802053), then restart the gateway.

Example:

#

bindings: [
{
agentId: "workerbee",
match: {
channel: "discord",
peer: { kind: "channel", id: "1476651790366802053" },
},
},
]

Then:

openclaw gateway restart

#

After restart, in this Discord thread run /status (or /model status) again — it should show Agent: workerbee.

One more thing: “Current=Claude, Active=MiniMax”

That specific combo usually means Claude was selected but failed at runtime, so it fell back. Once the binding is fixed, if you still see “Active minimax”, tail logs while sending a message:

openclaw logs --follow

and you’ll likely see an Anthropic error (often 429/rate limit, auth, etc.) explaining why it failed over.

drifting isle Feb 26, 2026, 7:12 PM

#

Current: minimax/MiniMax-M2.5
Default: minimax/MiniMax-M2.5
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[anthropic] endpoint: https://api.anthropic.com/ api: anthropic-messages auth: anthropic:default=sk-ant-a...N48bjQAA (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• anthropic/claude-sonnet-4-20250514

[minimax] endpoint: https://api.minimax.io/anthropic api: anthropic-messages auth: minimax:default=sk-cp-Tn...rEE8UUDM (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• minimax/MiniMax-M2.5 (Minimax)

steep tangleBOT Feb 26, 2026, 7:13 PM

#

That last /model status is consistent: you’re still in Agent: main, and in that session you’ve now explicitly set:

Current: minimax/MiniMax-M2.5
Default: minimax/MiniMax-M2.5

So nothing is “reverting” — you’re just still routed to main in this thread.

The root issue is the binding mismatch we saw earlier:

workerbee is currently routed to 1476073500430041252
but the place you’re chatting is 1476651790366802053

Fix (routing): bind this channel/thread id to `workerbee`

On the gateway host, edit ~/.openclaw/openclaw.json and add (or change) a binding like:

#

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      peer: { kind: "channel", id: "1476651790366802053" },
    },
  },
]

Then restart:

openclaw gateway restart

#

Verify

Back in this Discord thread, run:

/model status

You should see:

Agent: workerbee
and Current/Default should be Claude (from workerbee’s defaults)

If it still shows Agent: main, the binding didn’t load (wrong config file/profile, or you edited the wrong place).

Once it’s working and stable, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

drifting isle Feb 26, 2026, 7:14 PM

#

this is what the .json file show. I have restarted the gateway "bindings": [
{
"agentId": "workerbee",
"match": {
"channel": "1476651790366802053"
}
}
],

steep tangleBOT Feb 26, 2026, 7:15 PM

#

Yep — that binding is shaped wrong.

In bindings, match.channel is the provider name (e.g. "discord"), not the Discord channel id. The Discord channel/thread id goes under match.peer.id.

Use this instead:

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      peer: { kind: "channel", id: "1476651790366802053" },
    },
  },
]

#

Then:

openclaw gateway restart
openclaw agents list --bindings

And in the Discord thread run:

/model status

You should see Agent: workerbee.

If it still shows Agent: main, paste the new openclaw agents list --bindings output — sometimes people are editing a different profile/config than the service is actually running.

drifting isle Feb 26, 2026, 7:16 PM

#

jhat@Jhats-Mac-mini ~ % openclaw gateway restart
Failed to read config at /Users/jhat/.openclaw/openclaw.json SyntaxError: JSON5: invalid character '"' at 134:3
at syntaxError (/opt/homebrew/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:1110:17)
at invalidChar (/opt/homebrew/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:1055:12)
at Object.afterPropertyValue (/opt/homebrew/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:676:15)
at Object.default (/opt/homebrew/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:168:37)
at lex (/opt/homebrew/lib/node_modules/openclaw/node_modules/json5/lib/parse.js💯42)
at Object.parse (/opt/homebrew/lib/node_modules/openclaw/node_modules/json5/lib/parse.js:25:17)
at Object.loadConfig (file:///opt/homebrew/lib/node_modules/openclaw/dist/config-BEQvFIpK.js:8070:111)
at loadConfig (file:///opt/homebrew/lib/node_modules/openclaw/dist/config-BEQvFIpK.js:8507:20)
at file:///opt/homebrew/lib/node_modules/openclaw/dist/session-utils-BcQu-YrK.js:42:9
at file:///opt/homebrew/lib/node_modules/openclaw/dist/session-utils-BcQu-YrK.js:62:3 {
lineNumber: 134,
columnNumber: 3
}

steep tangleBOT Feb 26, 2026, 7:18 PM

#

That error means your config file is currently invalid JSON5, so nothing can restart until we fix ~/.openclaw/openclaw.json.

The parser is telling you exactly where:

line 134, column 3
invalid character '"'

That usually happens when a line like "bindings": [ got pasted in a spot where JSON5 wasn’t expecting a new key (most commonly: missing a comma above, or pasted outside the top-level { ... }).

1) Show the broken area (paste this output here)

Run:

nl -ba ~/.openclaw/openclaw.json | sed -n '125,145p'

That will print line numbers; we can spot the exact syntax problem immediately.

#

2) What the `bindings` block should look like (valid shape)

Make sure it’s a top-level key and that match.channel is "discord" (not the numeric id):

{
  // ... agents, channels, etc ...

  bindings: [
    {
      agentId: "workerbee",
      match: {
        channel: "discord",
        peer: { kind: "channel", id: "1476651790366802053" },
      },
    },
  ],

#

Important details:

There must be a comma after the previous top-level section before bindings.
channel: "discord" is the provider name; the Discord id goes under peer.id.

3) After you fix the syntax

Run:

openclaw gateway restart

Paste the nl -ba … snippet and I’ll tell you the exact edit to make on line 134.

drifting isle Feb 26, 2026, 7:19 PM

#

jhat@Jhats-Mac-mini ~ % nl -ba ~/.openclaw/openclaw.json | sed -n '125,145p'
125 bindings: [
126 {
127 agentId: "workerbee",
128 match: {
129 channel: "discord",
130 peer: { kind: "channel", id: "1476651790366802053" },
131 },
132 },
133 ]
134 "messages": {
135 "ackReactionScope": "group-mentions"
136 },
137 "commands": {
138 "native": "auto",
139 "nativeSkills": "auto",
140 "restart": true,
141 "ownerDisplay": "raw"
142 },
143 "channels": {
144 "discord": {
145 "enabled": true,

steep tangleBOT Feb 26, 2026, 7:20 PM

#

Line 133 is the problem: you’re missing a comma between the top-level bindings block and the next top-level key ("messages").

Change this:

    ]
      "messages": {

to this:

    ],
    "messages": {

So literally: add a comma after the closing ] on line 133.

#

Then rerun:

openclaw gateway restart

After it restarts, sanity check routing:

openclaw agents list --bindings

(And optional cleanup while you’re in there: set workerbee’s model to "anthropic/claude-sonnet-4-20250514" to remove the “specified without provider” warning.)

drifting isle Feb 26, 2026, 7:23 PM

#

jhat@Jhats-Mac-mini ~ % openclaw agents list --bindings

🦞 OpenClaw 2026.2.25 (4b5d4a4) — Meta wishes they shipped this fast.

Agents:

main (default)
Identity: 🦊 Fred (IDENTITY.md)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: minimax/MiniMax-M2.5
Routing rules: 0
Routing: default (no explicit rules)
workerbee (WorkerBee)
Workspace: ~/.openclaw/workspace-workerbee
Agent dir: ~/.openclaw/agents/workerbee/agent
Model: claude-sonnet-4-20250514
Routing rules: 1
Routing rules:
- discord peer=channel:1476651790366802053
  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.

steep tangleBOT Feb 26, 2026, 7:24 PM

#

Perfect — that’s now correct:

workerbee has a routing rule: discord peer=channel:1476651790366802053

So messages in that Discord channel/thread should now route to workerbee, not main.

Final verification (in Discord)

In the same Discord thread/channel, run:

/model status

You should see:

Agent: workerbee
and Current/Default = Claude Sonnet

If you still see Agent: main, the only remaining gotcha is: you might be chatting in a different thread/channel than 1476651790366802053 (Discord has parent channel vs thread ids). If that happens, paste the /model status output and the channel/thread id you’re in, and we’ll bind the correct peer.id.

#

Also: optional cleanup — set workerbee’s model with provider prefix to remove the warning:
anthropic/claude-sonnet-4-20250514.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed.

drifting isle Feb 26, 2026, 7:25 PM

#

OpenclawBot
APP
— 12:25 PMThursday, February 26, 2026 at 12:25 PM
Current: minimax/MiniMax-M2.5
Default: minimax/MiniMax-M2.5
Agent: main
Auth file: ~/.openclaw/agents/main/agent/auth-profiles.json

[anthropic] endpoint: https://api.anthropic.com/ api: anthropic-messages auth: anthropic:default=sk-ant-a...N48bjQAA (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• anthropic/claude-sonnet-4-20250514

[minimax] endpoint: https://api.minimax.io/anthropic api: anthropic-messages auth: minimax:default=sk-cp-Tn...rEE8UUDM (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/main/agent/auth-profiles.json)
• minimax/MiniMax-M2.5 (Minimax)

steep tangleBOT Feb 26, 2026, 7:26 PM

#

That /model status output is still coming from the old running Gateway config (still routed to main).

Key point: openclaw agents list --bindings only proves the file on disk is correct. It does not prove the running Gateway service has reloaded it — and earlier your gateway restart was failing due to the JSON5 syntax error, so the service likely never restarted with the new bindings.

1) Restart the Gateway now that the config parses

Run:

openclaw gateway restart
openclaw gateway status

Make sure gateway status shows it’s running cleanly (and ideally that the service is using the same config path you edited).

2) Re-check in Discord

In the same Discord thread, run:

#

/model status

You should now see:

Agent: workerbee

3) If it STILL shows `Agent: main` after a successful restart

Then you’re binding the wrong Discord “peer id” (common with threads):

The ID you need is the thread/channel ID, not a message ID.
In Discord: enable Developer Mode → right‑click the thread/channel → Copy ID.
Put that ID into:

bindings: [
  {

#

    agentId: "workerbee",
    match: {
      channel: "discord",
      peer: { kind: "channel", id: "PASTE_THREAD_OR_CHANNEL_ID_HERE" },
    },
  },
]

Restart again.

(Optional cleanup)

Workerbee’s model is currently set without a provider (claude-sonnet-4-...). Change it to the explicit form to avoid warnings:

"anthropic/claude-sonnet-4-20250514"

#

If you paste the output of openclaw gateway status after the restart, I can tell you immediately whether the service actually picked up the updated config.

drifting isle Feb 26, 2026, 7:28 PM

#

jhat@Jhats-Mac-mini ~ % openclaw gateway status

🦞 OpenClaw 2026.2.25 (4b5d4a4) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-26.log
Command: /opt/homebrew/Cellar/node@22/22.22.0/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=auto (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/

Runtime: running (pid 27982, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

steep tangleBOT Feb 26, 2026, 7:31 PM

#

Config-wise you’re good now — the Gateway is reading the file you edited (your gateway status shows Config (service): ~/.openclaw/openclaw.json) and agents list --bindings shows the rule.

So if /model status in Discord still says Agent: main, it means the incoming Discord event is not matching that binding. The usual culprits are:

1) Wrong ID (thread id vs parent channel id)

Discord threads have their own channel id.

Do this in Discord:

Settings → Advanced → Developer Mode ON
Right‑click the thread you’re typing in → Copy ID
Right‑click the parent channel → Copy ID

Then either bind the thread id, or bind the parent (and let “parentPeer inheritance” catch all threads).

Easiest: add both bindings:

#

bindings: [
  // thread id (exact)
  {
    agentId: "workerbee",
    match: { channel: "discord", accountId: "*", peer: { kind: "channel", id: "THREAD_ID_HERE" } },
  },

  // parent channel id (covers threads via parentPeer)
  {
    agentId: "workerbee",
    match: { channel: "discord", accountId: "*", peer: { kind: "channel", id: "PARENT_CHANNEL_ID_HERE" } },
  },
]

2) AccountId mismatch (this one is sneaky)

#

If you have channels.discord.accounts.<something> and your bot account isn’t literally default, then a binding without accountId only matches the default account.

So I recommend keeping accountId: "*" in the binding (as above) unless you’re intentionally routing per-bot.

3) Thread is “focused”/bound to a main session

If thread bindings are enabled and the thread was previously /focus’d, it can override routing.

In the thread, try:

/agents (shows binding state)
/unfocus

If you paste the thread ID and parent channel ID (the two “Copy ID” values), I’ll tell you exactly which one to bind (or whether it’s an accountId issue).

drifting isle Feb 26, 2026, 7:33 PM

#

workerbee channel id: 1476073500430041252

#

parent channel id: 1475198339954901087

steep tangleBOT Feb 26, 2026, 7:35 PM

#

1476073500430041252 is very likely the parent channel (where threads live), while the thing you’re chatting inside is a thread channel id (different ID).

Two reliable ways to route Discord threads:

Option A (recommended): bind the parent channel → all threads inherit

Add a binding for the parent channel id you just posted:

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      accountId: "*",
      peer: { kind: "channel", id: "1476073500430041252" },
    },

#

  },
]

Restart:

openclaw gateway restart

Option B: bind a single thread

Bind the thread’s own id (it changes per thread), e.g. 1476651790366802053.

One more “why is it still main?” gotcha: thread is pinned via `/focus`

#

If thread bindings are on and that thread was previously focused to main, it can override routing.

In the Discord thread, run:

/unfocus
then /model status again

If it still says Agent: main, paste:

the /model status output
the thread ID (right‑click the thread → Copy ID)
and confirm whether you have multiple Discord bot accounts configured (accountId not default)

drifting isle Feb 26, 2026, 7:35 PM

#

OpenclawBot
APP
— 12:34 PMThursday, February 26, 2026 at 12:34 PM
agents:

workerbee (thread:1476648657792008346)

steep tangleBOT Feb 26, 2026, 7:36 PM

#

Gateway status looks clean (service + CLI both using ~/.openclaw/openclaw.json, RPC probe ok), and openclaw agents list --bindings shows the binding exists — so if Discord still says Agent: main, one of these is true:

1) The thread is “focused”/bound to `main` (overrides bindings)

This is the most common “why is it still main?” after bindings are fixed.

In the Discord thread, run:

/agents (shows binding/focus state)
/unfocus
then /model status again

If it was focused, /unfocus should immediately make it route by bindings again.

2) You bound the wrong ID (category vs parent channel vs thread)

For routing, the IDs that matter are:

Thread ID (the thing you’re typing inside)
Parent channel ID (the channel the thread belongs to)

#

The category ID doesn’t help.

You posted parent channel id: 1475198339954901087 — if that’s the actual parent channel (not the category), you can bind to it and let thread parent inheritance route all threads:

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      accountId: "*",
      peer: { kind: "channel", id: "1475198339954901087" },
    },
  },
]

#

Restart gateway after changing config.

Quick diagnostic (proves whether bindings are being used at all)

Temporarily add a catch‑all rule (routes ALL Discord to workerbee):

bindings: [
  { agentId: "workerbee", match: { channel: "discord", accountId: "*" } },
]

If /model status STILL says Agent: main after that, then it’s almost certainly (1) focused thread binding (needs /unfocus), not an ID problem.

Post the output of /agents from that Discord thread and I’ll tell you which case you’re in.

#

Nice — that /agents output tells us the actual thread id you’re talking in is:

thread: 1476648657792008346

That’s why your earlier binding to 1476651790366802053 didn’t take effect: it was the wrong channel/thread ID.

Fix: bind this thread (or bind the parent channel)

Add a binding for the real thread id (and I’d include accountId: "*" to avoid “default account” mismatches):

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      accountId: "*",

#

      peer: { kind: "channel", id: "1476648657792008346" },
    },
  },
]

Then:

openclaw gateway restart

Verify (in the same thread)

Run:

/model status

#

It should now say Agent: workerbee.

If it still says `Agent: main`

That means the thread is “pinned” via thread bindings (focused) to main. In the thread run:

/unfocus
then /model status again

If this fixed it, please right-click the solution → Apps → ✅ Mark Solution so it gets indexed.

drifting isle Feb 26, 2026, 7:37 PM

#

/unfocus must be run inside a Discord thread.

#

this was the output

steep tangleBOT Feb 26, 2026, 7:38 PM

#

Can you paste the actual output text? Your message just says “this was the output” but the output itself didn’t come through.

The two most useful ones right now (run them in the Discord thread and in your terminal) are:

In the Discord thread:

/model status
/agents (again)

In terminal (after you restart the gateway):

openclaw agents list --bindings

Once I see those, I can tell whether:

the thread is now routed to workerbee, or
it’s still main (usually wrong thread ID or a focused thread binding that needs /unfocus).

drifting isle Feb 26, 2026, 7:38 PM

#

unfocus must be run inside a Discord thread.

#

unfocus must be run inside a Discord thread.

steep tangleBOT Feb 26, 2026, 7:40 PM

#

That error just means you ran /unfocus somewhere that Discord doesn’t consider a thread (usually the parent channel, not the actual thread view).

What to do

Click into the thread itself in Discord (it should have its own message view — usually shown as a “thread” pill / title above the messages).
In that thread message box, send exactly (standalone):

/unfocus

If you can’t (or don’t want to) mess with /unfocus, you don’t actually need it for this issue — routing via bindings is the real fix.

Also: you probably bound the wrong ID

Earlier your /agents output showed the actual thread you’re chatting in is:

thread: 1476648657792008346

#

So make sure your config binds that (or the correct parent channel), e.g.:

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      accountId: "*",
      peer: { kind: "channel", id: "1476648657792008346" },
    },
  },
]

Then:

#

openclaw gateway restart

Quick check

In the same place you’re chatting, run:

/agents

If it shows thread:<some id>, you’re in a thread; then /unfocus should work there. If /agents shows no thread:..., you’re not in a thread view.

drifting isle Feb 26, 2026, 7:48 PM

#

I figured it out. I was looking in a channel named "workerbee", but there is an attached thread, also named "workerbee" as soon as I opened the thread, it came back with the correct model status.

steep tangleBOT Feb 26, 2026, 7:48 PM

#

That makes total sense — Discord’s UI is brutal here because the parent channel and the thread can have the same name, but OpenClaw routes them as different peers (different IDs → different sessions/agents).

Glad you found it.

If you want it to be bulletproof going forward, the two best practices are:

Always bind using the ID (right‑click → Copy ID) rather than the name.
If you want “everything under this channel including threads” to go to workerbee, bind the parent channel id (thread parent inheritance will pick it up).

If this fixed it, please right‑click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.

drifting isle Feb 26, 2026, 7:48 PM

#

how do I do this? If you want “everything under this channel including threads” to go to workerbee, bind the parent channel id (thread parent inheritance will pick it up).

steep tangleBOT Feb 26, 2026, 7:49 PM

#

Bind the parent channel ID in ~/.openclaw/openclaw.json (not the thread ID).

Step 1: Get the parent channel ID (Discord)

In Discord, enable Developer Mode:
User Settings → Advanced → Developer Mode
Right‑click the parent channel (the one that contains the threads) → Copy ID.

Step 2: Add a binding for that parent channel ID

Edit ~/.openclaw/openclaw.json and add (or change) your binding to use that ID:

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",

#

      accountId: "*",
      peer: { kind: "channel", id: "PASTE_PARENT_CHANNEL_ID_HERE" },
    },
  },
]

Notes:

channel: "discord" must literally be "discord".
accountId: "*" avoids “default account” surprises.

Step 3: Restart Gateway

openclaw gateway restart

#

Step 4: Verify

In any thread under that channel, run:

/model status
/agents

You should see it routing to workerbee.

If you paste the parent channel ID you copied, I can sanity-check you’re binding the right one.

drifting isle Feb 26, 2026, 7:51 PM

#

this is the output in the "workerbee" thread when I run model status. 🤖 workerbee
APP
— 12:47 PMThursday, February 26, 2026 at 12:47 PM
Current: anthropic/claude-sonnet-4-20250514
Default: anthropic/claude-sonnet-4-20250514
Agent: workerbee
Auth file: ~/.openclaw/agents/workerbee/agent/auth-profiles.json

[anthropic] endpoint: https://api.anthropic.com/ api: anthropic-messages auth: anthropic:default=sk-ant-a...kzQU5gAA (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/workerbee/agent/auth-profiles.json)
• anthropic/claude-sonnet-4-20250514

[minimax] endpoint: https://api.minimax.io/anthropic api: anthropic-messages auth: minimax:default=sk-cp-Tn...rEE8UUDM (next, lastGood) (auth-profiles.json: ~/.openclaw/agents/workerbee/agent/auth-profiles.json)
• minimax/MiniMax-M2.5 (Minimax)

steep tangleBOT Feb 26, 2026, 7:51 PM

#

That output is perfect — it proves the routing + model selection are working exactly the way you wanted inside the thread:

Agent: workerbee
Current/Default: anthropic/claude-sonnet-4-20250514

So you don’t need to change anything unless you want the parent channel itself (and all threads under it) to always route to workerbee.

If you do want that “everything under this channel” behavior, you still just need the parent channel ID (right‑click the parent channel → Copy ID) and then add this binding:

bindings: [
  {
    agentId: "workerbee",
    match: {
      channel: "discord",
      accountId: "*",

#I am using a combo of minimax and Claude-sonnet-4-xxx

1) openclaw models status --agent <workerbee> → zsh parse error

2) agents.defaults.subagents.model → “command not found”

3) /Users/jhat/.openclaw/completions/openclaw.zsh: … compdef

A) You’re not actually talking to the workerbee agent (routing/binding issue)

B) The Discord session is “pinned” to MiniMax via a session override (/model)

C) Minor: fix the config warning (won’t cause reverting, but do it anyway)

Fix

Quick sanity check (in Discord)

Fix: bind workerbee to the channel/thread you actually use

One more thing: “Current=Claude, Active=MiniMax”

Fix (routing): bind this channel/thread id to workerbee

Verify

1) Show the broken area (paste this output here)

2) What the bindings block should look like (valid shape)

3) After you fix the syntax

Final verification (in Discord)

1) Restart the Gateway now that the config parses

2) Re-check in Discord

3) If it STILL shows Agent: main after a successful restart

(Optional cleanup)

1) Wrong ID (thread id vs parent channel id)

2) AccountId mismatch (this one is sneaky)

3) Thread is “focused”/bound to a main session

Option A (recommended): bind the parent channel → all threads inherit

Option B: bind a single thread

One more “why is it still main?” gotcha: thread is pinned via /focus

OpenclawBot APP — 12:34 PMThursday, February 26, 2026 at 12:34 PM agents:

1) The thread is “focused”/bound to main (overrides bindings)

2) You bound the wrong ID (category vs parent channel vs thread)

Quick diagnostic (proves whether bindings are being used at all)

Fix: bind this thread (or bind the parent channel)

Verify (in the same thread)

If it still says Agent: main

What to do

Also: you probably bound the wrong ID

Quick check

Step 1: Get the parent channel ID (Discord)

Step 2: Add a binding for that parent channel ID

Step 3: Restart Gateway

Step 4: Verify

1) `openclaw models status --agent <workerbee>` → zsh parse error

2) `agents.defaults.subagents.model` → “command not found”

3) `/Users/jhat/.openclaw/completions/openclaw.zsh: … compdef`

A) You’re not actually talking to the `workerbee` agent (routing/binding issue)

B) The Discord session is “pinned” to MiniMax via a session override (`/model`)

Fix: bind `workerbee` to the channel/thread you actually use

Fix (routing): bind this channel/thread id to `workerbee`

2) What the `bindings` block should look like (valid shape)

3) If it STILL shows `Agent: main` after a successful restart

One more “why is it still main?” gotcha: thread is pinned via `/focus`

OpenclawBot
APP
— 12:34 PMThursday, February 26, 2026 at 12:34 PM
agents:

1) The thread is “focused”/bound to `main` (overrides bindings)

If it still says `Agent: main`