#GPT 5.4 not responding

40 messages · Page 1 of 1 (latest)

gritty junco
#

Eyo Krill, do you got any idea why my GPT 5.4 is not responding after updating to 2026.4.12?

foggy lanternBOT
foggy violetBOT
#

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

foggy lanternBOT
waxen swanBOT
#

Most likely, yeah, I suspect this is an auth/model-route mismatch, not GPT-5.4 itself.

After 2026.4.12, the routes are more explicitly split:

  • openai/gpt-5.4 = direct OpenAI API, needs OPENAI_API_KEY
  • openai-codex/gpt-5.4 = ChatGPT/Codex OAuth
  • codex/gpt-5.4 = bundled Codex harness path

So if you’re signed in with ChatGPT/Codex OAuth but still using openai/gpt-5.4, it can fail because that model ref expects an API key now. Docs: https://docs.openclaw.ai/providers/openai and https://docs.openclaw.ai/concepts/model-providers

Can you paste these so I can narrow it down fast?

openclaw --version
openclaw status
openclaw models status
# 
openclaw logs --follow

Also tell me which model ref you’re actually using right now:

  • openai/gpt-5.4
  • openai-codex/gpt-5.4
  • codex/gpt-5.4

If you want, my first thing to try would be:

  • if you use Codex/ChatGPT login → switch to openai-codex/gpt-5.4
  • if you use an OpenAI API key → keep openai/gpt-5.4

Troubleshooting runbook here too: https://docs.openclaw.ai/gateway/troubleshooting

gritty junco
#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai-codex/gpt-5.4
Fallbacks (1) : minimax/MiniMax-M2.7
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (2): openai-codex/gpt-5.4, "openai-codex/gpt-5.4"

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): github-copilot (1), openai-codex (1)

  • 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_BFp4...JT3xMliv
  • minimax effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | minimax:global=sk-cp-NN...HqP-MgBk | env=sk-cp-ij...SJdZDJMo | source=env: MINIMAX_API_KEY
  • minimax-portal effective=env:sk-cp-ij...SJdZDJMo | env=sk-cp-ij...SJdZDJMo | source=env: MINIMAX_API_KEY
  • nvidia effective=models.json:nvapi-aO...UEsAtWWN | models.json=nvapi-aO...UEsAtWWN | source=models.json: ~/.openclaw/agents/main/agent/models.json
  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:cosmin.darius123@gmail.com=OAuth (cosmin.darius123@gmail.com)
  • openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...36ff1ea7 | models.json=sk-or-v1...w5x6y7z8 | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

waxen swanBOT
#

That helps, yeah.

Your OAuth looks healthy, and openai-codex/gpt-5.4 is the right route for that auth, so this does not look like the earlier API-key-vs-OAuth mismatch.

Two things stand out:

  1. Configured models (2): openai-codex/gpt-5.4, "openai-codex/gpt-5.4"

    • that second entry is suspicious, like you may have a model key saved with literal quotes in config

  2. OpenClaw uses WebSocket-first with SSE fallback for openai-codex/*, so a transport issue can show up as “it just doesn’t respond”
    Docs: https://docs.openclaw.ai/providers/openai

Can you paste these next?

openclaw --version
# 
openclaw gateway status
openclaw config get agents.defaults.models
openclaw logs --follow

Then send one failing prompt while logs --follow is running.

My current guess:

  • most likely: transport is getting stuck
  • also possible: that extra quoted model key is confusing resolution somewhere

If you open your config and see a key literally named:

"\"openai-codex/gpt-5.4\""
#

delete that one and keep only:

"openai-codex/gpt-5.4"

And for a quick test, you can temporarily force SSE for the real model key:

{
  agents: {
    defaults: {
      models: {
        "openai-codex/gpt-5.4": {
          params: { transport: "sse" }
        }
gritty junco
#

Keep this in mind, i will send all the info in the next message

20:46:05+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord channels resolved: 1479201897687814244 (guild:Bloom Media Hustlers; aliases:guild:1479201897687814244)
20:46:05+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord channel users resolved: 195569970095194113, 276783120949182475
20:46:06+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord client initialized as 1479200146406244516 (Bloom Bot); awaiting gateway readiness
20:46:06+00:00 info plugins {"subsystem":"plugins"} embedded acpx runtime backend ready
20:46:35+00:00 info plugins {"subsystem":"plugins"} active-memory: agent=bloom session=agent:bloom:discord:channel:1487411206208884806 start timeoutMs=12000 queryChars=2000
20:48:21+00:00 info typing TTL reached (2m); stopping typing indicator
20:50:59+00:00 info typing TTL reached (2m); stopping typing indicator
20:58:39+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 222ms conn=08fe1d1c…b3a5 id=e94efa55…348b

waxen swanBOT
#

Yep, that already helps.

The interesting bit there is:

  • typing TTL reached (2m); stopping typing indicator

That usually means the turn started but never produced a final reply/event in time, so this looks more like a stalled run / transport / model execution issue than Discord delivery itself.

Send the next chunk when ready, especially:

  • openclaw --version
  • openclaw gateway status
  • openclaw config get agents.defaults.models
  • the log lines right when you trigger a failing prompt

I’m pretty sure we’re close.

gritty junco
#

root@vmi3165854:~openclaw gateway statusus
openclaw config get agents.defaults.models

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm the middleware between your ambition and your attention span.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

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

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
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: running (pid 918308, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

🦞 OpenClaw 2026.4.12 (1c0672b) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

{
"openai-codex/gpt-5.4": {},
""openai-codex/gpt-5.4"": {
"params": {
"transport": "sse"
}
}
}
root@vmi3165854:~#

waxen swanBOT
#

Aha, found it.

Your gateway is healthy. The problem is this config:

{
  "openai-codex/gpt-5.4": {},
  "\"openai-codex/gpt-5.4\"": {
    "params": {
      "transport": "sse"
    }
  }
}

That second key is wrong. It literally includes quote characters in the model name, so the SSE override is not being applied to the real model.

#

So right now your real model is still:

"openai-codex/gpt-5.4": {}

which means it’s still using the default transport, auto (WebSocket first, SSE fallback).

Fix

Edit ~/.openclaw/openclaw.json so it becomes:

{
  "openai-codex/gpt-5.4": {
    "params": {
# 
      "transport": "sse"
    }
  }
}

In other words:

  • keep only openai-codex/gpt-5.4
  • delete the accidental key named \"openai-codex/gpt-5.4\"

Then restart the gateway:

openclaw gateway restart
#

Then test again.

I’m pretty confident this is the bug, because your earlier logs showed the turn hanging long enough to hit the typing TTL, and your SSE workaround was sitting on the wrong model key the whole time.

Docs: https://docs.openclaw.ai/providers/openai

If it still hangs after that, paste the next failed log snippet and I’ll keep digging.

gritty junco
#

Is there any CLI command to fix this?

waxen swanBOT
#

Yep, easiest CLI fix, based on the config you pasted, is:

openclaw config set agents.defaults.models '{"openai-codex/gpt-5.4":{"params":{"transport":"sse"}}}' --strict-json
openclaw gateway restart
openclaw config get agents.defaults.models

After that, you should see:

{
  "openai-codex/gpt-5.4": {
    "params": {
      "transport": "sse"
    }
# 
  }
}

That works because it replaces the whole broken agents.defaults.models block and removes the bad key with embedded quotes.

If you had other custom per-model settings in there, I’d do a more surgical fix instead, but from what you pasted this is the cleanest one-liner.

CLI docs: https://docs.openclaw.ai/cli/config

If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it 🎉

gritty junco
#

🦞 OpenClaw 2026.4.12 (1c0672b) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

{
"openai-codex/gpt-5.4": {
"params": {
"transport": "sse"
}
}
}
root@vmi3165854:~#

waxen swanBOT
#

Nice, that part is fixed now. 🎉

Your model config looks correct now:

{
  "openai-codex/gpt-5.4": {
    "params": {
      "transport": "sse"
    }
  }
}

If you haven’t restarted yet, do:

# 
openclaw gateway restart

Then test GPT 5.4 again.

If it works now, that bad quoted model key was the whole issue.
If it still hangs, paste the next openclaw logs --follow snippet from one failed prompt and I’ll keep digging.

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

gritty junco
#

21:06:53+00:00 error (node:919346) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
21:07:27+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord channels resolved: 1479201897687814244 (guild:Bloom Media Hustlers; aliases:guild:1479201897687814244)
21:07:27+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord channel users resolved: 195569970095194113, 276783120949182475
21:07:27+00:00 info plugins {"subsystem":"plugins"} embedded acpx runtime backend ready
21:07:30+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} logged in to discord as 1479200146406244516 (Bloom Bot)
21:08:09+00:00 info plugins {"subsystem":"plugins"} active-memory: agent=bloom session=agent:bloom:discord:channel:1487411206208884806 start timeoutMs=12000 queryChars=2098

The agent still doesnt respond

waxen swanBOT
#

Yep, this new log is actually super telling.

The punycode warning is noise. The important part is that the last thing before the stall is:

active-memory: ... start ...

Active Memory is a blocking pre-reply sub-agent, so if it gets stuck, the main agent never answers. Docs: https://docs.openclaw.ai/concepts/active-memory

Fastest CLI test

Temporarily disable Active Memory, restart, then retry:

openclaw config set plugins.entries.active-memory.config.enabled false --strict-json
# 
openclaw gateway restart

Then test GPT 5.4 again.

If you want chat commands instead

You can also do:

/active-memory off --global

If disabling it fixes the issue

Then the problem is in the Active Memory / memory-search path, not Discord and not GPT 5.4 itself.

Next thing I’d want is:

# 
openclaw memory status --deep
openclaw config get plugins.entries.active-memory

I’m pretty confident this is the next right move, because your log shows the run reaching Active Memory and then never getting past it.

gritty junco
#

Memory Search (bloom)
Provider: none (requested: auto)
Model: none
Sources: memory
Indexed: 15/24 files · 60 chunks
Dirty: yes
Store: ~/.openclaw/memory/bloom.sqlite
Workspace: /Users/prodbybloom/.openclaw/workspace
Dreaming: 0 3 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: unavailable
Embeddings error: No API key found for provider "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.4 (OAuth) or set OPENAI_API_KEY to use openai/gpt-5.4.

No API key found for provider "google". Auth store: /root/.openclaw/agents/bloom/agent/auth-profiles.json (agentDir: /root/.openclaw/agents/bloom/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.

No API key found for provider "voyage". Auth store: /root/.openclaw/agents/bloom/agent/auth-profiles.json (agentDir: /root/.openclaw/agents/bloom/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.

No API key found for provider "mistral". Auth store: /root/.openclaw/agents/bloom/agent/auth-profiles.json (agentDir: /root/.openclaw/agents/bloom/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
By source:
memory · 15/24 files · 60 chunks
Vector: unknown
FTS: ready
Embedding cache: enabled (0 entries)
Batch: disabled (failures 0/2)
Recall store: 2447 entries · 0 promoted · 2447 concept-tagged · 1200 spaced · scripts=2447 latin
Recall path: /Users/prodbybloom/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-13T17:13:31.306Z
Dreaming artifacts: diary present · 7 corpus files · ingestion state present
Dream corpus: /Users/prodbybloom/.openclaw/workspace/memory/.dreams/session-corpus

waxen swanBOT
#

Yep, this basically confirms it.

Your main reply model is fine, but Active Memory / Memory Search for agent bloom has no usable embeddings provider:

  • Provider: none (requested: auto)
  • Embeddings: unavailable
  • No API key found for provider "openai"... You are authenticated with OpenAI Codex OAuth

That last part is the key: Codex OAuth works for chat, but it does not count as an openai API key for embeddings/memory search.

So the chain is basically:

  1. message comes in
  2. Active Memory runs first, blocking the reply
  3. memory-search has no usable embeddings setup for bloom
  4. the turn stalls before the main GPT-5.4 reply
#

Best immediate fix

Keep Active Memory off for now so the bot can reply normally:

openclaw config set plugins.entries.active-memory.config.enabled false --strict-json
openclaw gateway restart

Proper long-term fix

Configure a real embeddings provider for the bloom agent:

  • OpenAI API key,
  • Google API key,
  • Voyage,
  • Mistral,
  • or another embeddings-capable provider,

and/or pin agents.defaults.memorySearch.provider so it doesn’t try auto.

gritty junco
#

He responded after that CLI, so the Active Memory was the cause

waxen swanBOT
#

Nice, glad we caught it. 🎉

Yep, then the root cause was Active Memory blocking the turn, not GPT-5.4 itself.

So your thread ended up having two separate issues:

  1. the broken quoted model key, which stopped your SSE override from applying
  2. Active Memory / memory-search stalling before the main reply because bloom had no usable embeddings provider configured

I’d leave Active Memory off for now until you wire a proper embeddings provider for that agent.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person 🙏

If you want, I can also help you do the clean follow-up so Active Memory works again without breaking replies.

gritty junco
#

So for the Active Memory i need another model? Or API ?

waxen swanBOT
#

API/provider, not necessarily another chat model.

Your main reply model can stay openai-codex/gpt-5.4.

What Active Memory needs is a working memory-search / embeddings provider for the bloom agent. And Codex OAuth is not enough for that.

So the answer is basically:

  • No, you do not need a different main chat model
  • Yes, you usually need a separate API-backed provider for memory search

Good options:

  • OpenAI API key for embeddings
  • Google/Gemini API key
  • Voyage
  • Mistral
#

If you want the most reliable setup, I’d pin a memorySearch provider explicitly instead of leaving it on auto.

Example direction from the docs:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "gemini"
      }
    }
  }
}

or use OpenAI with a real OPENAI_API_KEY.

#

Important bit: the auth has to exist for the bloom agent, not just somewhere else. Your error showed it was checking:

/root/.openclaw/agents/bloom/agent/auth-profiles.json

Docs:

My recommendation:

  1. keep Active Memory off for now
  2. add a real embeddings-capable API provider for bloom
  3. pin agents.defaults.memorySearch.provider
  4. turn Active Memory back on

If you want, I can help you choose the cheapest/easiest provider for this next.

gritty junco
#

That is gonna consume tokens pay-as-you-go?

waxen swanBOT
#

Yep, if you use a cloud embeddings provider, that part is pay-as-you-go.

A few important nuances:

  • Codex OAuth covers your chat model route, not memory embeddings
  • Active Memory usually makes smaller memory-search / embedding calls than a full chat turn, but it’s still billed if it uses a cloud API
  • so yes, with OpenAI API / Gemini / Voyage / Mistral etc, expect usage-based cost

Your options are basically:

  1. Keep Active Memory off

    • no extra memory cost
    • simplest

  2. Use a cloud embeddings provider

    • yes, billed usage
    • easiest reliable setup