Agent can't respond to messages | Friends of the Crustacean 🦞🤝 | Page 1

lyric epoch Apr 21, 2026, 7:21 PM

#

I've set up Openclaw for the first time. I'm using Windows and I've got the program installed, the gateway is up, I can access the control UI and I've paired a DIscord bot that is connected to Openclaw and the messages do show up in the Control UI. But whether I send a message from the control UI or from Discord DM's, there is no AI response. I'm using a free gemma model from Openrouter (I've tried the Openrouter API on another project and it does work but no requests from Openclaw are getting through to my Openrouter account). Anyways, the agent takes my prompts and just processes for a while and then times out. Any help?

limpid hedgeBOT Apr 21, 2026, 7:21 PM

#

junior pollenBOT Apr 21, 2026, 7:21 PM

#

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

limpid hedgeBOT Apr 21, 2026, 7:21 PM

#

wooden ravenBOT Apr 21, 2026, 7:23 PM

#

Since the messages reach Control UI, Discord pairing is probably fine. This looks like the model/auth side.

Can you paste these, in order:

openclaw --version
openclaw status
openclaw models status --probe
openclaw doctor

Then send one test prompt and grab the fresh error from:

openclaw logs --follow

#

The two most likely causes are:

The gateway service cannot see your OpenRouter key. On Windows, background services often do not inherit shell env vars. Put
OPENROUTER_API_KEY=sk-or-... in %USERPROFILE%\.openclaw\.env, restart the gateway, then re-run openclaw models status --probe. If you see Missing auth, or Shell env: off while using the service, that is the first thing to fix.
That free Gemma route is timing out on OpenClaw’s full agent/tool prompt. If auth looks good, temporarily test a known-good hosted model. If that works, your setup is fine and the specific free model is the problem.

Docs:
https://docs.openclaw.ai/help/faq#the-gateway-is-up-but-replies-never-arrive-what-should-i-check
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/providers/openrouter
https://docs.openclaw.ai/help/environment
https://docs.openclaw.ai/platforms/windows

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

lyric epoch Apr 22, 2026, 12:49 AM

#

The output is very long-- anything specific I should include (can't paste the whole thing)

wooden ravenBOT Apr 22, 2026, 12:49 AM

#

Yep, just the important bits 👍

Please paste only these parts:

Exact version
```
openclaw --version
```
From openclaw status
- the top summary
- any WARN, ERROR, or Missing auth lines
From openclaw models status --probe
- the resolved primary model
- the OpenRouter auth section
- any probe result for that model

#

any Missing auth, unusableProfiles, timeout, or cooldown lines

From openclaw doctor
- only the warnings/errors, not the whole output
From openclaw logs --follow
- send one tiny test message like hi
- then paste about 30 to 50 lines around the failure/timeout
- especially lines mentioning:
  openrouter, auth, provider, model, timeout, error, failed

Also, please redact any API keys/tokens before posting.

If you want, even this is enough to start:

openclaw --version
the OpenRouter part of openclaw models status --probe

#

the timeout/error lines from logs

That should narrow it down a lot.

lyric epoch Apr 22, 2026, 12:57 AM

#

OpenClaw 2026.4.15 (041266a)
Secret diagnostics:

status: failed to resolve channels.discord.token locally (Environment variable "DISCORD_BOT_TOKEN" is missing or empty.).
status: channels.discord.token is unavailable in this command path; continuing with degraded read-only config.
status: gateway secrets.resolve unavailable (gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\my_user.openclaw\openclaw.json
Bind: loopback); attempted local command-secret resolution.

Sessions │ 2 active · default google/gemma-4-31b-it:free (200k ctx) · ~. │
│ │ openclaw\agents\main\sessions\sessions.json

Security audit
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - openrouter/google/gemma-4-31b-it:free (31B) @ agents.defaults.model.primary (unsafe; sandbox=off; web=[web_fetch]) - o…
CRITICAL Discord security warning
Discord guilds: groupPolicy="open" with no guild/channel allowlist; any channel can trigger (mention-gated). Set channels.discord.groupPolicy="allowlist" and c…
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
WARN Control UI insecure auth toggle enabled
gateway.controlUi.allowInsecureAuth=true does not bypass secure context or device identity checks; only dangerouslyDisableDeviceAuth disables Control UI device…
WARN Insecure or dangerous config flags enabled
Detected 1 enabled flag(s): gateway.controlUi.allowInsecureAuth=true.

This is most of the summary

wooden ravenBOT Apr 22, 2026, 12:58 AM

#

That helps a lot.

A few quick reads on that output:

The Discord token warning is probably not the root cause. Since messages already show up in Control UI, Discord ingress is working.
The biggest red flag is the model. OpenClaw is explicitly warning about openrouter/google/gemma-4-31b-it:free (31B). Those smaller free routes often choke on the full agent prompt/tool schema and just hang or timeout.
gateway closed (1006 abnormal closure) is also suspicious. That suggests the CLI had a flaky connection to the gateway while resolving secrets.

So, next please paste just these 2 things:

From:
```
openclaw models status --probe
```
I want:
- the resolved primary model
- the OpenRouter auth section

#

the probe result for that model
- any Missing auth, timeout, or cooldown lines

From:
```
openclaw logs --follow
```
send one tiny prompt like hi, then paste 30 to 50 lines around the timeout/error

Also, as a fast sanity check, temporarily switch off that free Gemma route and try one stronger hosted model, or openrouter/auto. If replies start immediately, then your setup is mostly fine and the model choice was the blocker.

lyric epoch Apr 22, 2026, 1:40 AM

#

Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : openrouter/google/gemma-4-31b-it:free
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : OpenRouter -> openrouter/auto
Configured models (2): openrouter/auto, openrouter/google/gemma-4-31b-it:free

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

openrouter effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...816d10dc

OAuth/token status

none

Auth probes
┌───────────────────────────────────────┬──────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├───────────────────────────────────────┼──────────────────────────────┼────────────┤
│ openrouter/google/gemma-4-31b-it:free │ openrouter:default (api_key) │ ok · 62.1s │
└───────────────────────────────────────┴──────────────────────────────┴────────────┘
Probed 1 target in 143.9s

This is the probe.
I will upload the follow logs shortly>

wooden ravenBOT Apr 22, 2026, 1:40 AM

#

Perfect, that probe is the smoking gun.

It tells us:

Auth is fine. OpenRouter is loaded correctly.
The model itself is the problem. ok · 62.1s for a probe is very slow. Once OpenClaw adds the full agent prompt, tools, and session context, that free Gemma route is very likely timing out.
That also matches the earlier warning: “Small models require sandboxing and web tools disabled.”

So the next step is a quick sanity test:

openclaw models set openrouter/auto

Then send a tiny hi again.

If that works, then your setup is basically fine, and openrouter/google/gemma-4-31b-it:free is just too weak/slow as the primary agent model.

#

You can still send the logs when ready, but at this point I’d bet pretty hard the timeout is model-related, not Discord-related and not missing auth.

If you want to stay on free OpenRouter routes after this, we can figure out a better candidate or fallback setup.

lyric epoch Apr 22, 2026, 1:48 AM

#

I can't get the logs follow to work, but when I sent "hi" this error popped up
[agent/embedded] incomplete turn detected: runId=078c4f8d-b2f1-4e11-a849-4310bce002a0 sessionId=fb9937d9-f0c8-45f1-b3fe-a575f0a4f506 stopReason=stop payloads=0 — surfacing error to user

wooden ravenBOT Apr 22, 2026, 1:49 AM

#

Yep, that line is really useful.

It means:

the model run ended normally (stopReason=stop)
but it produced no actual answer at all (payloads=0)

So this is basically an empty model response, not a Discord delivery problem.

Given the earlier probe was auth OK but very slow, this fits the same story:
that free Gemma route is accepting requests, then failing to produce a usable reply for a real agent turn.

I’d do this next:

openclaw models set openrouter/auto

#

Then start a fresh chat/session with:

/new

and try hi again.

If that works, you’ve confirmed the root cause:
openrouter/google/gemma-4-31b-it:free is not a good primary agent model here.

If you want to stay on free OpenRouter models after that, we can look for a better route, but I would not keep this Gemma one as the default.

lyric epoch Apr 22, 2026, 2:02 AM

#

I tried several other models including gpt-oss, qwen 3 coder, nemotron 3 and the openrouter default option and all did the same timeout with the incomplete turn error. Am I missing a step here? I do want to stick with free models, preferably on Openrouter. Any suggestions?

wooden ravenBOT Apr 22, 2026, 2:04 AM

#

I don’t think you’re missing a setup step.

At this point you’ve already proved:

Discord ingress works
OpenRouter auth works
multiple free models are returning empty turns under the full agent runtime

So this looks much more like a free-model compatibility / tool-surface problem than a setup mistake.

If you want to stay free, I’d try this next:

1) Make the runtime leaner

In ~\.openclaw\openclaw.json, add something like:

#

{
  agents: {
    defaults: {
      experimental: {
        localModelLean: true,
      },
    },
  },
  tools: {
    deny: ["web_fetch", "web_search", "browser"],
  },
}

Then restart the gateway, send /new, and retry.

#

2) Stop guessing free models, scan them

Run:

openclaw models scan

and pick from the top probed results, instead of manually trying random free routes.

3) Quick sanity check

If you want to isolate plain inference vs full agent runtime:

openclaw infer model run --model openrouter/google/gemma-4-31b-it:free --prompt "Reply with exactly: smoke-ok" --json

If that works but normal chat still empty-turns, it’s almost certainly the full tool/prompt surface.

#

Also, openrouter/auto is not a “best free model for OpenClaw agents” selector, so I wouldn’t rely on that alone.

Docs:
https://docs.openclaw.ai/concepts/experimental-features
https://docs.openclaw.ai/cli/models

If you want, paste your openclaw.json after the lean-mode change and I’ll sanity check it.

lyric epoch Apr 22, 2026, 2:12 AM

#

How can I test if the Openrouter auth is really working?

wooden ravenBOT Apr 22, 2026, 2:12 AM

#

Two good ways:

1) Auth-only check

You basically already ran this:

openclaw models status --probe

If you see something like:

openrouter/... | openrouter:default (api_key) | ok

that means OpenClaw resolved the key and successfully made a real request with it.

#

2) Plain inference check

This is the best “is auth + provider path actually usable?” test:

openclaw infer model run --model openrouter/google/gemma-4-31b-it:free --prompt "Reply with exactly: auth-ok" --json

If that returns auth-ok, then:

OpenRouter auth works
the provider path works
the model can answer a simple prompt

At that point, if normal chat still fails, the issue is not auth, it’s the full agent runtime / tool surface / model compatibility.

So, short version: your earlier models status --probe already strongly suggests auth is working.
infer model run is the next stronger proof.

#

Docs:
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/cli/infer
https://docs.openclaw.ai/providers/openrouter

lyric epoch Apr 22, 2026, 2:15 AM

#

The infer model run didn't work either but I did see the ok sign on the probe report. What should I do next?

wooden ravenBOT Apr 22, 2026, 2:16 AM

#

That narrows it down a lot.

If probe = ok but infer model run fails, then:

OpenRouter auth is working
but the real request shape is still breaking, usually because the model/runtime combo is too weak or too strict for OpenClaw’s normal prompt + tool surface

So the next step is not more auth debugging. It’s to shrink the runtime and retest.

Do this next

Add this to ~\.openclaw\openclaw.json:

{
  agents: {

#

    defaults: {
      experimental: {
        localModelLean: true,
      },
    },
  },
  tools: {
    deny: ["web_fetch", "web_search", "browser"],
  },
}

Then:

restart the gateway
send /new

#Agent can't respond to messages