What is the correct command to check token usage source? | Friends of the Crustacean 🦞🤝 | Page 1

verbal kernel Apr 20, 2026, 5:40 AM

#

I have seen something like this before:
🦞 OpenClaw 2026.4.9 (0512059)
🧠 Model: openai-codex/gpt-5.4-mini · 🔑 oauth (openai-codex:marketing.ps@trrgroup.com (marketing.ps@trrgroup.com))
🧮 Tokens: 470 in / 198 out
🗄️ Cache: 99% hit · 69k cached, 0 new
📚 Context: 70k/272k (26%) · 🧹 Compactions: 0
📊 Usage: 5h 85% left ⏱2h 31m · Week 98% left ⏱6d 21h
🧵 Session: agent:main:main • updated just now
⚙️ Runtime: direct · Think: off · Text: low
🪢 Queue: collect (depth 0)
🧠 Context breakdown
Workspace: C:\Users\prapunsak.openclaw\workspace
Bootstrap max/file: 32,000 chars
Bootstrap max/total: 180,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 76,811 chars (~19,203 tok) (Project Context 52,240 chars (~13,060 tok))

Injected workspace files:

AGENTS.md: OK | raw 26,651 chars (~6,663 tok) | injected 26,651 chars (~6,663 tok)
SOUL.md: OK | raw 8,597 chars (~2,150 tok) | injected 8,597 chars (~2,150 tok)
TOOLS.md: OK | raw 1,636 chars (~409 tok) | injected 1,636 chars (~409 tok)
IDENTITY.md: OK | raw 6,243 chars (~1,561 tok) | injected 6,243 chars (~1,561 tok)
USER.md: OK | raw 2,908 chars (~727 tok) | injected 2,908 chars (~727 tok)
HEARTBEAT.md: OK | raw 786 chars (~197 tok) | injected 786 chars (~197 tok)
BOOTSTRAP.md: MISSING | raw 0 | injected 0
MEMORY.md: OK | raw 5,537 chars (~1,385 tok) | injected 5,537 chars (~1,385 tok)

Skills list (system prompt text): 9,578 chars (~2,395 tok) (21 skills)
Skills: coding-agent, gog, healthcheck, nano-pdf, node-connect, notion, session-logs, skill-creator, summarize, voice-call, weather, budget-audit, config-diff-review, knowledge-reconciliation, learning-loop, memory-promotion, memory-watchdog, model-routing, receipt-normalizer, self-improvement-review, … (+1 more)
Tool list (system prompt text): 0 chars (~0 tok)
Tool schemas (JSON): 27,509 chars (~6,878 tok) (counts toward context; not shown as text)
Tools: read, edit, write, apply_patch, exec, process, canvas, nodes, cron, message, tts,

sharp sequoiaBOT Apr 20, 2026, 5:40 AM

#

cyan ravineBOT Apr 20, 2026, 5:40 AM

#

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

shell lynxBOT Apr 20, 2026, 5:41 AM

#

Depends which “usage” you mean:

Chat status card like the one you pasted: /status
Full provider quota/usage window in CLI: openclaw status --usage
Which auth/profile is being used: openclaw models status
Per-reply token footer: /usage tokens or /usage full

So if you want the source behind that Usage line, the best check is usually:

openclaw models status
openclaw status --usage

Docs:

#

If your output looks different on your install, paste:

openclaw --version

verbal kernel Apr 20, 2026, 6:09 AM

#

I have a lot of noisy blocked tasks. How do I manage them? For example, some tasks were already completed. some tasks were duplicates

shell lynxBOT Apr 20, 2026, 6:10 AM

#

Yep, use the task ledger tools, not /status alone.

Quick cleanup workflow:

openclaw tasks list
openclaw tasks show <task-id>
openclaw tasks audit
openclaw tasks maintenance --apply

Useful actions:

See everything: openclaw tasks list
Inspect one noisy item: openclaw tasks show <id>
Cancel a stuck/duplicate active task: openclaw tasks cancel <id>
Silence notifications: openclaw tasks notify <id> silent

#

Reconcile stale state / cleanup bookkeeping: openclaw tasks maintenance --apply

A few notes:

Already completed tasks are kept for 7 days, then auto-pruned.
If something is just stale/wrongly marked, tasks maintenance --apply is the right first move.
If you truly have duplicate active tasks, cancel the extra one(s).
In chat, /tasks gives the session-linked task board.

If these are actually Task Flow items, use:

openclaw tasks flow list
openclaw tasks flow show <id>
openclaw tasks flow cancel <id>

Docs:

https://docs.openclaw.ai/automation/tasks

#

https://docs.openclaw.ai/automation/taskflow

If you want, paste openclaw tasks audit and I can help decide which ones are safe to cancel.

verbal kernel Apr 20, 2026, 6:13 AM

#

Tasks audit: 64 findings · 0 errors · 64 warnings
Task findings: 64 · TaskFlow findings: 0
Scope Severity Code Item Status Age Detail
Task warn inconsistent_timestamps cac6277e-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 8fc647a4-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps a4de69f4-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 3229cd74-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps b30847dd-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 434e94f2-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 23812a0b-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 69bebc88-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 859c1424-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 9ca2ac78-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps bac060c8-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 9a85713a-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 9d8fb72e-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 5994e991-… failed fresh startedAt is earlier than createdAt

#

Task warn inconsistent_timestamps 250c1396-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps ceadaea5-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps e0fa1ca9-… failed fresh startedAt is earlier than createdAt

#

Task warn inconsistent_timestamps c2496128-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 83a56a46-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 53cb4c51-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 4592bb9a-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 60e4cef8-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps f1f47025-… timed_out fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps facba15c-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 40c085ad-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps ea00a53f-… failed fresh startedAt is earlier than createdAt

#

Task warn inconsistent_timestamps c345c383-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 390a95e7-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 65fa0caa-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 9e1d3c74-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 3bcc5432-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps e3ed0079-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 3719e9ad-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 001f83b8-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 35332960-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps d4bd2203-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 21a61299-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 6d103f95-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps a6ef1329-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps deee46b9-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 15f59c70-… succeeded fresh startedAt is earlier than createdAt

#

Task warn inconsistent_timestamps 09ac5782-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 758f0e3c-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 5e00807e-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 67251345-… succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 12927754-… failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps 0ce2be08-… running fresh startedAt is earlier than createdAt

shell lynxBOT Apr 20, 2026, 6:14 AM

#

That audit is noisy, but it’s not showing blocked/stuck work.

What you have is:

64 warnings
0 errors
all the samples are inconsistent_timestamps
the tasks are already succeeded or failed, not running

So this looks more like task bookkeeping/timestamp noise than real backlog pressure.

What I’d do:

openclaw tasks list --status running
openclaw tasks list --status queued

#

openclaw tasks maintenance --apply

How to read it:

If running / queued are basically empty, you’re fine.
inconsistent_timestamps means the recorded timeline is out of order, for example startedAt < createdAt.
Fresh terminal tasks are not removed immediately. They auto-prune after 7 days.

So, short version: these warnings are annoying, but not the same as blocked tasks.

If this keeps happening, please paste:

openclaw --version

#

openclaw tasks audit --json

That would be good to file as a bug here:
https://github.com/openclaw/openclaw/issues

Docs:

If you want, paste the running and queued lists next, and I’ll help separate real stuck tasks from harmless audit noise.

#

Yep, same pattern.

The important part is:

failed = the task itself failed
inconsistent_timestamps = audit/bookkeeping warning, probably not the cause of the failure

So I’d treat those as real failed tasks plus noisy timestamp metadata.

Next step:

openclaw tasks list --status failed
openclaw tasks show <full-task-id>

Check the error / terminal summary on the failed task. That will tell you why it failed.

#

If you just want to clean up stale bookkeeping:

openclaw tasks maintenance --apply

But if this timestamp warning keeps appearing, please include:

openclaw --version
openclaw tasks audit --json

and file it here:
https://github.com/openclaw/openclaw/issues

So, short answer: the failure is real, the timestamp warning is probably just noise layered on top.

#

This pretty much confirms it.

Because the same warning shows up on:

succeeded
failed
timed_out

…the inconsistent_timestamps warning is almost certainly separate from the actual outcome.

So I’d split it like this:

Ignore for now: succeeded + timestamp warning
Investigate: failed and timed_out

Use:

#

openclaw tasks list --status failed
openclaw tasks list --status timed_out
openclaw tasks show <full-task-id>

That gets you the real error/timeout reason instead of the noisy audit warning.

So yes, I’m fairly confident this is a task timestamp bug/noise, not “all these tasks are blocked because of timestamps”.

If you’re still on that version, please paste:

openclaw --version

If it matches 2026.4.9-ish, I’d file it as a bug with:

#

openclaw tasks audit --json

and link it here:
https://github.com/openclaw/openclaw/issues

Glad we narrowed it down a bit.

#

Yep, this seals it.

Because most of these are succeeded, the timestamp warning is almost certainly just audit noise / a bug, not the thing breaking tasks.

At this point I’d ignore every succeeded row and only inspect the real failures:

openclaw tasks list --status failed --json
openclaw tasks show <full-failed-task-id>

Important: the shortened ids with … are not enough, you need the full task id.

So the two things to do now are:

Debug the failed tasks
Report the timestamp warning separately as a bug

#

If you file it, include:

openclaw --version
openclaw tasks audit --json

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

No need to chase the succeeded ones anymore.

#

Nice, that’s more useful.

Interpretation now:

succeeded + timestamp warning → ignore
failed + timestamp warning → inspect the failure
running + timestamp warning + fresh → probably fine for now

That running task is only concerning if it later turns into:

stale_running, or
it stays running for a long time

Docs say stale_running only becomes an audit issue after about 30 minutes.

So next step:

#

openclaw tasks show <full-id-of-12927754...>
openclaw tasks show <full-id-of-0ce2be08...>

What to do with each:

failed task: read the real error
running task: just check what it’s doing, don’t cancel it yet if it’s still fresh

If the running one is still there later:

openclaw tasks list --status running
openclaw tasks audit

#

You’re down to one real failure and one live task now, the rest is just noisy timestamp junk.

verbal kernel Apr 20, 2026, 6:17 AM

#

OpenClaw 2026.4.15 (041266a)

shell lynxBOT Apr 20, 2026, 6:17 AM

#

Perfect, thanks, that helps.

Since you’re on OpenClaw 2026.4.15, I’d treat this as a real timestamp/audit bug, not just old-version weirdness.

My read now:

inconsistent_timestamps is not a reliable blocker signal
for triage, focus on:
- failed
- timed_out
- stale_running
- lost

You can mostly ignore inconsistent_timestamps by itself, especially when it shows up on succeeded and fresh running tasks.

I’d file a bug with:

#

openclaw --version
openclaw tasks audit --json
openclaw tasks show <full-failed-task-id>
openclaw tasks show <full-running-task-id>

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

So the practical answer is: don’t manage those rows as “blocked tasks”. They’re noisy audit entries. Manage only the genuinely failed/stuck ones.

verbal kernel Apr 20, 2026, 6:21 AM

#

Can you help me write the issue to report?

shell lynxBOT Apr 20, 2026, 6:21 AM

#

Yep, here’s a clean draft you can paste into GitHub.

Suggested title:
tasks audit reports false-positive inconsistent_timestamps on succeeded/failed/running tasks

Issue body:

## Summary

`openclaw tasks audit` is reporting a large number of `inconsistent_timestamps` warnings with:

> startedAt is earlier than createdAt

This appears on tasks with multiple outcomes, including:

#

- `succeeded`
- `failed`
- `timed_out`
- fresh `running`

Because it also shows up on successful and fresh-running tasks, this looks like a task timestamp bookkeeping/audit bug rather than a real "blocked task" condition.

## Version

```bash
openclaw --version

Output:

#

OpenClaw 2026.4.15 (041266a)


## What I expected

I expected task timestamps to be monotonic, and for `tasks audit` not to warn on healthy successful/fresh-running tasks.

## What actually happened

`openclaw tasks audit` reports many warnings like:

```text
Task warn inconsistent_timestamps <task-id> succeeded fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps <task-id> failed fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps <task-id> timed_out fresh startedAt is earlier than createdAt
Task warn inconsistent_timestamps <task-id> running fresh startedAt is earlier than createdAt

#


This makes task audit output noisy and makes it harder to identify real task issues.

## Steps to reproduce

1. Run background tasks normally.
2. Run:

```bash
openclaw tasks audit

Observe inconsistent_timestamps warnings for tasks in different states, including succeeded.

Notes

#


- This does **not** seem tied to only failed tasks.
- The warning appears even for fresh successful tasks.
- The warning may be orthogonal to the actual task result.
- Real task failures still need separate inspection via `openclaw tasks show <full-task-id>`.

## Additional diagnostics

I can also provide:

```bash
openclaw tasks audit --json
openclaw tasks show <full-failed-task-id>
openclaw tasks show <full-running-task-id>

#


## Environment

- OpenClaw: `2026.4.15 (041266a)`
- OS: Windows (please correct if needed)

If you want, I can also make this shorter and more maintainer-friendly, like a minimal repro issue.

verbal kernel Apr 20, 2026, 7:29 AM

#

How to get these to show?
Workspace: C:\Users\prapunsak.openclaw\workspace
Bootstrap max/file: 32,000 chars
Bootstrap max/total: 180,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 76,811 chars (~19,203 tok) (Project Context 52,240 chars (~13,060 tok))

Skills list (system prompt text): 9,578 chars (~2,395 tok) (21 skills)
Skills: coding-agent, gog, healthcheck, nano-pdf, node-connect, notion, session-logs, skill-creator, summarize, voice-call, weather, budget-audit, config-diff-review, knowledge-reconciliation, learning-loop, memory-promotion, memory-watchdog, model-routing, receipt-normalizer, self-improvement-review, … (+1 more)
Tool list (system prompt text): 0 chars (~0 tok)
Tool schemas (JSON): 27,509 chars (~6,878 tok) (counts toward context; not shown as text)
Tools: read, edit, write, apply_patch, exec, process, canvas, nodes, cron, message, tts,

shell lynxBOT Apr 20, 2026, 7:29 AM

#

Use:

/context list

That’s the command that shows the block you pasted:

Workspace
bootstrap limits
sandbox
system prompt size
injected workspace files
skills/tool sizes

If you want the more verbose version, use:

#

/context detail

A couple notes:

/status only gives the quick summary, not that full breakdown.
System prompt (run) appears after a normal tool-capable run exists, otherwise it may fall back to an estimate.

Docs: https://docs.openclaw.ai/concepts/context

Glad you found that one, it’s super handy for debugging context bloat.

verbal kernel Apr 20, 2026, 9:06 AM

#

I need help telling Openclaw Control to enable discord skill.

I want the discord built-in skill (Discord ops via the message tool (channel=discord).) to change from Yellow (need setup) to green (ready to use)

This is what OpenClaw Control is saying:
I can help, but that change is a runtime/config setup, so I need the actual Discord skill path or the exact setup mechanism the Control UI expects.

What I know:

the skill name is discord
description: Discord ops via the message tool (channel=discord).
Control UI shows Need Setup

What I don’t have yet:

the built-in skill file location
the setup command/flag for that skill
the config key that marks it ready

If you want, I can now search the workspace/runtime for the Discord skill registration and tell you exactly what needs to be set to turn it green.

shell lynxBOT Apr 20, 2026, 9:07 AM

#

Yep. I checked the built-in Discord skill, and the key bit is:

Skill file: skills/discord/SKILL.md
Requirement metadata: channels.discord.token

So the yellow → green status is driven by whether OpenClaw sees:

channels.discord.token

What to set

At minimum, set a Discord bot token in config, ideally via env ref:

#

export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN"
openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN

If you actually want Discord to work, also enable the channel:

openclaw config set channels.discord.enabled true --strict-json
openclaw gateway restart

Why Control shows “Need Setup”

Because the built-in skill metadata literally says it requires:

#

requires:
  config:
    - channels.discord.token

So there is no separate Discord-skill toggle.
The skill turns green when that config requirement is satisfied.

How to verify

openclaw skills info discord
openclaw skills list --eligible

If the token is detected, discord should move into the ready/eligible set.

#

Practical advice

If your goal is only make the skill green, set channels.discord.token.
If your goal is actually use Discord, set both:
- channels.discord.token
- channels.discord.enabled: true

Docs:

If you want, I can also write the exact openclaw.json snippet for your setup.

verbal kernel Apr 20, 2026, 9:19 AM

#

I have two agents so I have two tokens. So what's the command that I need to do?

shell lynxBOT Apr 20, 2026, 9:20 AM

#

If you have two Discord bots for two agents, I’d do it like this.

1) Set env vars for both bot tokens

export DISCORD_BOT_TOKEN_MAIN="YOUR_MAIN_BOT_TOKEN"
export DISCORD_BOT_TOKEN_CODING="YOUR_SECOND_BOT_TOKEN"

2) Set the default/main Discord token

This is the important one for making the built-in discord skill go green:

openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN_MAIN
openclaw config set channels.discord.enabled true --strict-json

#

3) Set the second Discord account token

Replace coding with your second agent/account id if different:

openclaw config set channels.discord.accounts.coding.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN_CODING

4) Bind each Discord account to the right agent

openclaw agents bind --agent main --bind discord
openclaw agents bind --agent coding --bind discord:coding

5) Restart and verify

#

openclaw gateway restart
openclaw skills info discord
openclaw agents bindings

Important gotcha

If your only token is under:

channels.discord.accounts.coding.token

the built-in discord skill may still stay yellow, because its metadata checks the default Discord token requirement.

So for yellow → green, make sure you set:

#

channels.discord.token

for the default/main bot.

If you want, send me your two agent ids and I’ll rewrite the exact commands with your real names.

verbal kernel Apr 20, 2026, 9:21 AM

#

I am already using Discord for both agents, with the new bindings. what will I be allow to do more?

shell lynxBOT Apr 20, 2026, 9:22 AM

#

If both agents are already working on Discord, then turning that built-in discord skill green mostly gives you:

What changes

The agent becomes more confident about using Discord-specific ops through the message tool, for example:

read Discord channels/history
send to specific Discord channels or users
react to messages
edit/delete messages
create threads
pin/unpin
search messages
create polls
use richer Discord UI/components when supported

What does not change much

#

It does not magically unlock basic replying, if replies already work now.
Normal inbound/outbound Discord chat routing can already work without that skill showing green.

So what’s the practical benefit?

Mostly these 3 things:

Control UI stops saying “Need Setup”
The agent gets better prompt guidance that Discord ops are available
The agent is more likely to use the right message tool patterns for Discord automatically

So if you’re already chatting with both agents on Discord, the green state is more about:

better agent guidance
less setup confusion
more reliable Discord tool use

#

not “suddenly Discord starts working”.

If you want, I can give you a before/after example of what the agent can do once the Discord skill is considered ready.

verbal kernel Apr 20, 2026, 9:29 AM

#

Do I need channel id for this as well?

shell lynxBOT Apr 20, 2026, 9:30 AM

#

Not for the skill turning green, no.

For the built-in discord skill readiness, the important bit is the Discord token config, not a channel id.

You need for green/ready

channels.discord.token for the default Discord bot
and practically channels.discord.enabled: true

You do not need for that

channel id
guild id
message id

You only need channel id later if you want to:

target a specific Discord channel with the message tool
bind behavior to a specific guild/channel
configure allowlists / channel-specific routing

#

So short answer:

turn skill green: token yes, channel id no
do Discord ops in a specific place: channel id yes

If you want, I can give you a tiny checklist for:

make skill green, and
make a specific Discord channel usable.

verbal kernel Apr 20, 2026, 9:31 AM

#

WHat do you mean by Discord channel usable?

shell lynxBOT Apr 20, 2026, 9:31 AM

#

I mean “usable” as in:

OpenClaw can actually work in that Discord channel, not just have the skill marked ready.

So a Discord channel is “usable” when the bot/account can:

see the channel
read messages there
send messages there
pass your OpenClaw allowlist / guild / mention rules
route to the right agent/account binding

So there are two separate things:

1. Skill ready

This is the yellow/green thing in Control.

#

That mostly means:

the Discord requirement is configured, especially the token

2. Channel usable

This means the bot can really operate in a specific channel.

For that, you usually need:

bot invited to the server
correct Discord permissions
guild/channel allowed in OpenClaw config
correct agent binding
mention rules or allowlist rules satisfied

So:

green skill = “Discord capability is configured”
usable channel = “this exact Discord channel actually works for messages/actions”

#

If you want, I can give you a plain checklist to verify one channel is usable step by step.

verbal kernel Apr 20, 2026, 9:32 AM

#

The channels already have agents usable

shell lynxBOT Apr 20, 2026, 9:33 AM

#

Then honestly, you’re probably already done functionally.

If:

both Discord channels/accounts already work
both agents are already bound correctly
the bots can already read/reply there

then the yellow discord skill is mostly just:

a Control UI readiness mismatch, or
a skill-metadata check that isn’t accounting for your multi-account setup

In other words:

runtime works
UI still says “Need Setup”

#

That can happen because the built-in skill checks for the default Discord token requirement, while your real setup may be account-scoped for multiple agents.

Practical answer

If everything already works, you do not need to fix this unless you specifically want the Control UI chip to turn green.

So your choices are:

Ignore it
since Discord is already usable
Force the UI to go green
by setting a default Discord token path that satisfies the built-in skill check

If you want, I can help you figure out whether this is actually a Control UI bug for multi-account Discord skills, which honestly sounds pretty likely.

verbal kernel Apr 20, 2026, 9:40 AM

#

Help me figure out

shell lynxBOT Apr 20, 2026, 9:41 AM

#

I checked it, and I think you found a real multi-account false negative.

What’s happening

The built-in Discord skill says it requires:

channels.discord.token

That comes from:

skills/discord/SKILL.md

Then skill readiness is evaluated with an exact config path check, via:

src/agents/skills-status.ts

#

src/shared/config-eval.ts

That logic checks the path literally, it does not treat:

channels.discord.accounts.<id>.token

as satisfying:

channels.discord.token

So the likely result is

your Discord bots/accounts work fine

#

your agent bindings work fine
but the built-in discord skill still shows yellow / Need Setup

because the readiness check is not account-aware.

My conclusion

This looks like a Control/skill readiness limitation or bug for multi-account Discord setups.

Your options

Option 1, simplest

Ignore it, since runtime already works.

Option 2, force it green

Set a default top-level Discord token too, so the skill check passes.

#

Option 3, report it

Report that the Discord skill readiness check should accept account-scoped tokens in multi-account setups.

If you want, I can write you a tight bug report that says exactly this, with the code-path reasoning trimmed down for maintainers.

verbal kernel Apr 20, 2026, 9:43 AM

#

Force it green

shell lynxBOT Apr 20, 2026, 9:43 AM

#

Yep, easiest workaround:

Use one of your already-working Discord bot tokens as the top-level default Discord token too.

openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN_MAIN
openclaw config set channels.discord.enabled true --strict-json
openclaw gateway restart
openclaw skills info discord

Replace DISCORD_BOT_TOKEN_MAIN with whichever env var already holds the bot token you want treated as the default Discord account.

What this does

keeps your existing multi-account setup
adds the missing top-level channels.discord.token

#

makes the built-in discord skill eligibility check pass
should flip the chip from yellow to green

Important

This is a workaround, not the real fix.
You’re basically duplicating the default bot token at the top-level config path so Control stops complaining.

If you want, I can also give you the exact command for your second account name if you paste the account ids you used.

verbal kernel Apr 20, 2026, 9:44 AM

#

Does setting two tokens help with their Discord skills ?

shell lynxBOT Apr 20, 2026, 9:45 AM

#

Short answer: not by itself, probably no.

Why

For actual Discord runtime/use, yes:

two tokens = two Discord bot accounts
good for two agents / two account bindings

But for the built-in discord skill turning green, the check appears to care about the default top-level token path:

channels.discord.token

So:

#

two account-scoped tokens help Discord work
but they may not satisfy the skill readiness chip

Practical rule

If you want Discord to work for two agents, set both account tokens.
If you want the discord skill to show green, also set a top-level default token.

So the answer is:

two tokens for runtime: yes
two tokens for the green skill chip: not necessarily

That’s why I suggested forcing one working bot token into:

#

channels.discord.token

If you want, I can give you the exact “best config shape” for:

2 agents
2 Discord bots
green Discord skill chip.

#

Don’t use that link.

For OpenClaw bugs/issues, use the official tracker only:
https://github.com/openclaw/openclaw/issues

Random IP submit pages are not part of the project, and I wouldn’t trust them.

verbal kernel Apr 20, 2026, 11:27 AM

#

When someone said “Add routing rule to system prompt” What/where exactly is system prompt?

shell lynxBOT Apr 20, 2026, 11:28 AM

#

In OpenClaw, the system prompt is not one file you open and edit directly.

It’s the prompt OpenClaw builds every run from:

built-in OpenClaw instructions
tool/skill metadata
runtime info
injected workspace files like:
- AGENTS.md
- SOUL.md
- USER.md
- TOOLS.md

So when someone says “add routing rule to the system prompt”…

They usually mean one of two things:

#

1. If they mean model behavior/instructions

Put it in:

AGENTS.md for operational rules/instructions
SOUL.md for personality/tone
USER.md for user-specific context

For most “rule” changes, AGENTS.md is the right place.

2. If they mean actual agent/channel routing

That is not really a system prompt thing.

That belongs in config/bindings, for example:

bindings
channel account config
guild/channel allowlists

#

agent bindings

So if the rule is “Discord account X should go to agent Y”, that should be in bindings/config, not in the prompt.

How to inspect what OpenClaw is injecting

Use:

/context list
/context detail

Docs:

#

If you want, tell me the exact “routing rule” someone suggested, and I can tell you whether it belongs in AGENTS.md or bindings/config.

verbal kernel Apr 20, 2026, 11:31 AM

#

https://docs.google.com/document/d/1ffmZEfT7aenfAz2lkjyHsQIlYRWFpGcM/mobilebasic

shell lynxBOT Apr 20, 2026, 11:33 AM

#

I opened it. That doc is using “system prompt” loosely.

In current OpenClaw, the closest translation is:

behavior/instruction rules → put them in AGENTS.md
tone/personality → SOUL.md
actual routing/config → use bindings/config, not prompt text

So for that doc specifically

When it says things like:

“Add session initialization rule to system prompt”
“Add routing/model-selection rule to system prompt”

the practical OpenClaw version is usually:

#

Put instruction-style rules in:

AGENTS.md

Put real routing in:

agent bindings
channel/account config
model config

Important caveat

That Google doc is not official OpenClaw docs, and parts of it look pretty hand-wavy/outdated for current OpenClaw, so I would not copy it blindly.

For example, OpenClaw already has its own built system prompt and bootstrap/context behavior, so “edit the system prompt” is not really the right mental model here.

Best mental model

#

Want the agent to behave a certain way? → AGENTS.md
Want the agent to sound a certain way? → SOUL.md
Want Discord/model/account routing to actually change? → config/bindings

If you want, paste the exact paragraph from that doc you’re trying to apply, and I’ll translate it into the correct OpenClaw place.

verbal kernel Apr 20, 2026, 11:37 AM

#

MODEL SELECTION RULE:

Default: Always use Haiku
Switch to Sonnet ONLY when:

Architecture decisions
Production code review
Security analysis
Complex debugging/reasoning
Strategic multi-project decisions

When in doubt: Try Haiku first.

But replace Haiku with codex openai 5.4 mini, sonnet with codex openai 5.4

shell lynxBOT Apr 20, 2026, 11:38 AM

#

Yep, that kind of rule goes in AGENTS.md.

I’d paste something like this there:

## Model selection

Default: prefer GPT-5.4 mini.

Escalate to GPT-5.4 only for:
- architecture decisions
- production code review
- security analysis
- complex debugging or deep reasoning
- strategic multi-project decisions

#

When in doubt, try GPT-5.4 mini first.
If the task clearly needs deeper reasoning or the first pass is weak, escalate to GPT-5.4.

Important caveat

That is a behavior rule, not a hard runtime switch.

So:

put it in AGENTS.md if you want the agent to follow that preference
but if you want actual default model selection enforced, set the default model in config too

So the clean split is:

AGENTS.md = “when should I escalate?”

#

config = “what model do I start on by default?”

If you want, I can turn that into:

an AGENTS.md block, and
the matching config snippet for mini-by-default.

verbal kernel Apr 20, 2026, 11:43 AM

#

Now that openclaw has adaptive thinking mode. How should I combine this with model-routing?

shell lynxBOT Apr 20, 2026, 11:44 AM

#

Best way to think about it:

model-routing chooses the size/cost tier
adaptive thinking chooses the effort level inside that tier

So I would not replace model-routing with adaptive. I’d layer them.

Recommended pattern

1. Cheap/default lane

Use your cheaper model by default, with off or low thinking.

Good for:

normal chat
tool use
simple coding
file edits

#

routine debugging

2. Same model, more effort

If the task is getting tricky but not obviously “big”, keep the same model and raise thinking to:

adaptive if the provider/model handles it well
otherwise medium/high

Good for:

messy bug hunts
reasoning through a few alternatives
medium-complexity code review

3. Bigger model lane

Escalate to the stronger model for clearly expensive cognition:

architecture

#

security
critical production review
deep debugging
multi-step planning across systems

And for that lane, adaptive thinking is a good fit.

Practical rule of thumb

I’d use something like:

Mini + low/off = default
Mini + adaptive/medium = first escalation
Full model + adaptive = serious work
Full model + high/xhigh = only when really needed

Why this works

#

If you set adaptive everywhere, you blur the savings from model-routing.
If you use routing only and never vary thinking, you miss a cheaper middle ground.

So the sweet spot is:

route by task size, then use thinking as a second dial.

Suggested AGENTS.md wording

## Model and thinking policy

Default: use GPT-5.4 mini for normal work.

For moderately difficult tasks, keep GPT-5.4 mini and increase thinking first.

#

Escalate to GPT-5.4 for:
- architecture decisions
- production code review
- security analysis
- complex debugging or reasoning
- strategic multi-project decisions

Use adaptive thinking for tasks that are ambiguous or reasoning-heavy.
When in doubt, try the smaller model first, then raise thinking before escalating models, unless the task is obviously high-stakes.

One caveat: adaptive is most meaningful on models/providers that truly support provider-managed adaptive reasoning. If your chosen model doesn’t show a strong difference, use explicit low / medium / high instead.

If you want, I can turn this into:

a tighter AGENTS.md block, and
a matching config strategy for mini-by-default.

verbal kernel Apr 20, 2026, 11:47 AM

#

Yes please. I also have skill.md for this as well. The file recommending me to put in soul.md as well

shell lynxBOT Apr 20, 2026, 11:48 AM

#

Yep. I’d not put the full thing in all three places.

Because:

AGENTS.md is always injected, good for base operating policy
SOUL.md is for personality/values, keep it short
SKILL.md is good for a detailed playbook, but it’s more situational/on-demand

My recommendation

Put the main rule in `AGENTS.md`

Keep it short, like this:

## Model and thinking policy

#

Default to the smaller/cheaper model for routine work.

Escalation ladder:
1. smaller model + low/off thinking for normal work
2. smaller model + adaptive or medium thinking for moderately difficult work
3. stronger model + adaptive thinking for architecture, security, production review, or complex debugging
4. stronger model + high thinking only when clearly justified

Escalate to the stronger model when:
- architecture decisions
- production code review
- security analysis
- complex debugging or reasoning
- strategic multi-project decisions
- the smaller model has already made a solid attempt and is still struggling

#


Prefer raising thinking before raising model size, unless the task is obviously high-stakes or deeply complex.

Optional tiny note in `SOUL.md`

Only if you want a token-frugality principle there too:

Prefer the smallest effective model and only escalate when the task clearly needs it.

I would keep SOUL to one line max for this. Don’t duplicate the full routing table there.

Put the detailed version in `SKILL.md`

If you already have a skill for this, that’s a good place for:

#

examples
edge cases
model/thinking matrix
“if X fails, then escalate to Y” playbook

Matching config strategy

Use config to enforce the default, and AGENTS to explain escalation behavior.

Something like:

{
  agents: {
    defaults: {
      model: {

#

        primary: "YOUR_MINI_MODEL_REF"
      },
      thinkingDefault: "low",
      models: {
        "YOUR_MINI_MODEL_REF": { alias: "mini" },
        "YOUR_FULL_MODEL_REF": { alias: "full" }
      }
    }
  }
}

Replace those with the exact refs from:

#

/model list

Short version

AGENTS.md = main policy
SOUL.md = maybe one short principle
SKILL.md = detailed playbook
config = actual default model/thinking

Also, your injected prompt is already pretty big, so I’d avoid repeating the same rule in multiple files.

If you want, I can help you compress your current wording into a very short AGENTS block so it doesn’t bloat context.

sharp sequoiaBOT Apr 20, 2026, 11:53 AM

#

verbal kernel Apr 20, 2026, 11:59 AM

#

Can you tell me why you think my injected prompt is big and where should I be thinking about reducing?
Can you help compress my current wording?

shell lynxBOT Apr 20, 2026, 12:00 PM

#

Yep. I think it’s big because you’re paying a pretty large fixed cost before the conversation even starts.

From your /context snapshot:

System prompt (run): ~19,203 tokens
Project Context alone: ~13,060 tokens

That’s not broken, but it is a real permanent tax on every turn.

Where the size is coming from

Biggest injected files:

AGENTS.md → ~6,663 tok
SOUL.md → ~2,150 tok
IDENTITY.md → ~1,561 tok
MEMORY.md → ~1,385 tok

#

USER.md → ~727 tok

And outside your files:

Skills list → ~2,395 tok
Tool schemas → ~6,878 tok

Highest-impact places to reduce

1. `AGENTS.md` is the biggest target

That’s your best ROI by far.

Trim anything that is:

repetitive
example-heavy
historical
niche/rarely needed

#

duplicated elsewhere

Keep only rules the agent truly needs every single turn.

2. `SOUL.md`

Good place to trim tone/personality fluff if it got long.

Keep:

voice
values
a few behavioral principles

Cut:

long philosophy
repeated guidance already in AGENTS

3. `IDENTITY.md`

#

This one is often way longer than it needs to be.

Usually identity can be tiny:

name
role
one-line vibe
emoji

4. `MEMORY.md`

This should be durable facts only, not logs, not ongoing notes, not long reminders.

If something is:

temporary
project-specific
date-specific
“nice to remember but not always needed”

#

move it out of MEMORY.

5. Skills list

If you have lots of installed skills, that list grows.
If some are irrelevant for this agent, a skill allowlist can help.

Good rule of thumb

If a piece of text is not needed on almost every turn, it probably should not live in:

AGENTS.md
SOUL.md
IDENTITY.md
USER.md
MEMORY.md

Those are expensive because they get injected constantly.

#

Compressed version of your model/thinking wording

Here’s a much tighter version for AGENTS.md:

## Model and thinking policy

Default to the smaller model.

Escalate in this order:
1. smaller model + low/off thinking
2. smaller model + adaptive/medium thinking
3. stronger model + adaptive thinking
4. stronger model + high thinking only when justified

#


Use the stronger model for architecture, security, production review, strategic planning, or when the smaller model is clearly struggling.

Prefer increasing thinking before increasing model size, unless the task is obviously high-stakes or deeply complex.

If you want it even tighter:

## Model policy

Default to the smaller model.
Raise thinking before raising model size unless the task is clearly high-stakes.
Use the stronger model for architecture, security, production review, strategic planning, or when the smaller model struggles.

#

If you want, I can help you do a line-by-line trim plan for AGENTS.md, SOUL.md, and IDENTITY.md based on the token numbers you pasted.

verbal kernel Apr 20, 2026, 2:07 PM

#

Does thinking need a config in json.md for adaptive thinking ability or does skill.md ?

shell lynxBOT Apr 20, 2026, 2:07 PM

#

Config, not SKILL.md.

SKILL.md can recommend when to use adaptive thinking, but it does not enable the capability.

What actually controls it

1. The model/provider must support it

That’s the real “ability” part.

2. You can set the default in config

Use openclaw.json, for example:

{
  agents: {
    defaults: {

#

      thinkingDefault: "adaptive"
    }
  }
}

Or per agent:

{
  agents: {
    list: [
      {
        id: "main",
        thinkingDefault: "adaptive"

#

      }
    ]
  }
}

3. You can also set it per session/message

For example:

/think adaptive

Where `SKILL.md` fits

Use SKILL.md only for guidance like:

#

use adaptive for hard reasoning
keep thinking low for routine work
escalate model if adaptive still isn’t enough

So:

ability/defaults → config
usage guidance → AGENTS.md or SKILL.md

One important caveat: if your selected model/provider doesn’t truly support meaningful adaptive thinking, setting "adaptive" may not behave the way you expect. In that case, use explicit levels like low, medium, or high.

If you want, I can show you the best minimal config for:

mini as default
adaptive available when needed
stronger model only for escalations.

verbal kernel Apr 20, 2026, 2:09 PM

#

Yes please

shell lynxBOT Apr 20, 2026, 2:09 PM

#

Yep, here’s the minimal setup I’d recommend.

`openclaw.json`

{
  agents: {
    defaults: {
      model: {
        primary: "YOUR_MINI_MODEL_REF"
      },
      thinkingDefault: "low",
      models: {
        "YOUR_MINI_MODEL_REF": { alias: "mini" },
        "YOUR_STRONG_MODEL_REF": { alias: "strong" }
      }

#

    }
  }
}

Why this shape

primary = mini
keeps your normal/default cost low
thinkingDefault: "low"
avoids paying adaptive/high on every turn
both models in models
makes both selectable/allowed for intentional escalation

#

Important gotcha

I would not put the stronger model into fallbacks just for “hard tasks”.

fallbacks are mainly for:

provider/model failure
auth/rate-limit failover

They are not a clean “use bigger model when task is harder” policy.

How to use it in practice

Default

mini + low thinking

Harder turn

/think adaptive

#

Bigger escalation

/model strong

Matching `AGENTS.md` block

## Model and thinking policy

Default to the smaller model with low thinking.
For moderately difficult tasks, increase thinking first.
Switch to the stronger model for architecture, security, production review, strategic planning, or when the smaller model is clearly struggling.
Do not escalate model size unless the task or prior attempt justifies it.

Optional note

If you want one specific agent to be more “deep-thinky”, set:

#

agents.list[].thinkingDefault

just for that agent, instead of globally.

And use /model list to get the exact refs to replace:

YOUR_MINI_MODEL_REF
YOUR_STRONG_MODEL_REF

If you want, I can help you turn your actual current model names into a ready-to-paste config snippet.

verbal kernel Apr 20, 2026, 2:14 PM

#

Just agent.md alone is enough for agent to know which model to escalate to? Currently, I have many models configured. But many of them are in testing phrase. For example, qwen local models and openrouter/free

shell lynxBOT Apr 20, 2026, 2:15 PM

#

Short answer: no, AGENTS.md alone is not enough as a hard guarantee.

It’s good for policy/preference, but if you have lots of configured models, especially test ones, I would not rely on prompt text alone.

Best practice

Use both:

1. Config = constrain the model set

Keep only your sanctioned daily-use models in the main catalog/allowlist for that agent flow.

For example, keep just:

mini
strong
maybe one backup

#

and leave experimental stuff out of the everyday set if possible.

2. `AGENTS.md` = tell the agent how to escalate

For example:

default to mini
escalate to strong
do not use test/free/local models unless explicitly asked

Why this matters

If you leave lots of models visible, like:

local Qwen variants
OpenRouter free models
test models

#

then the agent may still “know about” them, and prompt rules become more advisory than reliable.

My recommendation

For your main agent, keep the routing surface very small:

one default cheap model
one stronger escalation model
maybe one backup

Treat everything else as testing-only, not normal escalation targets.

Practical policy

If you must keep test models configured, add a short rule like:

#

Only escalate between the approved primary and strong models.
Do not auto-select experimental, local, free-tier, or test models unless the user explicitly asks.

But honestly, config curation is stronger than wording.

So the real answer is:

AGENTS.md alone = okay for guidance
AGENTS.md + tight model allowlist/aliases = much better

If you want, I can help you design a clean 3-model setup:

default
strong escalation
backup
while keeping your test models out of the normal path.

verbal kernel Apr 20, 2026, 2:17 PM

#

Show me. I think I have like 10 models configured right now

shell lynxBOT Apr 20, 2026, 2:19 PM

#

Yep, if you’ve got ~10 configured, I’d split them into:

3 production models
everything else = testing only

The clean 3-model setup

1. Default

Your cheap, reliable daily driver.

Use for:

normal chat
tool use
file edits
routine coding/debugging

2. Strong

#

Your best trusted escalation model.

Use for:

architecture
security
production review
hard debugging
strategic decisions

3. Backup

A boring, reliable fallback from a different provider/auth path if possible.

Use for:

outages
rate limits
temporary provider weirdness

#

What I would not put in the main 3

Usually keep these out of the normal path unless they’ve proven themselves:

local experimental models
free-tier models
OpenRouter random/free picks
test Qwen variants
anything you don’t trust for tools

Example config shape

{
  agents: {
    defaults: {

#

      model: {
        primary: "YOUR_DEFAULT_MODEL"
      },
      thinkingDefault: "low",
      models: {
        "YOUR_DEFAULT_MODEL": { alias: "mini" },
        "YOUR_STRONG_MODEL": { alias: "strong" },
        "YOUR_BACKUP_MODEL": { alias: "backup" }
      }
    }
  }
}

What this gives you

#

Now your main agent only “sees” the 3 sanctioned choices:

mini
strong
backup

That makes AGENTS.md much more reliable.

Matching `AGENTS.md`

## Model policy

Default to `mini`.
Escalate to `strong` for architecture, security, production review, strategic planning, or when `mini` is clearly struggling.
Use `backup` only for fallback/recovery, not as the normal escalation target.

#

Do not auto-select experimental, local, or free-tier models unless the user explicitly asks.

Best structure if you like testing

I’d honestly do this:

main agent → only the curated 3
test/lab agent → all the weird experimental models

That way your daily agent stays sane, and your test agent can stay chaotic 😄

If you want, I can help you turn your current 10 models into these buckets:

default
strong

#

backup
testing only

verbal kernel Apr 20, 2026, 2:20 PM

#

Yes please

shell lynxBOT Apr 20, 2026, 2:21 PM

#

Yep, easiest next step:

Paste the output of either:

/model list

or

openclaw models list

and I’ll sort them into:

default

#

strong
backup
testing-only

The rule I’ll use

Default

cheapest model you actually trust
good enough for daily chat/tool use
not experimental

Strong

best trusted reasoning/review model
for architecture, security, hard debugging

Backup

stable fallback

#

ideally different provider/auth path from the default

Testing-only

local experiments
free-tier models
flaky tool callers
things you don’t want auto-selected

If you paste the list, I’ll turn it into a clean 3-model config for you.

Also, once we get it working, please mark the solution so Answer Overflow can index it:
right-click the solution message → Apps → ✅ Mark Solution.

verbal kernel Apr 20, 2026, 2:25 PM

#

Can you show by example first? Lets say theres 10 models under models:. how would the agent know from json which is configured but experimental . Which one allow to escalate to because of stronger?

shell lynxBOT Apr 20, 2026, 2:26 PM

#

Yep, this is the key bit:

The agent does not magically infer “experimental” from models:.
There isn’t a built-in model-catalog flag like:

{ experimental: true }

for normal model entries.

So how does the agent know?

Only from a combination of:

model.primary
tells it the default

#

aliases / naming conventions
for example strong, backup, exp-qwen-local
AGENTS.md policy
telling it which aliases are okay to escalate to

Example with 10 configured models

{
  agents: {
    defaults: {
      model: {
        primary: "openai/gpt-5.4-mini"

#

      },
      thinkingDefault: "low",
      models: {
        "openai/gpt-5.4-mini": { alias: "mini" },
        "openai/gpt-5.4": { alias: "strong" },
        "anthropic/claude-sonnet-4-6": { alias: "backup" },

        "qwen/local-coder-32b": { alias: "exp-qwen-local" },
        "qwen/local-instruct-14b": { alias: "exp-qwen-small" },
        "openrouter/some-free-model-1": { alias: "exp-free-1" },
        "openrouter/some-free-model-2": { alias: "exp-free-2" },
        "openrouter/another-test-model": { alias: "exp-test-1" },
        "google/some-preview-model": { alias: "exp-preview" },
        "other/provider-model": { alias: "exp-other" }
      }

#

    }
  }
}

Then in `AGENTS.md`

## Model policy

Default to `mini`.
Escalate to `strong` for architecture, security, production review, strategic planning, or when `mini` is clearly struggling.
Use `backup` only for fallback/recovery.
Do not auto-select models whose alias starts with `exp-` unless the user explicitly asks.

#

What this means

The agent knows:

default = mini
approved escalation = strong
fallback only = backup
experimental = anything named exp-*

But that is because you encoded the meaning in:

alias names
AGENTS policy

not because OpenClaw has a special experimental-model flag.

#

Stronger recommendation

If you want this to be more reliable, don’t leave the 10-model test zoo in the same everyday catalog.

Better:

main agent → only mini, strong, backup
test agent → all the experimental models

That’s much cleaner than trying to teach the agent to ignore 7 tempting weird models 😄

If you want, I can show you both versions side by side:

single-agent with exp- aliases*, and
clean main-agent + test-agent split.

verbal kernel Apr 20, 2026, 3:59 PM

#

Can I set thinking default differently for some model? For example, codex 5.3 always default at medium

shell lynxBOT Apr 20, 2026, 4:00 PM

#

Yes, you can do that with per-model params.

So the pattern is:

global default at agent level
specific model override in that model’s params

Example

{
  agents: {
    defaults: {
      thinkingDefault: "low",
      models: {
        "YOUR_CODEX_53_MODEL_REF": {

#

          alias: "codex53",
          params: {
            thinking: "medium"
          }
        },
        "YOUR_MINI_MODEL_REF": {
          alias: "mini"
        }
      }
    }
  }
}

What that means

#

most models default to low
YOUR_CODEX_53_MODEL_REF defaults to medium
if you switch to that model, it carries its own thinking default

Important

Per-message or session overrides still beat that, for example:

/think high

So the practical precedence is roughly:

message/session /think
model-specific params.thinking
agent thinkingDefault

#

global fallback behavior

So for your example

Yes, you can absolutely say:

Codex 5.3 → default medium
mini model → default low/off

That’s actually a pretty nice setup.

If you want, I can show you a realistic 3-model config with:

mini = low
codex 5.3 = medium
strong model = adaptive/high.

verbal kernel Apr 20, 2026, 4:05 PM

#

I actually want default at mini low first, then think higher first before escalating to 5.3, then higher to 5.4 , then 5.4 high at max something kike that.

shell lynxBOT Apr 20, 2026, 4:05 PM

#

Yep, that’s a sensible ladder.

The clean way to do it is:

config sets the default thinking per model
AGENTS.md tells the agent the escalation order

Your ladder

I’d express it like this:

mini + low (default)
mini + medium/high before changing model
5.3 + medium
5.4 + medium/adaptive
5.4 + high only as the max step

#

Important nuance

OpenClaw can help you approximate this, but JSON alone does not define a fully automatic “ladder engine”.

So:

config = “when this model is selected, use this default thinking”
AGENTS = “which rung should I try next”

Example config shape

{
  agents: {
    defaults: {
      model: {

#

        primary: "YOUR_MINI_REF"
      },
      thinkingDefault: "low",
      models: {
        "YOUR_MINI_REF": {
          alias: "mini"
        },
        "YOUR_53_REF": {
          alias: "mid",
          params: {
            thinking: "medium"
          }
        },
        "YOUR_54_REF": {
          alias: "strong",

#

          params: {
            thinking: "medium"
            // or "adaptive" if that's what you want for this model/provider
          }
        }
      }
    }
  }
}

Matching `AGENTS.md`

## Model escalation policy

#


Use this escalation ladder:
1. `mini` with low thinking
2. increase thinking on `mini` before changing models
3. escalate to `mid`
4. escalate to `strong`
5. use high thinking on `strong` only when clearly justified

Do not escalate model size early if increasing thinking on the current model is likely enough.
Reserve the highest step for difficult, high-stakes, or clearly unresolved work.

One more important note

You can’t have the same model be both:

#

5.4 default medium
and separately 5.4 default high

as two built-in defaults in one entry.

So the last step, 5.4 + high, is usually a manual/session override:

/think high

after you’re already on 5.4.

Also, I would not use fallbacks for this ladder, because fallbacks are mostly for failures, not “task got harder”.

If you want, I can turn this into a ready-to-paste config using your likely naming scheme:

#

mini
mid
strong

#What is the correct command to check token usage source?

Notes

What to set

Why Control shows “Need Setup”

How to verify

Practical advice

1) Set env vars for both bot tokens

2) Set the default/main Discord token

3) Set the second Discord account token

4) Bind each Discord account to the right agent

5) Restart and verify

Important gotcha

What changes

What does not change much

So what’s the practical benefit?

You need for green/ready

You do not need for that

You only need channel id later if you want to:

1. Skill ready

2. Channel usable

Practical answer

What’s happening

So the likely result is

My conclusion

Your options

Option 1, simplest

Option 2, force it green

Option 3, report it

What this does

Important

Why

Practical rule

So when someone says “add routing rule to the system prompt”…

1. If they mean model behavior/instructions

2. If they mean actual agent/channel routing

How to inspect what OpenClaw is injecting

So for that doc specifically

Put instruction-style rules in:

Put real routing in:

Important caveat

Best mental model

Important caveat

Recommended pattern

1. Cheap/default lane

2. Same model, more effort

3. Bigger model lane

Practical rule of thumb

Why this works

Suggested AGENTS.md wording

My recommendation

Put the main rule in AGENTS.md

Optional tiny note in SOUL.md

Put the detailed version in SKILL.md

Matching config strategy

Short version

Where the size is coming from

Highest-impact places to reduce

1. AGENTS.md is the biggest target

2. SOUL.md

3. IDENTITY.md

4. MEMORY.md

5. Skills list

Good rule of thumb

Compressed version of your model/thinking wording

What actually controls it

1. The model/provider must support it

2. You can set the default in config

3. You can also set it per session/message

Where SKILL.md fits

openclaw.json

Why this shape

Important gotcha

How to use it in practice

Default

Harder turn

Bigger escalation

Matching AGENTS.md block

Optional note

Best practice

1. Config = constrain the model set

Put the main rule in `AGENTS.md`

Optional tiny note in `SOUL.md`

Put the detailed version in `SKILL.md`

1. `AGENTS.md` is the biggest target

2. `SOUL.md`

3. `IDENTITY.md`

4. `MEMORY.md`

Where `SKILL.md` fits

`openclaw.json`

Matching `AGENTS.md` block

2. `AGENTS.md` = tell the agent how to escalate

Matching `AGENTS.md`

Then in `AGENTS.md`

Matching `AGENTS.md`