Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Native OpenRouter integration fails for openrouter/openrouter/free with incomplete turn / payloads=0, even in a clean OpenClaw 2026.4.15 container.

Steps to reproduce

1. Run a clean ephemeral OpenClaw container with valid OpenRouter credentials from an env file:

docker run --rm -it
--env-file /var/docker-skynet/.env
ghcr.io/openclaw/openclaw:2026.4.15
sh -lc '
openclaw models set openrouter/openrouter/free &&
openclaw infer model run --model openrouter/openrouter/free --prompt "Reply with exactly: smoke-ok" --json
'

2. Observe that OpenClaw returns:

   • [agent/embedded] incomplete turn detected ...
   • stopReason=stop
   • payloads=0
   • "⚠️ Agent couldn't generate a response. Please try again."

3. Compare with a direct OpenRouter API call from the same environment:

curl -i -s https://openrouter.ai/api/v1/chat/completions
-H "Authorization: Bearer $OPENROUTER_API_KEY"
-H "Content-Type: application/json"
-d '{
"model":"openrouter/free",
"messages":[{"role":"user","content":"Reply with exactly: smoke-ok"}]
}'

This direct call succeeds and returns HTTP 200 with a valid assistant response.

Expected behavior

OpenClaw should successfully return the model response when using the native OpenRouter integration with openrouter/openrouter/free, especially when the same prompt succeeds through a direct OpenRouter API call from the same container/environment.

Actual behavior

OpenClaw's native OpenRouter path fails with:

[agent/embedded] incomplete turn detected ... stopReason=stop payloads=0

The CLI returns:
"⚠️ Agent couldn't generate a response. Please try again."

This happens even in a clean ephemeral OpenClaw 2026.4.15 container with valid auth and without mounting any existing config or workspace.

OpenClaw version

2026.4.15

Operating system

Ubuntu 24.04

Install method

Docker

Model

openrouter/free

Provider / routing chain

Native OpenRouter integration in OpenClaw Model reference in OpenClaw: openrouter/openrouter/free Routing tested directly against OpenRouter API: https://openrouter.ai/api/v1/chat/completions

Additional provider/model setup details

• OPENROUTER_API_KEY provided via --env-file /var/docker-skynet/.env
• The same environment can call OpenRouter directly successfully
• Reproduced in a clean ephemeral container, so this does not appear to depend on existing mounted config or persistent volumes
• Also reproduced previously from the normal deployed container/UI/Telegram path, but the clean Docker repro above is the minimal case

Logs, screenshots, and evidence

Clean repro command:

docker run --rm -it \
  --env-file /var/docker-skynet/.env \
  ghcr.io/openclaw/openclaw:2026.4.15 \
  sh -lc '
    openclaw models set openrouter/openrouter/free &&
    openclaw infer model run --model openrouter/openrouter/free --prompt "Reply with exactly: smoke-ok" --json
  '

Observed output:

15:26:54 [agent/embedded] incomplete turn detected: runId=47c21d0f-283b-48c7-bd2f-ddd0b3fdb936 sessionId=47c21d0f-283b-48c7-bd2f-ddd0b3fdb936 stopReason=stop payloads=0 — surfacing error to user

{
  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openrouter",
  "model": "openrouter/free",
  "attempts": [],
  "outputs": [
    {
      "text": "⚠️ Agent couldn't generate a response. Please try again.",
      "mediaUrl": null
    }
  ]
}

Direct OpenRouter API call from the same environment succeeds with HTTP 200 and returns "smoke-ok".

Also verified that:
- https://openrouter.ai/api/v1/chat/completions is the correct working endpoint
- https://openrouter.ai/api/chat/completions does not return the API response and instead returns HTML / a site page

Impact and severity

High for native OpenRouter users.
This makes the native OpenRouter integration unusable for openrouter/free in my environment, even though the underlying OpenRouter API itself is working correctly. It blocks using OpenClaw with native OpenRouter routing for this model.

Additional information

I specifically need to use OpenRouter natively in OpenClaw.

This issue is not limited to Telegram or the web UI:

• It reproduced in Telegram
• It reproduced in the OpenClaw UI
• It reproduced in a clean ephemeral Docker container using only the CLI

That strongly suggests the issue is in OpenClaw's native OpenRouter execution path rather than in the client channel, my persisted config, or OpenRouter availability itself.