OpenClaw just answering with: ⚠️ Agent couldn't generate a response. Please try again. | Friends of the Crustacean 🦞🤝 | Page 1

cursive notch Apr 21, 2026, 3:39 PM

#

I am writing to report a recurring issue with OpenClaw. Regardless of the input or context provided, the system consistently returns the following error message:

"Agent couldn't generate a response. Please try again."

I want to clarify that I have already exhausted all standard troubleshooting methods, including:

Refreshing the session and restarting the application.

Clearing cache and cookies to ensure a clean state.

Varying the prompts (from simple queries to complex tasks) to see if it was a specific trigger.

Checking network stability and trying different browsers/devices.

Despite these efforts, the "Agent couldn't generate a response" error persists every single time. It appears the system is unable to process or output any data at this moment.

white vectorBOT Apr 21, 2026, 3:39 PM

#

jaunty swallowBOT Apr 21, 2026, 3:39 PM

#

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

white vectorBOT Apr 21, 2026, 3:39 PM

#

cursive notch Apr 21, 2026, 3:41 PM

#

I am using OpenClaw on a LXC on Proxmox! Here are the Logs: 14:11:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:12:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:13:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)

royal thicketBOT Apr 21, 2026, 3:41 PM

#

That banner is the generic fallback, not the root cause. It usually means the agent run ended with no usable final reply because of a provider error, auth/quota issue, gateway problem, or a local model/backend incompatibility.

Since it happens across browsers/devices, I’d treat this as backend-side, not cache/cookies.

Please paste these outputs, in this order:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
openclaw doctor

Then reproduce it once and capture the log around that failed turn:

#

openclaw logs --follow

A few important notes:

Paste text, not screenshots, if possible.
If you use Ollama, LM Studio, llama.cpp, vLLM, or another OpenAI-compatible local backend, say which one. That changes the likely fix quite a bit.
If this is happening in every session, mention whether it also fails on a brand new chat.

Docs for the exact triage flow:

If you share those outputs, I can help narrow it down fast.

cursive notch Apr 21, 2026, 3:41 PM

#

4:14:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:15:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:16:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:17:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:18:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:19:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:20:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)
14:21:01+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=unannounced)

#

14:26:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:27:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:28:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:29:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:30:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(4

#

14:23:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:24:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)
14:25:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)

#

14:22:21+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=openclaw (45)._openclaw-gw._tcp.local. host=openclaw-(45).local. port=18789 state=probing)

royal thicketBOT Apr 21, 2026, 3:42 PM

#

Yep, those bonjour lines are probably a red herring.

They mean mDNS/Bonjour discovery is failing to advertise inside the LXC, which is pretty common in containers/Proxmox because multicast is flaky there. That affects discovery, not the agent’s ability to generate a reply.

So the important part is: those are not the logs we need for this failure.

Please grab these instead:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
openclaw doctor

Then do this:

#

Run:
```
openclaw logs --follow
```
Send a simple prompt like hi
Paste the log lines from that exact moment

What I’m looking for is anything mentioning:

401, 403, 429
rate limit
auth
model
provider
timeout
tool
stopReason: error

#

If you want, you can also ignore or disable Bonjour later in the container with:

{
  discovery: {
    mdns: { mode: "off" }
  }
}

Docs:

So, short version: the bonjour warning is not the root cause. I need the model/gateway error around a failed prompt plus the version/status output.

#

These are still just the once-per-minute Bonjour watchdog warnings. They’re noisy, but they are not the agent failure.

The line we care about should show up immediately after you send a prompt, not every 60 seconds.

So let’s narrow it down with the minimum useful output:

openclaw --version
openclaw status --all
openclaw models status

Then, to avoid the Bonjour spam, run:

openclaw logs --follow | grep -vi bonjour

#

Now send a simple prompt like hi, and paste the new log lines that appear right after that.

That should show the real cause, usually one of:

provider auth failure
quota / 429
bad model config
local backend incompatibility
timeout / upstream error

If you want, just start with openclaw status --all first. That alone often exposes the problem.

#

We’re still looking at the same unrelated Bonjour warning.

That warning is about service discovery in the container, not why replies fail. We can’t diagnose the agent error from it.

So let’s stop chasing that line. Please run this one command only and paste the full output:

openclaw status --all

If you want a second one after that, do:

openclaw models status

That’s the useful data here. Not the repeating warn bonjour lines.

#

Also, because you’re on LXC/Proxmox, Bonjour/mDNS failing is pretty normal, so don’t treat that as the root cause. If you don’t need discovery, you can disable it later with:

{
  discovery: {
    mdns: { mode: "off" }
  }
}

But first, please paste openclaw status --all. That’s the fastest way forward.

#

I think we’re talking past each other a bit 😅

Please stop pasting the dashboard log panel. Those Bonjour lines are not the failure.

Instead, go into the LXC shell/terminal and copy-paste this exact command:

openclaw --version && openclaw status --all && openclaw models status

Then paste that terminal output here.

Important:

run it inside the LXC
paste the command output, even if it shows errors
if it says openclaw: command not found, paste that too

#

Right now we still have no agent/model error, only mDNS discovery noise. Once you paste the command output, we can actually diagnose it.

#

That is still the same unrelated Bonjour line.

I can’t diagnose the reply failure from that log entry. I’d just be guessing.

Please paste terminal output from inside the LXC for this exact command:

openclaw --version && openclaw status --all && openclaw models status

If that’s hard to paste into Discord, attach it as a .txt file instead.

Without that output, we’re stuck on mDNS noise and not the actual agent/model error. Once you share it, I can help with the next step.

cursive notch Apr 21, 2026, 3:46 PM

#

🦞 OpenClaw 2026.4.15 (041266a) — The only crab in your contacts you actually want to hear from. 🦞

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : google/gemini-2.5-flash
Fallbacks (5) : openrouter/openrouter/elephant-alpha, groq/llama-3.3-70b-versatile, openrouter/google/gemma-4-31b-it:free, openrouter/google/gemma-4-26b-a4b-it:free, openrouter/nvidia/nemotron-3-super-120b-a12b:free
Image model : -
Image fallbacks (0): -
Aliases (5) : Auto (Free Router) -> openrouter/openrouter/free, gemini -> google/gemini-3.1-pro-preview, Llama 3.3 70B (Groq) -> groq/llama-3.3-70b-versatile, Llama 3.1 8B Instant (Groq) -> groq/llama-3.1-8b-instant, Llama 4 Scout 17B (Groq) -> groq/meta-llama/llama-4-scout-17b-16e-instruct
Configured models (10): openrouter/openrouter/free, openrouter/openrouter/elephant-alpha, openrouter/google/gemma-4-31b-it:free, openrouter/google/gemma-4-26b-a4b-it:free, openrouter/nvidia/nemotron-3-super-120b-a12b:free, google/gemini-3.1-pro-preview, google/gemini-2.5-flash, groq/llama-3.3-70b-versatile, groq/llama-3.1-8b-instant, groq/meta-llama/llama-4-scout-17b-16e-instruct

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

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAi...5EZHYBAg
groq effective=env:gsk_nyN2...mXzpd207 | env=gsk_nyN2...mXzpd207 | source=env: GROQ_API_KEY
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | openrouter:default=sk-or-v1...c146ec50, openrouter:manual=token:sk-or-v1...414bac6d

OAuth/token status

openrouter
- openrouter:manual static

#

🦞 OpenClaw 2026.4.15 (041266a) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

|
OpenClaw status --all

Overview
┌─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │

│ Version │ 2026.4.15 │
│ OS │ linux 6.8.12-20-pve (x64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://192.168.178.198:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 41ms · auth token · openclaw (192.168.178.198) app 2026.4.15 linux 6.8.12-20-pve │

#

│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 53224, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 1 bootstrapping · 1 active · 3 sessions │
│ Secrets │ none │
└─────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼─────────────────────────────────────────────────────────────────────────────────────────
o

#

───────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (sha256:90fd11d9 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config │
└──────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Agents
┌────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ PRESENT │ 3 │ 3m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: lan

✓ Config: /root/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 53224 root: openclaw-gateway (*:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 9 eligible · 0 missing · /root/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

royal thicketBOT Apr 21, 2026, 3:47 PM

#

Perfect, that’s finally the useful part.

A few takeaways:

2026.4.15 is recent enough, so this probably isn’t just “ancient version” pain.
Your config/auth exists, so this is no longer looking like a missing-model setup issue.
The Bonjour warning is unrelated.

What we still don’t know is whether those providers actually work from the running gateway host. models status without --probe only shows configured auth sources, not whether requests succeed.

Please run this next:

openclaw models status --probe

and paste the output.

#

One important clue from your output:

Shell env : off

That is not automatically bad, but it matters if the gateway runs as a service and some keys only exist in your shell. In your case, Groq is env-based, so if the daemon does not inherit that env, the running gateway may not actually have the key even though your terminal does.

If you started OpenClaw as a service, the safe fixes are:

put env keys in ~/.openclaw/.env, or
enable shell import:

{
  env: {
    shellEnv: {
      enabled: true
    }

#

}
}

then restart the gateway.

Docs:

So, next best step is openclaw models status --probe. That should tell us whether this is a real provider/auth failure versus something higher up in the agent runtime.

#

Nice, this is progress.

From that status overview, the gateway itself looks healthy:

correct version
reachable on loopback
auth token path is working
dashboard is up

So this is probably not an LXC/Bonjour/gateway-startup problem anymore.

The failure is now much more likely in the model/provider layer.

Please run this next and paste the full output:

#

openclaw models status --probe

That does a real probe, not just config inspection.

If that comes back clean, do this immediately after:

openclaw logs --follow | grep -vi bonjour

Then send a test prompt like hi and paste the new log lines.

So at this point we’ve basically ruled out:

gateway down
dashboard unreachable

#

basic local connectivity
the bonjour warning as root cause

Next target is provider auth / model probe / runtime error.

cursive notch Apr 21, 2026, 3:49 PM

#

🦞 OpenClaw 2026.4.15 (041266a) — Greetings, Professor Falken

|
o
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : google/gemini-2.5-flash
Fallbacks (5) : openrouter/openrouter/elephant-alpha, groq/llama-3.3-70b-versatile, openrouter/google/gemma-4-31b-it:free, openrouter/google/gemma-4-26b-a4b-it:free, openrouter/nvidia/nemotron-3-super-120b-a12b:free
Image model : -
Image fallbacks (0): -
Aliases (5) : Auto (Free Router) -> openrouter/openrouter/free, gemini -> google/gemini-3.1-pro-preview, Llama 3.3 70B (Groq) -> groq/llama-3.3-70b-versatile, Llama 3.1 8B Instant (Groq) -> groq/llama-3.1-8b-instant, Llama 4 Scout 17B (Groq) -> groq/meta-llama/llama-4-scout-17b-16e-instruct
Configured models (10): openrouter/openrouter/free, openrouter/openrouter/elephant-alpha, openrouter/google/gemma-4-31b-it:free, openrouter/google/gemma-4-26b-a4b-it:free, openrouter/nvidia/nemotron-3-super-120b-a12b:free, google/gemini-3.1-pro-preview, google/gemini-2.5-flash, groq/llama-3.3-70b-versatile, groq/llama-3.1-8b-instant, groq/meta-llama/llama-4-scout-17b-16e-instruct

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

google effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyAi...5EZHYBAg
groq effective=env:gsk_nyN2...mXzpd207 | env=gsk_nyN2...mXzpd207 | source=env: GROQ_API_KEY
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=0, token=1, api_key=1) | openrouter:default=sk-or-v1...c146ec50, openrouter:manual=token:sk-or-v1...414bac6d

#

OAuth/token status

openrouter
- openrouter:manual static

Auth probes
┌──────────────────────────────────────┬──────────────────────────────┬────────────┐
│ Model │ Profile │ Status │
├──────────────────────────────────────┼──────────────────────────────┼────────────┤
│ google/gemini-2.5-flash │ google:default (api_key) │ ok · 17.4s │
│ groq/llama-3.3-70b-versatile │ env (api_key) │ ok · 7.2s │
│ openrouter/openrouter/elephant-alpha │ openrouter:default (api_key) │ ok · 3.9s │
│ openrouter/openrouter/elephant-alpha │ openrouter:manual (token) │ ok · 1.5s │
└──────────────────────────────────────┴──────────────────────────────┴────────────┘
Probed 4 targets in 34s

royal thicketBOT Apr 21, 2026, 3:49 PM

#

Aha, this is the first real smoking gun:

Agents: 1 total · 1 bootstrapping

That means your main agent still thinks it is in first-run bootstrap mode.

Per the docs, bootstrapping should remove BOOTSTRAP.md when finished:
https://docs.openclaw.ai/start/bootstrapping

So if you already completed setup before, the likely problem is a stuck BOOTSTRAP.md in the workspace.

Please check this on the LXC host:

ls -la ~/.openclaw/workspace/BOOTSTRAP.md

#

If that file exists and you already finished onboarding/bootstrap before, I’d do this:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then start a fresh chat/session and test again.

Why I think this is it:

Bonjour is noise
gateway is up
status is healthy
but the agent is still marked bootstrapping, which is not normal after setup is done

If your workspace is not the default ~/.openclaw/workspace, use the workspace path from your config instead. If you want, paste the result of the ls command first and I’ll sanity check it before you move anything.

#

Nice, that helps too.

Your Telegram channel is healthy, so this is not a channel transport problem either.

At this point the weird thing that still stands out is only this:

1 bootstrapping

So I’d stay focused on that.

Please run this next on the LXC host:

ls -la ~/.openclaw/workspace/BOOTSTRAP.md

If you’re not using the default workspace, first check:

#

openclaw config get agents.defaults.workspace

Then look for BOOTSTRAP.md in that workspace instead.

If BOOTSTRAP.md is still there and you already finished setup before, that’s very likely the issue. In that case, move it aside and restart:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

So yeah, gateway looks fine, Telegram looks fine, Bonjour is noise. The bootstrap-pending agent is the thing I’d fix next.

#

Yep, confirmed.

This is the problem:

Agent main
Bootstrap file: PRESENT

That is not normal after setup is finished. Bootstrapping is supposed to remove BOOTSTRAP.md when it completes.

Also, the Port 18789 is already in use warning is fine here, it just means the gateway is already running.

So the next fix is:

mv /root/.openclaw/workspace/BOOTSTRAP.md /root/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

#

Then start a fresh session and test again. If you’re using Telegram, send:

/new

and then try a simple message like hi.

Docs:

https://docs.openclaw.ai/start/bootstrapping

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

cursive notch Apr 21, 2026, 3:51 PM

#

root@openclaw:~/.openclaw ls -la ~/.openclaw/workspace/BOOTSTRAP.md
-rw-r--r-- 1 root root 1471 Apr 19 15:24 /root/.openclaw/workspace/BOOTSTRAP.md

royal thicketBOT Apr 21, 2026, 3:51 PM

#

I can’t tell from this snippet whether you already did the BOOTSTRAP.md fix.

The key checkpoint is:

before: Bootstrap file = PRESENT
after fix: that should no longer be present in openclaw status --all

So please confirm one of these:

You moved BOOTSTRAP.md, restarted, and now it works
You moved it, restarted, but it still fails
You haven’t moved it yet

If you already did the move/restart and it still fails, then the next command is:

#

openclaw models status --probe

If you haven’t done the move yet, I’d still do that first, because Bootstrap file PRESENT was the clearest broken signal in everything you pasted.

#

Nice, that narrows it down a lot.

Your model auth probes are all green, so we can now rule out:

bad API keys
provider auth
fallback auth
gateway reachability
Telegram transport

At this point, the remaining broken signal is still the same one:

Bootstrap file: PRESENT

So yes, I’d treat the stuck bootstrap as the root cause unless proven otherwise.

Since your gateway config is under /root, use this exact path:

#

mv /root/.openclaw/workspace/BOOTSTRAP.md /root/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then send:

/new

and try hi.

If you already did that, rerun:

#

openclaw status --all

and check whether the agent still shows:

Bootstrap file │ PRESENT

If it still says PRESENT, then the file either wasn’t moved or the workspace path is different.

If PRESENT is gone and it still fails, then we’re down to live runtime logs, and the next step is:

openclaw logs --follow | grep -vi bonjour

#

then send a test prompt and paste the new lines.

#

Yep, that’s it.

/root/.openclaw/workspace/BOOTSTRAP.md is still there, and that matches the Bootstrap file: PRESENT status. If this is not a brand-new unfinished setup, that file is the problem.

I’d do this now:

mv /root/.openclaw/workspace/BOOTSTRAP.md /root/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then start a fresh session:

/new

#

and test with:

hi

If you want one extra sanity check after restart:

openclaw status --all

and confirm the agent no longer shows Bootstrap file │ PRESENT.

I’m pretty confident this is the fix.

cursive notch Apr 21, 2026, 3:55 PM

#

⚠️ Agent couldn't generate a response. Please try again.

royal thicketBOT Apr 21, 2026, 3:56 PM

#

If that happened after the move/restart, then we need to separate two cases:

1) Check whether bootstrap is actually cleared

Run:

ls -la /root/.openclaw/workspace/BOOTSTRAP.md
openclaw status --all

What I want to know:

does BOOTSTRAP.md still exist?
does the Agents table still say Bootstrap file │ PRESENT?

2) If bootstrap is gone but it still errors, capture the real runtime error

In one terminal:

#

openclaw logs --follow | grep -vi bonjour

Then send:

/new
hi

and paste the new log lines that appear immediately after.

So yeah, if you already moved the file and still got the generic error, we’re probably looking at a second issue, but first I need to verify whether bootstrap actually cleared.

cursive notch Apr 21, 2026, 3:56 PM

#

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (sha256:90fd11d9 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config │
└──────────┴──────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Agents
┌────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ main │ ABSENT │ 3 │ 1m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: lan

✓ Config: /root/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 194 root: openclaw-gateway (*:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 9 eligible · 0 missing · /root/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

#

penClaw status --all

Overview
┌─────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────

#

│ Version │ 2026.4.15 │
│ OS │ linux 6.8.12-20-pve (x64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://192.168.178.198:18789/ │
│ Tailscale │ off │
│

royal thicketBOT Apr 21, 2026, 3:57 PM

#

That’s the channel section again, and it doesn’t help here.

At this point I need one of these two things only:

Option A, confirm bootstrap is gone

Paste the output of:

ls -la /root/.openclaw/workspace/BOOTSTRAP.md

I expect either:

No such file or directory, which is good, or
the file is still there, which means the fix did not apply

Option B, capture the actual runtime error

cursive notch Apr 21, 2026, 3:57 PM

#

│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 51ms · auth token · openclaw (192.168.178.198) app 2026.4.15 linux 6.8.12-20-pve │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 194, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 1 active · 3 sessions │
│ Secrets │ none

royal thicketBOT Apr 21, 2026, 3:57 PM

#

Run:

openclaw logs --follow | grep -vi bonjour

Then send:

/new
hi

and paste the new log lines.

So please, no more channel/status tables for now. I need either the BOOTSTRAP.md check or the post-prompt logs.

cursive notch Apr 21, 2026, 3:57 PM

#

root@openclaw:~ ls -la /root/.openclaw/workspace/BOOTSTRAP.md
ls: cannot access '/root/.openclaw/workspace/BOOTSTRAP.md': No such file or directory

royal thicketBOT Apr 21, 2026, 3:58 PM

#

Nice, that confirms the bootstrap issue is fixed:

Bootstrap file │ ABSENT

So we cleared the first bug. Good catch.

Also, the Port 18789 is already in use line is still expected, it just means the gateway is running.

Next step

Please test in a brand-new session, not an old one:

/new
hi

If it still returns the generic error, then we finally need the real runtime error behind it:

#

openclaw logs --follow | grep -vi bonjour

Then send /new, then hi, and paste the new lines that appear right after.

So, status now looks like this:

bootstrap: fixed
gateway: healthy
channels: healthy
model probes: healthy

What’s left is a runtime/session-level error, and the live logs are the thing we need now.

#

We’re done with status --all now, it won’t tell us more.

At this point I need live logs during a failed message, nothing else.

Please do exactly this:

In the LXC terminal, run:

openclaw logs --follow | grep -vi bonjour

Leave that running.
In Telegram, send:
```
/new
```

#

then:

hi

Paste the new log lines that appear right after.

If nothing appears in the log when you send hi, say that explicitly. That’s useful too.

So, no more status tables for now, I need the post-prompt logs.

#

You’re still pasting status output, not the live logs from a failed prompt.

I can’t diagnose the remaining issue from status anymore. We already used status to rule out:

gateway down
channel down
model auth broken
stuck bootstrap

What’s left requires the actual runtime error.

So I need exactly this, or I’m just guessing:

openclaw logs --follow | grep -vi bonjour

#

Then send in Telegram:

/new
hi

and paste the new lines that appear.

If you don’t want to do that, the fastest alternative is to use a local coding agent on the box so it can inspect the live failure directly:
https://docs.openclaw.ai/help/faq#i-am-stuck-fastest-way-to-get-unstuck

But from here, status output is no longer useful. I need the post-prompt logs.

cursive notch Apr 21, 2026, 3:59 PM

#

2026-04-21T15:55:18.042Z info plugins {"subsystem":"plugins"} embedded acpx runtime backend ready
2026-04-21T15:55:24.968Z info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-21-greeting.md
2026-04-21T15:55:37.615Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=12528a01-01b7-4882-8861-daf97eadad60 sessionId=a3fe0a2b-a4df-4cad-9e5f-a6a02916f34e stopReason=stop payloads=0 — surfacing error to user
2026-04-21T15:55:37.750Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8736947311 message=1561

#

2026-04-21T15:55:40.424Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=8de5ae12-f46a-4c31-93f4-af750f43be8a sessionId=a3fe0a2b-a4df-4cad-9e5f-a6a02916f34e stopReason=stop payloads=0 — surfacing error to user
2026-04-21T15:55:40.586Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8736947311 message=1562
2026-04-21T15:56:21.416Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 126ms conn=0c50cfd7…19a4 id=14cf47d7…bebd
2026-04-21T15:56:22.112Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 84ms conn=7bd4ee15…62ab id=9f8f46c7…de4d
2026-04-21T15:58:42.313Z info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-21-greet-user.md
2026-04-21T15:58:47.214Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=47ca1670-bb91-436c-8869-480d629be828 sessionId=84cb9845-4fe8-4876-a728-e948f1b75db9 stopReason=stop payloads=0 — surfacing error to user
2026-04-21T15:58:47.348Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8736947311 message=1564
2026-04-21T15:58:49.766Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=1f69cddd-a19d-4139-94e5-780b6dd1e0e3 sessionId=84cb9845-4fe8-4876-a728-e948f1b75db9 stopReason=stop payloads=0 — surfacing error to user
2026-04-21T15:58:49.966Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8736947311 message=1566

royal thicketBOT Apr 21, 2026, 3:59 PM

#

Good, that confirms:

0 bootstrapping
gateway healthy
service running

So the bootstrap fix worked.

But I still cannot diagnose the remaining error from status output. The next message needs to be one of these only:

The live log lines from:

openclaw logs --follow | grep -vi bonjour

after sending:

#

   /new
   hi

Or the sentence:
```
nothing appeared in the logs
```

Please don’t paste more status --all output, we’re past that stage.

#

Perfect, that confirms the bootstrap file is really gone.

So we now know:

bootstrap issue: fixed
gateway: healthy
model auth: healthy
channel: healthy

What’s left is the actual runtime failure, and I still need the post-prompt logs to see it.

Please do this exact sequence:

openclaw logs --follow | grep -vi bonjour

#

Leave that running, then in Telegram send:

/new
hi

Then reply here with either:

the new log lines that appeared, or
nothing appeared in the logs

That’s the only missing piece now.

cursive notch Apr 21, 2026, 4:01 PM

#

SO, now it is answering but only with the google gemini provider...

royal thicketBOT Apr 21, 2026, 4:01 PM

#

Good, we finally have the real signal.

This line is the key:

incomplete turn detected ... stopReason=stop payloads=0

That means the agent run completed, but the model returned no visible reply text. So this is not auth, not Telegram, not bootstrap, and not the gateway.

Most likely, your current default model is choking on the full agent runtime prompt and ending with an empty turn.

Fastest workaround

Temporarily switch away from the current primary model to another one that already probed OK:

#

openclaw models set groq/llama-3.3-70b-versatile

Then in Telegram:

/new
hi

If that works, you’ve confirmed it’s a model/runtime compatibility issue with the previous default, not your install.

If it still fails after switching, I’d want the next failed log snippet too.

And if switching fixes it, please file a GitHub issue with this log line:
https://github.com/openclaw/openclaw/issues

#

That’s the right escalation path for this kind of bug.

#

Those logs confirm the same failure pattern across fresh runs:

incomplete turn detected ... stopReason=stop payloads=0

So the agent is running, but it’s producing zero visible output and surfacing the generic error.

Two paths from here

If you have not actually switched the default model yet, try that once:
```
openclaw models set groq/llama-3.3-70b-versatile
```
then:

#

   /new
   hi

If you already switched models and still got these logs, then I’d treat this as a real OpenClaw bug and file it here:
https://github.com/openclaw/openclaw/issues

What to include in the issue

2026.4.15 on Proxmox LXC
bootstrap was initially stuck (BOOTSTRAP.md present), then fixed
gateway/channel/model probes all healthy

repeated log line:

incomplete turn detected ... stopReason=stop payloads=0

#

At that point it’s maintainer-debug territory, not normal setup trouble anymore.

#

Nice, that’s actually a big clue.

That means your install is basically healthy now, and the remaining problem is provider-specific, not gateway/bootstrap/channel.

So the picture is:

Gemini works
some other configured providers pass auth probe
but those same providers fail on full agent turns and end in:
```
stopReason=stop payloads=0
```

That can happen because probe success only proves auth/basic inference, not that the provider/model handles the full OpenClaw agent runtime cleanly.

What I’d do

Keep Google Gemini as your temporary primary, since it works.

#

Treat the failing non-Google providers as a separate bug/compat issue.
File a GitHub issue for the providers that still fail on real agent turns:
https://github.com/openclaw/openclaw/issues

Include:

provider(s) that fail
provider that works (Gemini)

the log line:

incomplete turn detected ... stopReason=stop payloads=0

If you want, I can help you write a clean GitHub issue summary from everything we found here.

And if Gemini solves it well enough for now, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

cursive notch Apr 21, 2026, 4:04 PM

#

So, I configurated openrouter, groq and google gemini, but only google gemini is working!!

royal thicketBOT Apr 21, 2026, 4:05 PM

#

Yep, based on everything you posted, that’s the current diagnosis.

What’s happening:

Google Gemini works
Groq + OpenRouter authenticate successfully

but on real full agent turns they fall into:

incomplete turn detected ... stopReason=stop payloads=0

So they’re not failing at auth, they’re failing at the agent-runtime response stage.

Practical fix for now

Keep Gemini as your primary model, and remove the failing providers from your fallback chain for now:

keep agents.defaults.model.primary on Gemini
remove Groq/OpenRouter from agents.defaults.model.fallbacks until this is fixed

#

Docs:

For the actual bug

Please file it here:
https://github.com/openclaw/openclaw/issues

Include:

Proxmox LXC
OpenClaw 2026.4.15
Groq/OpenRouter probes ok
Gemini works

failing log:

incomplete turn detected ... stopReason=stop payloads=0

#

And if you want current community advice on which non-Gemini models are behaving best right now, ask in #models.

If this solved it enough for now, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed.

cursive notch Apr 21, 2026, 4:09 PM

#

2026-04-21T16:06:01.414Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","fallback_model"],"runId":"b8199f5e-6eeb-44d5-944f-e5802b6c254f","stage":"assistant","decision":"fallback_model","failoverReason":"rate_limit","profileFailureReason":"rate_limit","provider":"google","model":"gemini-3.1-pro-preview","sourceProvider":"google","sourceModel":"gemini-3.1-pro-preview","profileId":"sha256:a94403a4f9d0","fallbackConfigured":true,"timedOut":false,"aborted":false,"status":429,"rawErrorPreview":"{"error":{"message":"{\n \"error\": {\n \"code\": 429,\n \"message\": \"You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. \\n* Quota exceeded for metric: generativelanguage.googleapis.com/generate_conten…","rawErrorHash":"sha256:ca187f4892e0","rawErrorFingerprint":"sha256:abbd20649658","providerRuntimeFailureKind":"rate_limit","providerErrorMessagePreview":"{\n "error": {\n "code": 429,\n "message": "You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-a…"} embedded run failover decision
2026-04-21T16:06:01.415Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=15314 error="FailoverError: ⚠️ API rate limit reached. Please try again later."
2026-04-21T16:06:01.416Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:8736947311 durationMs=15315 error="FailoverError: ⚠️ API rate limit reached. Please try again later."

#

2026-04-21T16:06:01.419Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"b8199f5e-6eeb-44d5-944f-e5802b6c254f","decision":"candidate_failed","requestedProvider":"google","requestedModel":"gemini-3.1-pro-preview","candidateProvider":"google","candidateModel":"gemini-3.1-pro-preview","attempt":1,"total":7,"reason":"rate_limit","status":429,"errorPreview":"⚠️ API rate limit reached. Please try again later.","errorHash":"sha256:2a33d7700899","nextCandidateProvider":"openrouter","nextCandidateModel":"openrouter/elephant-alpha","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision
2026-04-21T16:06:07.796Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_succeeded"],"runId":"b8199f5e-6eeb-44d5-944f-e5802b6c254f","decision":"candidate_succeeded","requestedProvider":"google","requestedModel":"gemini-3.1-pro-preview","candidateProvider":"openrouter","candidateModel":"openrouter/elephant-alpha","attempt":2,"total":7,"isPrimary":false,"requestedModelMatched":false,"fallbackConfigured":true,"previousAttempts":[{"provider":"google","model":"gemini-3.1-pro-preview","reason":"rate_limit","status":429,"errorPreview":"⚠️ API rate limit reached. Please try again later.","errorHash":"sha256:2a33d7700899"}]} model fallback decision

#

2026-04-21T16:06:32.201Z warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_SOCKET)
2026-04-21T16:06:32.203Z warn [telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_SOCKET)
2026-04-21T16:06:39.196Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"b4f9cbe2-d16a-4c1a-bd18-0fa3899524a0","isError":true,"error":"⚠️ API rate limit reached. Please try again later.","failoverReason":"rate_limit","model":"gemini-3.1-pro-preview","provider":"google","rawErrorPreview":"{"error":{"message":"{\n \"error\": {\n \"code\": 429,\n \"message\": \"You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. \\n* Quota exceeded for metric: generativelanguage.googleapis.com/generate_conten…","rawErrorHash":"sha256:44cbee60107f","rawErrorFingerprint":"sha256:57bf439bd13f","providerRuntimeFailureKind":"rate_limit","providerErrorMessagePreview":"{\n "error": {\n "code": 429,\n "message": "You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-a…"} embedded run agent end

royal thicketBOT Apr 21, 2026, 4:10 PM

#

Ah, this is much clearer now. You actually have two separate problems:

Groq/OpenRouter
They authenticate, but some full agent turns end with:
```
stopReason=stop payloads=0
```
so they look like a runtime compatibility bug.
Google Gemini 3.1 Pro Preview
This one is not a mystery bug, it is a straight 429 quota/rate-limit error:
```
provider: google
model: gemini-3.1-pro-preview
status: 429
You exceeded your current quota...
```

#

Important detail

Your alias list earlier showed:

gemini -> google/gemini-3.1-pro-preview

So if you use gemini, you are hitting the rate-limited preview model, not the working 2.5-flash one.

What I’d do now

Use the working Google model explicitly:

openclaw models set google/gemini-2.5-flash

And avoid the gemini alias for now, since that points at the quota-limited preview model.

#

So the final picture is

google/gemini-2.5-flash seems usable
google/gemini-3.1-pro-preview is quota-limited
Groq/OpenRouter still look buggy on full agent turns

If you want, I can help you write a clean config recommendation from this, so OpenClaw stops routing into the broken/rate-limited paths.

#

Nice, this actually changes the picture a bit.

That log says:

google/gemini-3.1-pro-preview failed with 429 rate_limit
then OpenClaw fell back
and openrouter/openrouter/elephant-alpha succeeded

So I was too pessimistic about OpenRouter earlier. At least that OpenRouter fallback is working here.

The clearer diagnosis now

Your main problem is that something is still trying to start on:

google/gemini-3.1-pro-preview

#

and that model is hitting quota/rate limits.

Best stable setup right now

I’d make the working non-rate-limited model your primary explicitly:

openclaw models set google/gemini-2.5-flash

And if you want a conservative setup, keep OpenRouter elephant-alpha as the fallback and leave Groq out until you test it separately.

So the updated picture is:

google/gemini-3.1-pro-preview = rate-limited
google/gemini-2.5-flash = seems good
openrouter/openrouter/elephant-alpha = did successfully handle fallback here
Groq = still unclear / test separately

#

If you want, I can give you a clean recommended primary + fallback config next.

#

Yep, this log is basically the final answer.

The Telegram IPv4 warning is not the problem. The real failure is still:

provider: google
model: gemini-3.1-pro-preview
error: API rate limit reached
status: 429

So this is a quota/model-selection issue, not a Telegram/network one.

Clean stable config I’d use for now

#

{
  agents: {
    defaults: {
      model: {
        primary: "google/gemini-2.5-flash",
        fallbacks: ["openrouter/openrouter/elephant-alpha"]
      }
    }
  }
}

And I’d leave Groq out for the moment until you test it separately.

Quick CLI fix

At minimum, do this:

#

openclaw models set google/gemini-2.5-flash

Summary

google/gemini-3.1-pro-preview = rate-limited
google/gemini-2.5-flash = your best stable primary right now
openrouter/openrouter/elephant-alpha = good fallback candidate
Telegram warning = ignore for this issue

Docs:

If this finally got you to a stable setup, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed.

cursive notch Apr 21, 2026, 4:12 PM

#

2026-04-21T16:11:35.146Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=10607 error="FailoverError: ⚠️ API rate limit reached. Please try again later."
2026-04-21T16:11:35.147Z error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:telegram:direct:8736947311 durationMs=10608 error="FailoverError: ⚠️ API rate limit reached. Please try again later."
2026-04-21T16:11:35.150Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"d3f45485-87f8-478e-91e6-38db8ae734cf","decision":"candidate_failed","requestedProvider":"groq","requestedModel":"llama-3.1-8b-instant","candidateProvider":"groq","candidateModel":"llama-3.1-8b-instant","attempt":1,"total":2,"reason":"rate_limit","status":429,"errorPreview":"⚠️ API rate limit reached. Please try again later.","errorHash":"sha256:2a33d7700899","nextCandidateProvider":"google","nextCandidateModel":"gemini-2.5-flash","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision
2026-04-21T16:11:38.379Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_succeeded"],"runId":"d3f45485-87f8-478e-91e6-38db8ae734cf","decision":"candidate_succeeded","requestedProvider":"groq","requestedModel":"llama-3.1-8b-instant","candidateProvider":"google","candidateModel":"gemini-2.5-flash","attempt":2,"total":2,"isPrimary":false,"requestedModelMatched":false,"fallbackConfigured":true,"previousAttempts":[{"provider":"groq","model":"llama-3.1-8b-instant","reason":"rate_limit","status":429,"errorPreview":"⚠️ API rate limit reached. Please try again later.","errorHash":"sha256:2a33d7700899"}]} model fallback decision

royal thicketBOT Apr 21, 2026, 4:12 PM

#

Yep, this is the same story again, just with Groq this time.

What the log says:

groq/llama-3.1-8b-instant failed with 429 rate_limit
OpenClaw failed over
google/gemini-2.5-flash succeeded

So the picture is a lot cleaner now:

What’s actually happening

OpenClaw itself is working.
Your problem is that some of the models you’re choosing first are quota/rate-limit constrained:

google/gemini-3.1-pro-preview = 429
groq/llama-3.1-8b-instant = 429
google/gemini-2.5-flash = working fallback

#

openrouter/openrouter/elephant-alpha = also worked as fallback earlier

Stable setup I’d recommend

Use only the providers/models that are actually surviving real turns right now:

{
  agents: {
    defaults: {
      model: {
        primary: "google/gemini-2.5-flash",
        fallbacks: ["openrouter/openrouter/elephant-alpha"]
      }
    }
  }
}

#

And temporarily remove/disable:

google/gemini-3.1-pro-preview
groq/llama-3.1-8b-instant

until you sort out quota/billing on those providers.

Short version

This is no longer “OpenClaw is broken”.
It’s “your first-choice models are rate-limited, and failover is saving you.”

If this got you stable, please right-click the solution message → Apps → ✅ Mark Solution so it’s indexed for the next person.

cursive notch Apr 21, 2026, 4:12 PM

#

2026-04-21T16:11:35.140Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"d3f45485-87f8-478e-91e6-38db8ae734cf","isError":true,"error":"⚠️ API rate limit reached. Please try again later.","failoverReason":"rate_limit","model":"llama-3.1-8b-instant","provider":"groq","rawErrorPreview":"413 Request too large for model llama-3.1-8b-instant in organization org_01kk4dws94fr2tbza4de04rdb6 service tier on_demand on tokens per minute (TPM): Limit 6000, Requested 41510, please reduce your message size and try again. Need more tokens? Upgrade to Dev Tier today at https://console.groq.com/settings/billing","rawErrorHash":"sha256:dc98aa7014c1","providerRuntimeFailureKind":"rate_limit"} embedded run agent end
2026-04-21T16:11:35.145Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","fallback_model"],"runId":"d3f45485-87f8-478e-91e6-38db8ae734cf","stage":"assistant","decision":"fallback_model","failoverReason":"rate_limit","profileFailureReason":"rate_limit","provider":"groq","model":"llama-3.1-8b-instant","sourceProvider":"groq","sourceModel":"llama-3.1-8b-instant","fallbackConfigured":true,"timedOut":false,"aborted":false,"status":429,"rawErrorPreview":"413 Request too large for model llama-3.1-8b-instant in organization org_01kk4dws94fr2tbza4de04rdb6 service tier on_demand on tokens per minute (TPM): Limit 6000, Requested 41510, please reduce your message size and try again. Need more tokens? Upgrade to Dev Tier today at https://console.groq.com/settings/billing","rawErrorHash":"sha256:dc98aa7014c1","providerRuntimeFailureKind":"rate_limit"} embedded run failover decision

royal thicketBOT Apr 21, 2026, 4:13 PM

#

Yep, this explains the Groq side perfectly.

It’s not just a vague rate limit. Groq is telling you exactly why:

Request too large for model `llama-3.1-8b-instant`
TPM limit: 6000
Requested: 41510

So the problem is:

the probe succeeded because it was tiny
the real OpenClaw agent turn is much larger
groq/llama-3.1-8b-instant on your current tier cannot handle that prompt size

That’s why everything looked confusing at first. The auth was fine, but the real runtime prompt was too big.

#

Final diagnosis

google/gemini-3.1-pro-preview = quota/rate-limited
groq/llama-3.1-8b-instant = too small / too low TPM budget for real OpenClaw turns
google/gemini-2.5-flash = working
openrouter/openrouter/elephant-alpha = working fallback candidate

So yes, the stable answer is still:

Use:

{
  agents: {
    defaults: {
      model: {
        primary: "google/gemini-2.5-flash",
        fallbacks: ["openrouter/openrouter/elephant-alpha"]

#

      }
    }
  }
}

and stop routing real agent turns into:

google/gemini-3.1-pro-preview
groq/llama-3.1-8b-instant

That finally ties the whole thing together.

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

cursive notch Apr 21, 2026, 4:25 PM

#

openrouter/openrouter/elephant-alpha is also not working!!

royal thicketBOT Apr 21, 2026, 4:25 PM

#

Got it. Then my earlier read was too optimistic.

That candidate_succeeded line only meant OpenClaw successfully switched to OpenRouter, not that the final assistant turn completed cleanly.

So for OpenRouter I need the same kind of log snippet we got for Groq/Gemini.

Please do this:

openclaw models set openrouter/openrouter/elephant-alpha
openclaw logs --follow | grep -Eiv 'bonjour|telegram sendMessage ok'

Then in Telegram:

#

/new
hi

and paste the new lines.

If OpenRouter is also failing, the exact error text is the only way to tell whether it’s:

another rate limit
model/runtime incompatibility
or an empty-response/incomplete-turn issue again

So yeah, I believe you, I just need the OpenRouter-specific failure log now.

white vectorBOT Apr 21, 2026, 4:53 PM

#

languid vessel Apr 21, 2026, 5:13 PM

#

@cursive notch I've noticed a trend that OpenClaw 2026.4.15 (041266a) doesn't work with OpenRouter. (I have built 6 different instances of OC with this version and none of the work with OpenRouter)

What I did, was to scrape all of OpenClaw 2026.4.15 (041266a) off the machine. Real PITA if you have a lot of setup already. I re-installed OpenClaw 2026.4.2 (d74a122) and use OpenRouter Specific models, not openrouter/auto. (This setup works on one system I have that never was upgraded. Go figure)

If you choose this route, make sure you backup all of you setting files, etc.

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version 2026.4.2 --no-onboard

OR

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --version 2026.4.2

royal thicketBOT Apr 21, 2026, 5:14 PM

#

That’s a useful datapoint, thanks.

If 2026.4.15 + OpenRouter-specific models is failing across multiple fresh installs, that really does smell like a regression, especially if older 2026.4.2 works for you.

A few notes for anyone following along:

I’d treat the downgrade as a workaround, not the real fix.
If someone tries it, back up both:
- ~/.openclaw
- the agent workspace (often ~/.openclaw/workspace)
I would not recommend nuking a working setup unless they’ve already confirmed the current version is the blocker.

Most importantly, this should be filed as a bug here:
https://github.com/openclaw/openclaw/issues

The helpful report would be:

#

works on 2026.4.2
fails on 2026.4.15
provider: OpenRouter
specific model refs work/fail status
whether openrouter/auto vs explicit OpenRouter model changed behavior
logs showing the failure mode (payloads=0, rate limit, etc.)

That kind of version-to-version regression report is exactly what maintainers need.

languid vessel Apr 21, 2026, 5:16 PM

#

I agree. Nuking a production setup is not the best way to go, but maybe build a different one if possible and transfer all of your setup over.

royal thicketBOT Apr 21, 2026, 5:16 PM

#

Yep, that’s the safer way.

If someone wants to test the regression path, I’d do it on a separate instance, not by blowing away the production one. Copy over:

~/.openclaw
the workspace directory

Then test the older version there first.

That gives you a workaround without trashing the live setup, and it still leaves a clean regression report for GitHub.

languid vessel Apr 21, 2026, 5:17 PM

#

I have multiple setups and ran across it when instansiating a new one. I nuked it, for troubleshooting purposed, because it was brand new and no loss to me if it failed.

royal thicketBOT Apr 21, 2026, 5:18 PM

#

That makes sense, and yeah, on a throwaway fresh install that’s a totally reasonable troubleshooting move.

The really valuable bit is that you reproduced it on a new instance, not just an old upgraded one. That’s great bug-report material for https://github.com/openclaw/openclaw/issues.

languid vessel Apr 21, 2026, 5:19 PM

#

I have filled out a GH issue already with the pertinant information.

royal thicketBOT Apr 21, 2026, 5:19 PM

#

Perfect, thanks, that helps a lot.

A fresh-install repro plus the version difference is exactly the kind of signal that makes these much easier to chase down.

languid vessel Apr 21, 2026, 5:20 PM

#

I left git and npm when I scraped OpenClaw 2026.4.15 (041266a) off. So it doesn't appear to be a dependency issue there.

royal thicketBOT Apr 21, 2026, 5:20 PM

#

That’s a really helpful datapoint too.

If git/npm stayed put and only the OpenClaw version changed, that makes a plain dependency drift explanation a lot less likely.

cursive notch Apr 22, 2026, 10:47 AM

#

Thanks @languid vessel! So actually this is already my second instance. But the first one was also at version 2026.4.10 and had problems. Thanks for your answer I will try it out later. Do you have also experience with the groq.com provider? I am having problems with this provider too.

royal thicketBOT Apr 22, 2026, 10:48 AM

#

Yep, for Groq we actually got a pretty clear answer from your logs.

It wasn’t a generic auth/setup failure. Groq was rejecting the full OpenClaw agent prompt because it was too large for that model/tier:

llama-3.1-8b-instant
TPM limit: 6000
Requested: 41510

So in your case the Groq problem looks like:

provider is reachable
tiny probes can pass
but real OpenClaw turns are too big for that Groq model/tier

So I would not use llama-3.1-8b-instant as a primary model for OpenClaw on that setup.

#

If you want broader real-world advice on which Groq models are behaving well right now, #models is the best place for that, since people there will have fresher hands-on experience.

white vectorBOT Apr 22, 2026, 11:21 AM

#

cursive notch Apr 22, 2026, 11:31 AM

#

Okay, which models of groq.com can you recommend?

royal thicketBOT Apr 22, 2026, 11:32 AM

#

I wouldn’t trust myself to give a fresh Groq ranking here, that changes too fast.

Best place for current Groq recommendations is #models plus the docs here:

What I can say from your logs is:

avoid the 8B instant one you tested on your current tier, it blew the TPM budget on real OpenClaw turns

So for up-to-date “which Groq model is actually working well right now”, ask in #models.

cursive notch Apr 22, 2026, 1:52 PM

#

I don't have the permissions to write in #1478196963563409520

royal thicketBOT Apr 22, 2026, 1:53 PM

#

No worries.

For real human experience / recommendations, use #users-helping-users instead. That’s the better fallback if you can’t post in the model channel.

And for the reference docs, keep these handy:

For this specific thread, I’d keep troubleshooting here and stick to the provider/model combo that’s already working on your setup for now.

cursive notch Apr 22, 2026, 2:56 PM

#

So, I tried it with downgrading the version and it worked. Thanks to @languid vessel

#OpenClaw just answering with: ⚠️ Agent couldn't generate a response. Please try again.

1) Check whether bootstrap is actually cleared

2) If bootstrap is gone but it still errors, capture the real runtime error

Option A, confirm bootstrap is gone

Option B, capture the actual runtime error

Next step

Fastest workaround

Two paths from here

What to include in the issue

What I’d do

Practical fix for now

For the actual bug

Important detail

What I’d do now

So the final picture is

The clearer diagnosis now

Best stable setup right now

Clean stable config I’d use for now

Quick CLI fix

Summary

What’s actually happening

Stable setup I’d recommend

Short version

Final diagnosis

So yes, the stable answer is still: