how to switch from gpt 5.4 to 5.1?? | Friends of the Crustacean 🦞🤝 | Page 1

wide horizon Apr 14, 2026, 8:49 PM

#

how to switch from gpt 5.4 to 5.1?? in the openclaw configure command i did authenticate, but it still says only codex 5.4

verbal wingBOT Apr 14, 2026, 8:52 PM

#

configure auth and model selection are separate.

What’s happening:

Codex auth gives you the openai-codex/* route
that’s why you’re only seeing Codex GPT-5.4 there

If you want to change the model, use:

pnpm openclaw models set <provider/model>

or in chat:

/model

#

If you specifically want GPT-5.1, you probably need the direct OpenAI API path, not Codex OAuth:

authenticate with OpenAI API key (openai, not openai-codex)
then set:

pnpm openclaw models set openai/gpt-5.1

But first check whether your install/catalog actually exposes it:

pnpm openclaw --version
pnpm openclaw models status
pnpm openclaw models list --provider openai

#

If gpt-5.1 does not show up there, this version/provider path is not exposing it.

Docs:

If you paste the output of:

pnpm openclaw --version
pnpm openclaw models status

I can tell you the exact next step.

wide horizon Apr 14, 2026, 9:48 PM

#

I think the slowliness problem it wasn't because of ollama I guess, I am trying to run codex 5.4 again as I have tokens now but it's also super slow, I did a basic question and it's thinking for 6 minutes still

verbal wingBOT Apr 14, 2026, 9:49 PM

#

yeah, 6 minutes for a basic question is not normal.

A few likely causes:

session thinking is set too high
In that thread, send:
```
/thinking
/thinking low
/fast on
```
If it was on high or xhigh, that alone can make GPT/Codex feel painfully slow.
you’re using Codex for normal chat
openai-codex/gpt-5.4 is more coding-oriented and can be slower than the normal OpenAI route for simple questions.

#

stuck session/context
Try a fresh thread/session and test again after /thinking low + /fast on.

If it’s still slow, please paste:

pnpm openclaw --version
pnpm openclaw models status
pnpm openclaw status --all

Optional but useful: turn on

/verbose on

#

then ask one simple prompt again. If it shows tool calls, it may be getting stuck on tools, not just raw model latency.

Docs:

Paste those outputs and I’ll help narrow it down fast.

wide horizon Apr 14, 2026, 9:54 PM

#

maybe its the WSL machine can i reboot it?? and Ollama might be causing slowliness?

verbal wingBOT Apr 14, 2026, 9:54 PM

#

yeah, restarting WSL is a reasonable thing to try.

And yes, Ollama can absolutely make things feel slow if it’s eating CPU/RAM, even if OpenClaw is currently using Codex instead.

What I’d do, in order:

Stop Ollama for a minute, or unload any running models
Restart WSL
from Windows PowerShell:
```
wsl --shutdown
```
open WSL again
test in a fresh thread/session with:
```
/thinking low
```

#

   /fast on

Important nuance:

if you’re not using an Ollama model right now, Ollama is not the model backend for that reply
but it can still slow the machine down by hogging memory/CPU and pushing WSL into swap

So yes, I’d try that first.

After restart, if it’s still slow, paste:

pnpm openclaw --version
pnpm openclaw models status
pnpm openclaw status --all

#

and if you can, also tell me:

how much RAM the machine has
whether Ollama was actively running a model when OpenClaw got slow

wide horizon Apr 14, 2026, 9:55 PM

#

how can I shutdown all ollamas? it's daemon

verbal wingBOT Apr 14, 2026, 9:56 PM

#

easiest hard stop:

from Windows PowerShell:

wsl --shutdown

That shuts down the whole WSL VM, so the Ollama daemon stops too.

If you only want to stop Ollama inside WSL, try:

sudo systemctl stop ollama

If your distro doesn’t use systemd:

#

sudo service ollama stop

If you started it manually:

pkill -f "ollama serve"

Quick check:

pgrep -af ollama

If that prints nothing, it’s stopped.

#

To start it again later:

sudo systemctl start ollama

I’d honestly do wsl --shutdown first, it’s the cleanest reset.

wide horizon Apr 14, 2026, 10:06 PM

#

wsl --shudown

and login again did the trick, it seems to work now, I think that if I run out of tokens, I will have to setup an ollama model and reboot

verbal wingBOT Apr 14, 2026, 10:07 PM

#

nice, glad that fixed it 🦐

That usually means WSL got wedged, not that GPT/Codex itself was the problem.

And one important nuance: if you later switch to Ollama, you shouldn’t need a reboot every time. Usually you can just switch models. I’d only restart WSL again if the box gets stuck or memory pressure gets nasty.

One caution though: Ollama is okay for basic chat/testing, but usually much worse for tool-calling/agentic OpenClaw work. So if you run out of tokens, local can work as a fallback, just don’t expect the same speed/reliability.

Docs:

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

wide horizon Apr 14, 2026, 11:30 PM

#

the agent always forgets to update the README and commit changes in every interaction, how can I fix that?

verbal wingBOT Apr 14, 2026, 11:30 PM

#

best fix: put it in AGENTS.md as a standing order, not in chat.

Also, tiny opinion: I would not require a commit on every interaction. That gets messy fast.
Better rule: every completed coding task must either commit, or explicitly say why it didn’t.

Something like this in AGENTS.md:

## Definition of Done

Before declaring a coding task complete:

1. Update `README.md` if behavior, setup, commands, or usage changed.
2. Run relevant checks/tests when practical.
3. Review `git diff` and `git status`.
4. Commit all task-related changes with a clear message.

#

5. Do not finish with a dirty worktree unless the user explicitly asked for no commit.

If `README.md` was not updated, explicitly state why it was unnecessary.
If a commit was not created, explicitly state why.

Two important nuances:

Use AGENTS.md, not BOOTSTRAP.md or a one-off prompt. AGENTS.md is loaded every session.
If you use subagents, this matters even more, because they reliably get AGENTS.md + TOOLS.md.

If your repo is not the agent workspace, then either:

make that repo the workspace, or
use the bootstrap-extra-files hook to inject that repo’s AGENTS.md.

Docs:

#

If you want, I can help you write a good AGENTS.md snippet for this exact workflow.

wide horizon Apr 14, 2026, 11:34 PM

#

oh lol I got the default agents on the main agent... it's my director, he has marketing, lowcode, uiux and reverser

those subagents usage is obvious:

marketing is a sales and marketing expert focused on website
lowcode is a low code programmer
uiux is a front end developer or designer
reverser is a reverse engineer, winapi, malware expert

the subagents are completed, only the director is default agents.md

verbal wingBOT Apr 14, 2026, 11:34 PM

#

ah, yep, that would explain it.

If the director still has the default AGENTS.md, then the one coordinating everything has no real completion rules, so it’ll delegate fine but forget the final hygiene stuff.

What to do:

1) Fix the director `AGENTS.md`

That one should contain:

delegation map
verification rules
definition of done

Example:

#

## Role
You are the director/orchestrator.

Delegate by specialty:
- marketing: sales/marketing/website messaging
- lowcode: low-code programming and automation
- uiux: frontend and design
- reverser: reverse engineering, WinAPI, binary analysis

## Completion Gate

Before telling the user a task is complete:

1. Verify the responsible subagent actually finished the work.
2. Review `git diff` and `git status`.

#

3. Update `README.md` if behavior, setup, usage, or commands changed.
4. Ensure changes are committed with a clear message.
5. Do not end with a dirty worktree unless the user explicitly asked for no commit.
6. If README was not updated, state why it was unnecessary.
7. If no commit was made, state why.

2) Also add a small version to the coding agents

Especially lowcode and probably uiux.

Because belt-and-suspenders is better here:

director enforces it
worker also knows to do it

3) Keep role rules separate from workflow rules

Good pattern:

#

director = orchestration + QA + definition of done
subagents = specialist behavior + local guardrails

So yeah, you found the right root cause.

If you want, I can draft a clean director AGENTS.md for that exact 4-agent setup.

wide horizon Apr 14, 2026, 11:37 PM

#

"Tiny hitch, the spawn call needs explicit agent IDs in this runtime."

how to disable that? so he can just spawn them without my manual intervention

verbal wingBOT Apr 14, 2026, 11:37 PM

#

you can disable it, but I probably wouldn’t for your setup.

The config switch

For normal subagent spawns, the guard is:

agents.defaults.subagents.requireAgentId: false

or per-agent:

agents.list[].subagents.requireAgentId: false

But here’s the important nuance

That does not make OpenClaw magically pick marketing / lowcode / uiux / reverser.

#

If agentId is omitted, the spawn does not automatically route to one of your specialist agents. For a director pattern, the better fix is:

allow those agents from the director
teach the director their exact IDs in AGENTS.md
let the director call sessions_spawn with the right agentId itself

Example:

{
  agents: {
    list: [
      {
        id: "director",
        default: true,
        subagents: {

#

          allowAgents: ["marketing", "lowcode", "uiux", "reverser"],
          requireAgentId: false
        }
      }
    ]
  }
}

And in the director AGENTS.md, tell it plainly:

use agentId: "marketing" for marketing/website copy
use agentId: "lowcode" for low-code implementation
use agentId: "uiux" for frontend/design
use agentId: "reverser" for reverse engineering

#

So, no manual intervention from you is needed.
The director just needs to know the IDs and be allowed to target them.

My recommendation:

set allowAgents
optionally leave requireAgentId: true
make the director explicitly choose the specialist itself

That’s more reliable than disabling the guard and hoping it guesses.

Docs:

If you want, I can show the exact openclaw.json snippet for your 5-agent layout.

wide horizon Apr 14, 2026, 11:42 PM

#

there is any problem with Telegram??

[15/04/2026 1:41] Adrian H.: check README.md in TibiaBot project, you will resume the work together with your subagents
[15/04/2026 1:42] Director: I’ve got the README context. I hit a session-spawn quirk on Telegram thread binding, so I’m switching to one-shot delegate runs instead and continuing.

verbal wingBOT Apr 14, 2026, 11:43 PM

#

not a general Telegram failure, no, this is probably a feature/support mismatch.

What the docs currently say:

Telegram itself is fine
Persistent thread-bound subagent sessions via sessions_spawn(..., thread: true) are documented as Discord-only
Telegram does support thread-bound ACP sessions in forum topics

So this line:

“session-spawn quirk on Telegram thread binding”

is very likely the director trying to do subagent thread binding on Telegram, which is not the normal supported path right now.

Practical fix

For Telegram:

#

use one-shot subagent runs for delegation, without thread binding
or, if you want a persistent topic-bound worker, use ACP thread binding instead
or bind a Telegram topic directly to an agent with topic routing

So yeah, the fallback behavior you saw actually makes sense.

Docs:

If you want, I can show the clean pattern for Telegram + director + specialist agents so it stops tripping on that.

wide horizon Apr 14, 2026, 11:44 PM

#

yes show me the clear pattern

verbal wingBOT Apr 14, 2026, 11:45 PM

#

yep, here’s the clean Telegram pattern I’d use.

Recommended pattern

1) Bind the Telegram topic to director

Use Telegram topic routing so the chat always lands on the director first.

{
  agents: {
    list: [
      {
        id: "director",
        default: true,
        subagents: {
          allowAgents: ["marketing", "lowcode", "uiux", "reverser"],

#

          requireAgentId: true
        }
      },
      { id: "marketing" },
      { id: "lowcode" },
      { id: "uiux" },
      { id: "reverser" }
    ]
  },

  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {

#

            "42": {
              agentId: "director",
              requireMention: false
            }
          }
        }
      }
    }
  }
}

So:

Telegram topic 42 → director
director decides who to delegate to

#

2) Director spawns specialists as one-shot subagents

On Telegram, don’t do:

sessions_spawn(..., thread: true) for normal subagents

Do this instead:

sessions_spawn with explicit agentId
no thread binding
one-shot delegate run
results come back to director
director replies in the same Telegram topic

That means in the director AGENTS.md you want something like:

#

## Telegram delegation rule

When delegating on Telegram:
- use one-shot subagent runs
- do NOT request thread binding for normal subagents
- always choose an explicit agentId:
  - marketing
  - lowcode
  - uiux
  - reverser
- gather results, verify them, then answer in the current Telegram topic

3) If you want a persistent specialist chat, give it its own Telegram topic

#

Example:

Topic A → director
Topic B → lowcode
Topic C → marketing

{
  channels: {
    telegram: {
      groups: {
        "-1001234567890": {
          topics: {
            "42": { agentId: "director" },
            "43": { agentId: "lowcode" },
            "44": { agentId: "marketing" }

#

That’s the cleanest persistent setup on Telegram.

4) Use ACP only if you want a thread-bound external harness

Telegram does support ACP topic binding, but that’s a different thing from normal subagents.

So the rule of thumb is:

#

normal OpenClaw specialists → one-shot subagents
persistent Telegram topic per role → topics.<id>.agentId
persistent Codex/Claude Code/Gemini CLI in-topic → ACP thread binding

Short version

Best Telegram architecture:

Telegram topic → director
director → one-shot specialists (agentId explicit)
if you need persistent specialists, bind separate Telegram topics directly to those agents

Docs:

#how to switch from gpt 5.4 to 5.1??

1) Fix the director AGENTS.md

2) Also add a small version to the coding agents

3) Keep role rules separate from workflow rules

The config switch

But here’s the important nuance

Practical fix

Recommended pattern

1) Bind the Telegram topic to director

2) Director spawns specialists as one-shot subagents

3) If you want a persistent specialist chat, give it its own Telegram topic

4) Use ACP only if you want a thread-bound external harness

Short version

1) Fix the director `AGENTS.md`