#Switch provider/model and now getting 400:The requested model not supported error

1 messages · Page 1 of 1 (latest)

olive musk
#

2026-03-07T22:08:59.341Z [agent/embedded] embedded run agent end: runId=cb3f8862-0db6-4fd0-af44-e858516dd3d3 isError=true error=HTTP 400 invalid_request_error: The requested model is not supported.

little axleBOT
#

That HTTP 400 invalid_request_error: The requested model is not supported is almost always the provider rejecting the model id you’re sending (wrong model name for that provider, wrong provider prefix, or a stale alias that resolves to something the provider doesn’t offer).

A quick way to pinpoint it:

  1. What version + what model is OpenClaw actually trying to run?
openclaw --version
openclaw models status

(or in-chat: /model status)

  1. Make sure your default model is a full provider/model string
    If you set something like gpt-… without the provider prefix, OpenClaw may assume the wrong provider (there’s a deprecation fallback that can bite here). Your config should look like:
  • agents.defaults.model.primary: "openai/…" (OpenAI API key)
  • or agents.defaults.model.primary: "openai-codex/…" (Codex OAuth)
    …etc.
#
  1. Pick a known-good model from your own gateway’s list (no guessing):
  • In chat: /model list
  • On the gateway host: openclaw models list

If you paste the output of openclaw --version + the top part of openclaw models status (it redacts secrets), I can tell you exactly which provider/model pairing is mismatched.

Docs reference (same checklist): https://docs.openclaw.ai/help/faq#models-defaults-selection-aliases-switching

olive musk
# little axle That `HTTP 400 invalid_request_error: The requested model is not supported` is a...

openclaw --version
openclaw models status
2026.3.2

🦞 OpenClaw 2026.3.2 (85377a2) — Your terminal just grew claws—type something and let the bot pinch the busywork.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : github-copilot/gemini-3-pro-preview
Fallbacks (17): github-copilot/claude-opus-4.5, github-copilot/claude-opus-4.6, github-copilot/claude-sonnet-4.5, github-copilot/claude-sonnet-4.6, github-copilot/gemini-3-flash-preview, github-copilot/gemini-3-pro-preview, github-copilot/gpt-5.2, github-copilot/gpt-5.2-codex, google-gemini-cli/gemini-3-flash-preview, google-gemini-cli/gemini-3-pro-preview, google-gemini-cli/gemini-3.1-pro-preview, openai-codex/gpt-5.2, openai-codex/gpt-5.2-codex, openai-codex/gpt-5.3-codex, openai-codex/gpt-5.3-codex-spark, github-copilot/gemini-3.1-pro-preview, github-copilot/claude-haiku-4.5
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (18): github-copilot/claude-opus-4.5, github-copilot/claude-opus-4.6, github-copilot/claude-sonnet-4.5, github-copilot/claude-sonnet-4.6, github-copilot/gemini-3-flash-preview, github-copilot/gemini-3-pro-preview, github-copilot/gpt-5.2, github-copilot/gpt-5.2-codex, google-gemini-cli/gemini-3-flash-preview, google-gemini-cli/gemini-3-pro-preview, google-gemini-cli/gemini-3.1-pro-preview, openai-codex/gpt-5.2, openai-codex/gpt-5.2-codex, openai-codex/gpt-5.3-codex, openai-codex/gpt-5.3-codex-spark, github-copilot/gemini-3.1-pro-preview, github-copilot/claude-haiku-4.5, github-copilot/gpt-4o

#

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : on
Providers w/ OAuth/tokens (5): anthropic (1), github-copilot (1), google-antigravity (1), google-gemini-cli (1), openai-codex (1)

  • anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | anthropic:manual=token:Symbol(c...:cancel)
  • github-copilot effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | github-copilot:github=token:ghu_lJt0...Jp1EBNTK
  • google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=[G...Y]
  • google-antigravity effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | google-antigravity:richard.r4hosting@gmail.com=OAuth (richard.r4hosting@gmail.com)
  • google-gemini-cli effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | google-gemini-cli:richard.r4hosting@gmail.com=OAuth (richard.r4hosting@gmail.com)
  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth

OAuth/token status

little axleBOT
#

Your models status output basically explains the 400:

  • Default: github-copilot/gemini-3-pro-preview

That means you’re asking the GitHub Copilot provider to serve a Gemini model id. Copilot model availability is plan-dependent, and (per the Copilot provider docs) the “known-good” path is to set something like github-copilot/gpt-4o as the default. When Copilot doesn’t recognize the model id, you get exactly: “requested model is not supported”.

Fix (pick one direction):

A) Stay on GitHub Copilot → switch default to a Copilot-supported model

Docs example:

openclaw models set github-copilot/gpt-4o
openclaw gateway restart

Copilot docs: https://docs.openclaw.ai/providers/github-copilot

B) If you actually want Gemini → use a Gemini provider as the default

#

You already have google-gemini-cli/... in your configured models, so set the default to that provider instead of github-copilot/...:

openclaw models set google-gemini-cli/gemini-3-pro-preview
openclaw gateway restart

Quick confirmation (live probe)

This will tell you immediately if the provider accepts the currently configured default:

openclaw models status --probe --probe-provider github-copilot

If you paste the probe output (just that section), I can tell you which side (provider vs model id) is still mismatched.

#

Nice — that auth output says credentials are fine (Copilot token looks valid, Gemini CLI OAuth looks valid, etc.). So this isn’t an “API key missing” problem.

What’s left is almost certainly: you’re still requesting a model id that the provider doesn’t accept.

Right now your default is:

  • github-copilot/gemini-3-pro-preview

If you want to use GitHub Copilot, switch the default to a Copilot-supported model (the Copilot docs’ known-good example is github-copilot/gpt-4o), then restart:

openclaw models set github-copilot/gpt-4o
openclaw gateway restart

If you actually want Gemini, keep Gemini but switch providers:

# 
openclaw models set google-gemini-cli/gemini-3-pro-preview
openclaw gateway restart

After doing that, run a live probe so we can see the exact rejection (if any):

openclaw models status --probe --probe-provider github-copilot

Paste the probe result section (it’ll include the specific model it tried + the error).

olive musk
#

Auth probes
┌─────────────────────────────────────┬───────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├─────────────────────────────────────┼───────────────────────────────┼────────────┤
│ github-copilot/gemini-3-pro-preview │ github-copilot:github (token) │ ok · 5.9s │
└─────────────────────────────────────┴───────────────────────────────┴────────────┘

#

OAuth/token status

little axleBOT
#

Good signal: the live probe succeeded for github-copilot/gemini-3-pro-preview. So Copilot auth is fine and that model id exists.

That makes me suspect the 400 you’re seeing in real runs is not “model doesn’t exist”, but “this model isn’t supported for the kind of request OpenClaw is making” (tool/function calling, response_format, etc.). Probes are usually a tiny plain chat request; a normal agent run is “chat + tools”.

Two quick tests:

1) Switch Copilot default to a “known to work with tools” Copilot model

openclaw models set github-copilot/gpt-4o
openclaw gateway restart

Then try sending a normal message again.

2) If you want Gemini specifically, use Gemini as the provider (not Copilot)

# 
openclaw models set google-gemini-cli/gemini-3-pro-preview
openclaw gateway restart

If it still errors

Paste 10–30 log lines around the failing request (that’s where it’ll show which model it actually tried). Easiest:

openclaw logs --follow

Then trigger the failure once, and copy the block that includes the 400 plus the lines just above it (usually includes model=... / provider info).

#

Cool — that probe result is key:

github-copilot/gemini-3-pro-preview + github-copilot:github → ok

So Copilot+Gemini itself is not rejected. That means the HTTP 400 … requested model is not supported you’re seeing is coming from a different model than the one you just probed (most commonly a fallback, or a session that’s pinned to another model).

Two concrete next steps to identify it:

1) Probe the other providers that are in your fallback chain

openclaw models status --probe --probe-provider openai-codex
openclaw models status --probe --probe-provider google-gemini-cli

2) Grab the log line that shows which model was actually requested when it fails

Run:

# 
openclaw logs --follow

Then trigger the failure once, and paste the ~20 lines around it (there’s usually a line right before the 400 that includes the exact model/provider used for that run).

If you want a fast “get unblocked” test while we debug: temporarily set the default to github-copilot/gpt-4o, restart, and try a fresh /new in the chat that’s failing. If that fixes it, we know the failure is in a fallback/pinning path rather than Copilot auth.

olive musk
#

Here's part of the gateway.err.log:

2026-03-07T21:59:46.828Z [agent/embedded] embedded run agent end: runId=a51d41c8-e814-4f91-9171-e5d10a05cc7d isError=true error=400 The requested model is not supported.
2026-03-07T21:59:58.768Z [agent/embedded] embedded run agent end: runId=b4d919be-d243-494d-a543-a38ea57bae9c isError=true error=HTTP 400 invalid_request_error: The requested model is not supported.
2026-03-07T22:08:59.341Z [agent/embedded] embedded run agent end: runId=cb3f8862-0db6-4fd0-af44-e858516dd3d3 isError=true error=HTTP 400 invalid_request_error: The requested model is not supported.
2026-03-07T22:18:26.657Z [agent/embedded] embedded run agent end: runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a isError=true error=HTTP 400 invalid_request_error: The requested model is not supported.

little axleBOT
#

Those gateway.err.log lines are the summary line only — they don’t include which model/provider was used for that run, so we need a tiny bit more context to stop guessing.

Two things to check next (these usually reveal the culprit fast):

1) Verify the gateway service is using the same config the CLI is showing

Please run and paste the top part:

openclaw gateway status

In particular, I’m looking for Config (cli) vs Config (service). If those differ, the gateway can be running an older/different config (and keep failing) even though openclaw models status looks good in your shell. (FAQ calls this out; fix is usually openclaw gateway install --force then restart.)

2) Grab the detailed log lines for one specific runId

Pick one runId (e.g. 12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a) and search in the non-err gateway log:

# 
rg "runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" ~/.openclaw/logs/gateway.log -n
# or:
grep -n "runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" ~/.openclaw/logs/gateway.log | head -50

That surrounding block usually shows the model string that was attempted right before the 400.

Paste:

  • openclaw gateway status output
  • and the few lines around that runId from gateway.log

…and we can point to the exact provider/model that’s being rejected.

olive musk
#

openclaw gateway status

🦞 OpenClaw 2026.3.2 (85377a2) — Type the command with confidence—nature will provide the stack trace if needed.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-03-07.log
Command: /usr/local/opt/node@22/bin/node /usr/local/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 22439)
RPC probe: ok

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

#

grep -n "runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" ~/.openclaw/logs/gateway.log | head -50

richardshepard@Richards-MacBook-Air ~ %

little axleBOT
#

Config mismatch is ruled out (CLI + service both use ~/.openclaw/openclaw.json, RPC probe ok). Good.

Now we just need the one missing piece: which model was actually requested in those failing runs. The gateway.err.log lines don’t include it, but the file log does (the one gateway status points to):

/tmp/openclaw/openclaw-2026-03-07.log

Can you grep one of the failing runIds in that file and paste the surrounding block?

Example (use the most recent failing runId you saw, e.g. 12d06e90...):

LOG=/tmp/openclaw/openclaw-2026-03-07.log
RUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a

grep -n "$RUN" "$LOG" | head
# then take the line number you get (say it's 1234) and paste context:
# 
sed -n '1210,1255p' "$LOG"

(If it’s JSON logs and runId= doesn’t match, try:)

grep -n "12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" "$LOG" | head

That snippet should show the provider/model right before the 400, and then we can say exactly what to change (or whether it’s a bug worth filing).

#

Yep — no output from ~/.openclaw/logs/gateway.log is expected. On macOS that file is usually just the LaunchAgent stdout/stderr wrapper, and it often doesn’t contain the embedded runIds.

The runIds you’re seeing are in the structured file log the gateway status printed:

/tmp/openclaw/openclaw-2026-03-07.log

Try searching for the UUID without the runId= prefix (it’s often JSON like "runId":"..."):

LOG=/tmp/openclaw/openclaw-2026-03-07.log
grep -n "12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" "$LOG" | head -20

Once you get a line number (say it’s 1234), grab a little context:

# 
sed -n '1210,1255p' "$LOG"

Paste that block here — it should include the provider/model right before the 400.

olive musk
# little axle Yep — **no output from `~/.openclaw/logs/gateway.log` is expected**. On macOS th...

LOG=/tmp/openclaw/openclaw-2026-03-07.log
RUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a

grep -n "$RUN" "$LOG" | head
1001:{"0":"{"subsystem":"agent/embedded"}","1":"embedded run agent end: runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a isError=true error=HTTP 400 invalid_request_error: The requested model is not supported.","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-03-07T22:18:26.655Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js","filePathWithLine":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427","method":"logToFile"}},"time":"2026-03-07T17:18:26.655-05:00"}
richardshepard@Richards-MacBook-Air ~ %

little axleBOT
#

Perfect — that confirms we’re looking at the right log file, but that line is still only the end-of-run summary. The model/provider info (and usually the real upstream error) is typically logged a few lines before line 1001.

Can you paste ~30 lines of context around it?

LOG=/tmp/openclaw/openclaw-2026-03-07.log
sed -n '970,1015p' "$LOG"

Also, since your fallback list includes openai-codex models (and that’s a common source of “model not supported” when a fallback kicks in), run this probe too and paste it:

openclaw models status --probe --probe-provider openai-codex

With those two snippets we’ll be able to say “it’s failing on provider X model Y” (and whether it’s the primary request or a fallback after the first attempt).

olive musk
# little axle Perfect — that confirms we’re looking at the right log file, but that line is st...

LOG=/tmp/openclaw/openclaw-2026-03-07.log
sed -n '970,1015p' "$LOG"....That log is too big to paste into chat here. Auth probes
┌──────────────────────┬──────────────────────────────┬──────────────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────────┼──────────────────────────────┼──────────────────────────────────────────┤
│ openai-codex/gpt-5.2 │ openai-codex:default (oauth) │ unknown · 13.4s │
│ │ │ ↳ LLM request timed out. │
└──────────────────────┴──────────────────────────────┴──────────────────────────────────────────┘
Probed 1 target in 13.5s

The reason I switched models is due to hitting the limit with openai-codex. Is it trying to use codex somewhere else

little axleBOT
#

Yes — it can still try Codex even if you switched your primary model, as long as openai-codex/... is still present in your fallback chain (fallbacks are “what to try next when the primary attempt errors”).

Given your probe shows openai-codex/gpt-5.2 is currently timing out, you definitely don’t want Codex sitting in fallbacks right now — it’ll slow/fail runs whenever OpenClaw falls back.

Check + remove Codex from fallbacks

openclaw models fallbacks list

If you see any openai-codex/... entries, remove them (repeat per entry you want gone):

openclaw models fallbacks remove openai-codex/gpt-5.2
# (and any other openai-codex/... you have in that list)

Or for a quick “debug reset”, clear fallbacks entirely (then you’ll know it’s not falling back into Codex at all):

# 
openclaw models fallbacks clear

Docs for these commands: https://docs.openclaw.ai/concepts/models#cli-commands

One more thing (the 400)

That sed -n '970,1015p' output is not “too big” if you trim it to just a few lines. Since the error line is at ~1001, paste just:

LOG=/tmp/openclaw/openclaw-2026-03-07.log
sed -n '996,1005p' "$LOG"

That’s usually enough to show whether the 400 came from the primary model or from a fallback (like Codex).

olive musk
#

LOG=/tmp/openclaw/openclaw-2026-03-07.log
sed -n '996,1005p' "$LOG"
{"0":"{"subsystem":"gateway/channels/discord"}","1":"[default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway/channels/discord"}","parentNames":["openclaw"],"date":"2026-03-07T22:17:48.147Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js","filePathWithLine":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427","method":"logToFile"}},"time":"2026-03-07T17:17:48.148-05:00"}
{"0":"{"subsystem":"gateway/channels/discord"}","1":"[default] starting provider (@RockyChats)","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"gateway/channels/discord"}","parentNames":["openclaw"],"date":"2026-03-07T22:17:48.152Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js","filePathWithLine":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427","method":"logToFile"}},"time":"2026-03-07T17:17:48.153-05:00"}

#

That's 996--1001

little axleBOT
#

That sed -n '996,1005p' snippet is just gateway startup logs (Discord provider starting) — it’s not the failing run. The easiest way to grab the right block is to anchor on the runId line number again, because it’s clearly not at ~1001 in your current file anymore.

Try this (it prints only a few lines, safe to paste):

LOG=/tmp/openclaw/openclaw-2026-03-07.log
RUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a

# show the line number where the runId occurs
grep -n "$RUN" "$LOG" | head -1

Then take that line number N and run:

sed -n "$((N-5)),$((N+5))p" "$LOG"
#

On your actual question: yes, OpenClaw can still be trying Codex even after you “switched models”, if openai-codex/... is still in your fallbacks. Fallbacks are attempted whenever the primary model errors.

To stop it from ever falling back into Codex:

openclaw models fallbacks list
openclaw models fallbacks remove openai-codex/gpt-5.2   # repeat for any openai-codex/... you see
# or the blunt debug hammer:
openclaw models fallbacks clear
openclaw gateway restart

Docs: https://docs.openclaw.ai/concepts/models#cli-commands

Also: your Codex probe is timing out, not 400’ing — so if you’re seeing a 400 “model not supported”, it’s quite possibly a Copilot fallback model getting rejected (not Codex). The runId context block will tell us which one.

#

Got it — but the 996–1001 block you pasted is still just Discord channel startup (gateway/channels/discord … starting provider). The actual 400 “requested model is not supported” line is a different log entry (and may be later in the file), so line ranges aren’t a reliable way to find it.

If you want to stop chasing logs and just get unblocked, do this “hard isolate”:

1) Stop any Codex usage by removing fallbacks

openclaw models fallbacks clear

2) Set a single known-good primary model (Copilot example)

openclaw models set github-copilot/gpt-4o
openclaw gateway restart

Then test sending a message again.

#

If that works, you’ve proven the 400 was coming from a fallback model (very possibly an openai-codex/... entry, or another Copilot model in the old fallback chain). After that you can re-add fallbacks gradually with:

openclaw models fallbacks add <provider/model>

Docs: https://docs.openclaw.ai/concepts/models#cli-commands

If you really want to keep github-copilot/gemini-3-pro-preview as primary, do the same isolation but set that as primary first, then add only 1–2 safe fallbacks.

olive musk
# little axle That `sed -n '996,1005p'` snippet is just **gateway startup** logs (Discord prov...

LOG=/tmp/openclaw/openclaw-2026-03-07.log
RUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a

grep -n "$RUN" "$LOG" | head -1
1001:{"0":"{"subsystem":"agent/embedded"}","1":"embedded run agent end: runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a isError=true error=HTTP 400 invalid_request_error: The requested model is not supported.","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"agent/embedded"}","parentNames":["openclaw"],"date":"2026-03-07T22:18:26.655Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js:427:14","fileName":"subsystem-BfkFJ4uQ.js","fileNameWithLine":"subsystem-BfkFJ4uQ.js:427","fileColumn":"14","fileLine":"427","filePath":"usr/local/lib/node_modules/openclaw/dist/subsystem-BfkFJ4uQ.js","filePathWithLine":"usr/local/lib/n

olive musk
#

I did all that before I put in ths ticket

little axleBOT
#

Right — and that’s the problem: the agent end … error=HTTP 400 … line doesn’t include provider/model, and with your current log level you won’t see the line that does.

In OpenClaw, the line that prints the exact provider+model is:

embedded run start: runId=… provider=… model=…

…but it’s logged at debug level. So you need to temporarily turn on debug logging:

openclaw config set logging.level "debug"
openclaw gateway restart

Then reproduce one failure (send a message / whatever triggers it), and grab just these two lines for the same runId:

# 
LOG=/tmp/openclaw/openclaw-2026-03-07.log
RUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a

grep -n "embedded run start: runId=$RUN" "$LOG" | tail -1
grep -n "embedded run agent end: runId=$RUN" "$LOG" | tail -1

That first line will finally tell us whether it’s actually trying openai-codex/... (fallback) or some other provider/model.

After we’ve captured it, you can turn logs back down:

openclaw config set logging.level "info"
openclaw gateway restart
#

And yes: if openai-codex/... is still in your fallbacks, OpenClaw can still try it when the primary errors — clearing/removing Codex from fallbacks prevents that path.

#

Alright — then we’re at the point where the only thing that matters is what the gateway is actually trying to run now.

Can you paste these three things (they’re short), from after you made the changes:

  1. Current model + fallbacks (so we know what “should” happen):
openclaw models status
openclaw models fallbacks list
  1. One fresh failing run, showing the debug “run start” line (this tells us what it’s really using):
  • Trigger the failure once, then grab the newest runId from the “agent end” line:
openclaw logs --limit 200 --json | tail -n 200 | rg "embedded run agent end: runId=" | tail -1
#
  • Take that runId value and run:
RUN=<paste-runId-here>
LOG=/tmp/openclaw/openclaw-2026-03-07.log

grep -n "embedded run start: runId=$RUN" "$LOG" | tail -1
grep -n "embedded run agent end: runId=$RUN" "$LOG" | tail -1

If the “run start” line shows a different provider/model than you expect, it’s usually either:

  • the session is pinned to a specific model → fix by /new in that Discord thread (or /model <something>), or
  • you’re hitting a different agent than the one you edited → fix by checking openclaw models status --agent <id>.

Paste those outputs and we can call it precisely.

#

I believe you — but I don’t have access to whatever you ran “before the ticket”, and the one log line you’ve posted (embedded run agent end…) doesn’t contain the provider/model, so there’s nothing left to infer from that alone.

The quickest way to move this forward is: paste a single pasteable report that’s designed for exactly this situation:

openclaw status --all

It’s read-only and redacts secrets, and it usually includes enough log tail + model resolution to spot “it’s actually using X/Y”.

If status --all still doesn’t show the model, then we need exactly one debug line (not a whole log file):

  1. ensure debug logging is on:
openclaw config set logging.level "debug"
openclaw gateway restart
#
  1. reproduce once, then paste just the embedded run start: line for the failing runId (that line includes provider=… model=…).

Without either openclaw status --all or that single embedded run start line, we’re stuck in a loop where the symptom never names the model being rejected.

olive musk
#

It started working after the restart. I hadn't done of the of the model/provider changes. Here's all the commands I've ran since we started talking:
1020 openclaw --version\nopenclaw models status
1021 openclaw models status --probe --probe-provider github-copilot
1022 openclaw gateway status
1023 grep -n "runId=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" ~/.openclaw/logs/gateway.log | head -50\n\n
1024 grep -n "2b34ea6b-38ad-4911-9446-0cd2382e1a4cv" ~/.openclaw/logs/gateway.log | head -50\n\n
1025 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nRUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a\n\ngrep -n "$RUN" "$LOG" | head\n# then take the line number you get (say it's 1234) and paste context:
1026 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nRUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a\n\ngrep -n "$RUN" "$LOG" | head
1027 LOG=/tmp/openclaw/openclaw-2026-03-07.log\ngrep -n "12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a" "$LOG" | head -20
1028 sed -n '1000,1025p' "$LOG"
1029 sed -n '998,1005p' "$LOG"

#

1030 sed -n '998,1005p' "$LOG"
1031 openclaw models status --probe --probe-provider openai-codex\n
1032 sed -n '998,1005p' "$LOG" | grep fail
1033 sed -n '998,1005p' "$LOG" | grep error
1034 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nsed -n '970,1015p' "$LOG"
1035 openclaw models fallbacks list\n
1036 openclaw models fallbacks remove openai-codex/gpt-5.2\n# (and any other openai-codex/... you have in that list)
1037 openclaw models fallbacks remove openai-codex/gpt-5.2
1038 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nsed -n '996,1005p' "$LOG"
1039 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nsed -n '996,1005p' "$LOG"
1040 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nRUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a\n\n# show the line number where the runId occurs\ngrep -n "$RUN" "$LOG" | head -1
1041 LOG=/tmp/openclaw/openclaw-2026-03-07.log\nRUN=12d06e90-7bef-43a9-a3fc-2a2c67a4aa1a\n\ngrep -n "$RUN" "$LOG" | head -1
1042 openclaw config set logging.level "debug"\nopenclaw gateway restart

little axleBOT
#

Good — if it started working right after openclaw gateway restart without any model/provider edits, that points to the gateway being in a stale/bad runtime state (cached model registry/session pin, transient provider hiccup, or a wedged connection) and the restart forced a clean reload.

If it ever comes back, the fastest “sanity loop” is:

  • openclaw gateway restart
  • then in the failing chat: /new (clears any session model pinning)
  • then openclaw models status + openclaw gateway status to confirm what’s actually active

If this thread is resolved now, please mark the solution (right‑click the solution message → Apps → ✅ Mark Solution). This helps Answer Overflow index it for the next person who hits the same “400 model not supported” symptom.

#

Yep — looking at that command list, there were two behavior-changing things in there (besides just inspecting logs):

  1. you removed openai-codex/gpt-5.2 from fallbacks, and
  2. you restarted the gateway (and also flipped logging.level to debug).

So the “it worked after restart” result is consistent with either:

  • the gateway was falling back into Codex sometimes (and Codex was failing), and/or
  • the gateway runtime was wedged and the restart cleared it.

Now that it’s working, I’d do two cleanup steps:

1) Put logging back to normal (otherwise /tmp/openclaw/... will get huge)

openclaw config set logging.level "info"
openclaw gateway restart
#

2) Keep Codex out of fallbacks until your Codex limit resets

You already removed one entry; double-check you don’t have other openai-codex/... still in fallbacks:

openclaw models fallbacks list

If everything’s good now, please mark the solution message so this gets indexed.