#Every few mins openclaw changes the default model back to 5.4 why is this?

1 messages · Page 1 of 1 (latest)

limber spindle
#

it was set via openclaw models command and confirmed via openclaw config get agents.defaults.model.primary that it was openai/gpt-5.3-codex

arctic zincBOT
nova harborBOT
#

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

arctic zincBOT
nocturne mortarBOT
#

I’m checking the docs and source for what could be rewriting that config, because that definitely sounds wrong if it keeps flipping back on its own.

#

I found one important clue already: openai/gpt-5.3-codex* is not a normal direct OpenAI API path in current docs. The Codex-specific route is openai-codex/*, and the direct openai/* side is centered on 5.4 now. I’m checking whether OpenClaw is auto-normalizing that back during auth/setup or whether you’ve got two config writers fighting each other.

#

That helps, and I think the big clue is the model ref itself.

openai/gpt-5.3-codex does not look like a current supported direct OpenAI default in the current docs/source. Right now the split is basically:

  • direct OpenAI API: openai/gpt-5.4
  • Codex OAuth: openai-codex/gpt-5.4
  • Spark, if entitled: openai-codex/gpt-5.3-codex-spark

So if OpenClaw can’t resolve openai/gpt-5.3-codex, it can fall back at runtime to the default, which would explain why you keep seeing 5.4.

Also, that fallback should not be rewriting config every few minutes by itself. If the file is truly changing, the usual suspects are:

  1. Config (cli) vs Config (service) mismatch
  2. a second gateway/service/process writing config
  3. an auth/setup flow that ran with --set-default

Can you paste these?

# 
openclaw --version
openclaw models status
openclaw gateway status --deep

And if you catch it during a flip:

openclaw logs --follow

If logs show something like Model "... could not be resolved. Falling back to default ..." that’s the smoking gun.

If you want the Codex route, I’d try this instead:

limber spindle
#

openai/gpt-5.3-codex is available when running openclaw models list

<openclaw --version>
OpenClaw 2026.4.9 (0512059)
</openclaw --version>

<openclaw models status>
Config : /data/.openclaw/openclaw.json
Agent dir : /data/.openclaw/agents/main/agent
Default : openal/gpt-5.3-codex
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : gpt -> openai/gpt-5.2, GPT -> openai/gpt-5.1-codex
Configured models (4): openai/gpt-5.2, openai/gpt-5.1-codex, openai/gpt-5.3-codex, openal/gpt-5.3-codex

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

  • openai effective=profiles:/data/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openai:default=ref(env:OPENAI_API_KEY) | env=sk-proj-...hNbjIfkA | source=env: OPENAI_API_KEY

Missing auth

  • openal openclaw configure or set an API key env var.

OAuth/token status

  • none
    </openclaw models status>

<openclaw gateway status --deep>
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-10.log

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

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (systemctl not available; systemd user services are required on Linux.)
RPC probe: ok

systemd user services unavailable.
systemd user services are unavailable; install/enable systemd or run the gateway under your supervisor.
If you're in a container, run the gateway in the foreground instead of openclaw gateway.

Listening: 127.0.0.1:18789, [::1]:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
</openclaw gateway status --deep>

nocturne mortarBOT
#

Aha, I think we found it.

Your models status output says the active default is openal/gpt-5.3-codex, not openai/gpt-5.3-codex.

That typo matters a lot:

  • Default : openal/gpt-5.3-codex
  • Missing auth : openal ...

So OpenClaw currently thinks the provider is openal, which is bogus. That also explains why it behaves weirdly and falls away from the model you intended.

Also, good news: Config (cli) and Config (service) are the same path, so this does not look like a CLI vs daemon config mismatch.

What I’d do

Open /data/.openclaw/openclaw.json and check both:

  • agents.defaults.model.primary
#
  • agents.defaults.models

Make sure they use:

"openai/gpt-5.3-codex"

and remove any bad entry like:

"openal/gpt-5.3-codex"

Then restart the gateway however you’re launching it.

Why I think this is the root cause

#

Your own status output already shows the bad provider id is present and active, so even if models list shows the correct openai/... model exists, your configured default is currently pointing at the typoed one.

One more check

Can you paste this too:

openclaw config get agents.defaults.model.primary
openclaw config get agents.defaults.models

If those show openal/..., that’s the bug right there.

If you did set openai/... and it later mutated into openal/... by itself, that smells like a real bug, and then it’s worth filing an issue here:
https://github.com/openclaw/openclaw/issues

Glad you pasted the status output, that made this way clearer.

limber spindle
#

give me the commands to paste in terminal to first remove the typo

nocturne mortarBOT
#

Yep, try this exact block first:

openclaw config unset 'agents.defaults.models[openal/gpt-5.3-codex]'
openclaw config set agents.defaults.model.primary openai/gpt-5.3-codex
openclaw config get agents.defaults.model.primary
openclaw config get agents.defaults.models

What it does:

  1. removes the bad openal/... model entry
  2. sets the primary back to openai/...
  3. prints both values so you can verify

If that looks right afterward, restart the gateway/container the same way you normally run it, then check:

# 
openclaw models status

If config unset says the openal/... path doesn’t exist, paste that error here, because then the typo is probably only in the primary value and not the allowlist entry.

limber spindle
#

i did all that but its back to gpt-5.4 agains

nocturne mortarBOT
#

I’m checking one more thing, because “it keeps snapping back” sounds like something else is actively re-applying a provider default, not just a typo.

#

Got it, then the typo wasn’t the whole story.

If it is truly going back to gpt-5.4 again, something is actively rewriting your config.

Since your gateway status showed no systemd user service, the most likely culprit is whatever is launching OpenClaw in that container/supervisor/entrypoint. Anything that runs one of these can reset OpenAI back to its default:

  • openclaw configure
  • openclaw onboard
  • openclaw models auth login --provider openai --set-default

Can you paste these right after it flips back:

openclaw config get agents.defaults.model --json
openclaw config get agents.defaults.model.primary
#

And also paste how you start OpenClaw:

  • your Docker Compose service / entrypoint / command
  • or the shell script / supervisor command you use

That part matters now. I’m suspicious the startup path is re-running setup and re-applying the OpenAI default model.

If you want a quick grep on the host/container, this should help too:

grep -RniE 'openclaw (configure|onboard|models auth login).*set-default|openclaw configure|openclaw onboard' .

If that finds your startup script, that’s probably the bug.

limber spindle
#

this was because deploying on coolify there is an OPENCLAW_PRIMARY_MODEL env var

nocturne mortarBOT
#

Yep, that’ll do it.

OPENCLAW_PRIMARY_MODEL is overriding the file config, so Coolify was effectively re-applying the model on each deploy/restart.

Fix:

  • remove that env var in Coolify, or
  • set it to the exact model you want

Then redeploy/restart.

That also explains why openclaw config get ... looked right while runtime kept drifting back.

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