#Discord keep return for each sent msg"404 status code (no body)"

1 messages · Page 1 of 1 (latest)

kindred flower
#

I am using alibaba coding plan
After each sent msg, the discord always first return "404 status code (no body)"
then kind of typing
then return the result

arctic dawnBOT
#

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

strong walrusBOT
#

That "404 status code (no body)" isn’t a Discord error — it’s the OpenAI SDK error string OpenClaw shows when an OpenAI-compatible model endpoint returns HTTP 404 with an empty body.

In practice it usually means your “Alibaba/Qwen coding plan” provider is being called with something it doesn’t support, e.g.:

  • Wrong baseUrl (missing /v1, wrong host, etc.)
  • Wrong API adapter (provider doesn’t support openai-responses, only openai-completions, so it 404s)
  • Wrong model id (endpoint responds 404 for unknown model)

Then OpenClaw continues and you still get an answer because it’s using a fallback model after the primary fails.

To pinpoint it, can you paste:

  1. openclaw --version
  2. In Discord: /model status output (redact keys) — this shows which provider/model it tries first, plus the provider baseUrl and api mode.

If this is Qwen/Alibaba via a custom provider, check your models.providers.<id>.api setting: most OpenAI-compatible endpoints want api: "openai-completions" (not openai-responses). Docs: https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

kindred flower
#

2026.3.1

Current: bailian/qwen3.5-plus
Default: bailian/qwen3.5-plus
Agent: config-manager
Auth file: ~/.openclaw/agents/config-manager/agent/auth-profiles.json

[bailian] endpoint: https://coding-intl.dashscope.aliyuncs.com/v1 api: openai-responses auth: sk-sp-..... (models.json: ~/.openclaw/agents/config-manager/agent/models.json)
• bailian/glm-4.7 (GLM-4.7 (Alibaba))
• bailian/glm-5 (GLM-5 (Alibaba))
• bailian/kimi-k2.5 (Kimi K2.5 (Alibaba))
• bailian/MiniMax-M2.5 (MiniMax M2.5 (Alibaba))
• bailian/qwen3-coder-next (Qwen 3 Coder Next)
• bailian/qwen3-coder-plus (Qwen 3 Coder Plus)
• bailian/qwen3-max-2026-01-23 (Qwen 3 Max)
• bailian/qwen3.5-plus (Qwen 3.5 Plus)

strong walrusBOT
#

Yep — your /model status basically confirms the root cause:

You have:

  • provider: bailian
  • baseUrl: https://coding-intl.dashscope.aliyuncs.com/v1
  • api: openai-responses

Most “OpenAI-compatible” endpoints (including DashScope-style ones) support Chat Completions (POST /v1/chat/completions), but do not support the OpenAI Responses API (POST /v1/responses). When OpenClaw tries /v1/responses, the upstream returns 404 with an empty body, and the OpenAI SDK formats that as:

404 status code (no body)

Then OpenClaw continues (fallback/retry path), so you still get an answer — but you see that annoying error first.

Fix

Change the provider adapter to chat-completions:

#
  • set models.providers.bailian.api to "openai-completions"
  • restart the gateway

Because your status output says it’s coming from models.json at:
~/.openclaw/agents/config-manager/agent/models.json

…update it there (or in your main config, but note models.json can “win” for that provider), then:

openclaw gateway restart

After restart, run /model status again and confirm it shows:

api: openai-completions

If it still shows openai-responses, paste the bailian block from that models.json (redact the key) and I’ll tell you exactly what to change.

kindred flower
#

it is weird that all setup are in openai-completions
coud not find any config that contain openai-responses

strong walrusBOT
#

That can happen, and it’s actually a clue:

/model status is showing the resolved runtime provider config, not “what you remember setting”. If it says:

[bailian] endpoint: ... api: openai-responses (models.json: .../models.json)

then OpenClaw is getting openai-responses from that models.json entry — either because:

  1. the bailian provider block in ~/.openclaw/agents/config-manager/agent/models.json has api: "openai-responses", or
  2. there is no api field at all for that provider, and OpenClaw is defaulting it to openai-responses for this endpoint/model catalog.

So it’s normal that you “can’t find openai-responses” in other config files.

What I need from you

Please paste just the bailian provider block from:

~/.openclaw/agents/config-manager/agent/models.json

#

(redact the apiKey / token). Then I can tell you the exact line to change.

What you’re aiming for

Make sure that provider block explicitly contains:

api: "openai-completions"

Then restart the gateway and re-check /model status to confirm it no longer says openai-responses.

(If you paste the block, I’ll point out exactly where to add it — the file structure varies a bit.)

kindred flower
#

"bailian": {
"baseUrl": "https://coding-intl.dashscope.aliyuncs.com/v1",
"apiKey": "sk-sp-.......",
"api": "openai-completions",
"models": [
{
"id": "qwen3.5-plus",
"name": "qwen3.5-plus",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 1000000,
"maxTokens": 65536,
"api": "openai-completions"
},
{
"id": "qwen3-max-2026-01-23",
"name": "qwen3-max-2026-01-23",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 65536,
"api": "openai-completions"
},
{
"id": "qwen3-coder-next",
"name": "qwen3-coder-next",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,

strong walrusBOT
#

Nice — that bailian block looks correct (it really is openai-completions at both provider + model level).

So if you’re still seeing:

  • /model status reporting api: openai-responses, or
  • the bot still posting 404 status code (no body) before every real answer

…then we’re no longer in “wrong config value” territory. It’s usually one of these:

1) Gateway hasn’t reloaded the file (stale in-memory config)

Restart the gateway, then re-check:

openclaw gateway restart

Then in Discord run /model status again and confirm what it shows for [bailian] ... api:.

#

2) The 404 is coming from some other request (not the main chat completion)

This is super common (memory/embeddings, tool preflight, etc.): one step fails with 404, but the main model call succeeds so you still get a normal answer.

To see exactly what is 404’ing, run:

openclaw logs --follow

Then send one Discord message and copy/paste the log lines around the 404 (they should include the URL/path being called, like /responses, /chat/completions, /embeddings, etc.).

Quick question

After you restart, does /model status still show openai-responses for bailian? If yes, paste that new /model status output + the 404 log snippet from openclaw logs --follow and we can pinpoint the exact component that’s failing.

kindred flower
#

^[[O14:55:01 warn discord/monitor {"subsystem":"discord/monitor"} {"listener":"DiscordMessageListener","event":"MESSAGE_CREATE","durationMs":138426,"duration":"138.4 seconds"} Slow listener detected
14:55:27 info exec {"subsystem":"exec"} elevated command cd /root/wealth-automation-stack && docker compose build finance-app 2>&1 | tail -20
^[[I

strong walrusBOT
#

Got it — your models.json snippet is clean: bailian is explicitly openai-completions, and the per-model entries also say openai-completions.

So if you’re still seeing a 404 status code (no body) message in Discord, it means the 404 is coming from some other HTTP call, or the gateway is still running with stale/cached config.

1) First sanity check: restart + re-check /model status

Please do:

openclaw gateway restart

Then run /model status again and paste the bailian section.
(We need to confirm the running gateway now reports api: openai-completions.)

2) Your log snippet doesn’t include the 404 yet

The lines you pasted are only:

#
  • Slow listener detected
  • an exec command

Can you grab the 404 by searching recent logs for it?

openclaw logs --limit 500 --plain --no-color | rg -n "404 status code|no body|dashscope|bailian|responses|realtime|embeddings"

Paste whatever that prints.

3) Also: is the “404 status code (no body)” a separate bot message in Discord?

If yes, copy/paste that exact Discord message text (or screenshot). That will tell us whether it’s:

  • a model call failover message, or
  • some auxiliary feature failing (common: embeddings/memory, probes, etc.) while the main reply still succeeds.

Once you paste the /model status (post-restart) + the rg log hit, we’ll know exactly which endpoint/path is returning 404.

kindred flower
#

root@kunbot-vps:~# openclaw logs --limit 500 --plain --no-color | rg -n "404 status code|no body|dashscope|bailian|responses|realtime|embeddings"
195: "providerOverride": "bailian",
213: "modelProvider": "bailian",
214: "providerOverride": "bailian",
232: "modelProvider": "bailian",
259: "providerOverride": "bailian",
277: "modelProvider": "bailian",
278: "providerOverride": "bailian",
296: "modelProvider": "bailian",

strong walrusBOT
#

Those rg hits are only showing that bailian is being used — but you’re not actually seeing the 404 string in the rendered (--plain) log output.

A common gotcha: openclaw logs --plain pretty-prints only a subset of fields, so the real error text can be present in the JSON but not included in the plain rendering.

Can you rerun the same search using JSON logs instead?

openclaw logs --limit 2000 --json | rg -n "404|no body|dashscope|bailian|responses|realtime|embeddings"

Even better (to catch it live):

openclaw logs --follow --json | rg -n "404|no body|responses|realtime|embeddings|dashscope"

Then send one Discord message and paste the first matching block.

#

Also quick clarification: do you see 404 status code (no body) as an actual message posted in Discord by the bot, or only in your gateway terminal output? That changes where we should look (Discord API vs model HTTP vs some tool like embeddings).

kindred flower
#

actual message posted in Discord by the bot

strong walrusBOT
#

If it’s an actual Discord message posted by the bot, and you can’t find any 404 in the gateway logs, the most common explanation is:

You have two OpenClaw instances connected to Discord with the same bot token

Both receive every Discord message:

  • Instance A (misconfigured / wrong model endpoint) replies with: 404 status code (no body)
  • Instance B replies normally a moment later (so it looks like “404 … typing … then answer”)

This also matches what you pasted earlier: your VPS logs show normal processing (slow listener, exec), but no 404.

Quick way to confirm (no config changes)

  1. On the VPS, run:
openclaw gateway status
openclaw channels status --probe
#
  1. Temporarily stop the VPS gateway (only for a quick test), then send a Discord message:
  • If the bot still replies while the VPS gateway is stopped → there is definitely another OpenClaw instance running somewhere else.

Command to stop (only if you’re OK interrupting it briefly):

openclaw gateway stop

If you confirm there are two instances, the fix is simply: stop/remove Discord config from the “bad” instance (or rotate the bot token and only configure it on one gateway).

If you want, paste the output of openclaw channels status --probe from the VPS, and tell me whether you’re also running OpenClaw on another machine (local laptop/another VPS).

kindred flower
#

no, only this vps

strong walrusBOT
#

Even if you only intended to run it on this VPS, the “404 message + then a normal answer” pattern still most often comes from two gateway processes receiving the same Discord events (one errors, the other succeeds) — and that can happen on the same VPS if you have (for example) a system service and a manual gateway run / Docker container.

Step 1: check for “extra” gateway services on the VPS

Run this and paste the output:

openclaw gateway status --deep

That command is specifically designed to surface “extra/legacy” gateway services if they exist.

If it reports more than one service/process, stop/uninstall the extra one(s) and the duplicate/error message should disappear.

Step 2 (if there’s only one): we need to see what call is producing the 404

Since it’s being posted as a bot message, something is throwing an exception and OpenClaw is surfacing error.message.

To capture it in logs, temporarily raise log level and reproduce once:

#
  • Set OPENCLAW_LOG_LEVEL=debug for the gateway service (or set logging.level: "debug" in ~/.openclaw/openclaw.json)
  • Restart gateway
  • Then:
openclaw logs --follow --json | rg -n "404|no body"

If you paste the first matching JSON log event, it’ll tell us whether the 404 is coming from:

  • a model HTTP request (and which path, like /responses vs /chat/completions), or
  • a Discord API call, etc.

Start with gateway status --deep though — it’s the fastest way to confirm/deny the duplicate-process theory.

kindred flower
#

🦞 OpenClaw 2026.3.1 (2a8ac97) — End-to-end encrypted, drama-to-drama excluded.

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-05.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/entry.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 1056767, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):

  • openclaw-guardian.service (system, unit: /etc/systemd/system/openclaw-guardian.service)
  • openclaw-unified.service (system, unit: /etc/systemd/system/openclaw-unified.service)
    Cleanup hint: systemctl --user disable --now openclaw-gateway.service
    Cleanup hint: rm ~/.config/systemd/user/openclaw-gateway.service

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).

strong walrusBOT
#

That output basically nails it.

You do have more than one OpenClaw “gateway-like” service on the VPS:

  • openclaw-gateway.service (user)
  • openclaw-guardian.service (system)
  • openclaw-unified.service (system)

If more than one of those is running and connected to Discord, you’ll get exactly what you described: two replies per message (one instance errors with 404 status code (no body), the other answers normally).

What to do next

  1. Check which of the extra services are actually running:
systemctl status openclaw-unified.service openclaw-guardian.service
systemctl --user status openclaw-gateway.service
#
  1. Stop the extra one(s) (do this one at a time, then test in Discord):
sudo systemctl stop openclaw-unified.service
sudo systemctl stop openclaw-guardian.service

Send a Discord message after each stop — as soon as the 404 status code (no body) “first reply” disappears, you found the culprit.

  1. Once confirmed, disable it so it won’t come back on reboot:
sudo systemctl disable --now openclaw-unified.service
sudo systemctl disable --now openclaw-guardian.service

(Only disable the one(s) you confirmed were running and causing the duplicate reply.)

#

If you paste the systemctl status outputs, I can tell you which service is actually doing the Discord connection and which one you should keep.

kindred flower
#

Note: The memory-core plugin warning (memory slot plugin not found) is also showing in logs — if agents are losing memory/context, that could be a separate issue worth investigating.

strong walrusBOT
#

Yep — that “memory slot plugin not found” warning is a separate thing, but there’s a good chance it’s related to the multiple services you have on the VPS.

If openclaw-unified / openclaw-guardian are also running, one of those could be starting with a different plugin allowlist/slots config and emitting the warning (and/or doing weird reply behavior).

Do this in order

  1. First clean up to a single running gateway (the extra services you saw in gateway status --deep).
    After you stop/disable the extras, re-check if:
  • the Discord “404 … then answer” behavior is gone
  • the memory warning is still there
  1. If the memory warning is still in the remaining gateway’s logs, paste:
openclaw config get plugins
openclaw plugins list
#

What I’ll be looking for:

  • plugins.enabled should be true
  • plugins.slots.memory should be "memory-core" (or omitted)
  • if you set plugins.allow, it must include "memory-core" (otherwise the memory slot can’t load and you’ll get that warning)

Optional quick health check:

openclaw memory status --deep

If you paste those outputs, we can fix the memory warning cleanly—but I’d strongly recommend getting down to one gateway service first.

kindred flower
#

root@kunbot-vps:~# openclaw memory status --deep
^[[O
🦞 OpenClaw 2026.3.1 (2a8ac97)
iMessage green bubble energy, but for everyone.

Memory search disabled.
Memory search disabled.
Memory search disabled.
Memory search disabled.
Memory search disabled.