OpenRouter Shows Tokens Used — But OpenClaw Never Replies (payloads=0)
You configure OpenClaw with an OpenRouter API key, restart the gateway, and send a message. Nothing comes back. The error is:
⚠️ Agent couldn't generate a response. Logs: incomplete turn detected ... payloads=0So you check your OpenRouter dashboard — and the request is there. Tokens consumed. OpenRouter says it worked. But OpenClaw has nothing to show for it.
This is a different bug from the double-prefix config issue. That one never reaches OpenRouter at all. This one reaches OpenRouter just fine — and fails on the way back.
What's Happening
OpenClaw's turn parser expects streamed response chunks in a specific SSE format. When using certain OpenRouter model routes — particularly Google Gemini models routed through OpenRouter (openrouter/google/gemini-2.5-flash, gemini-2.5-flash-lite, gemini-2.5-pro-preview) — the streaming format OpenRouter returns differs subtly from what OpenClaw's internal chunk parser expects.
The chunks arrive, OpenClaw's stream reader consumes them, but the content-block extraction step produces zero payloads. The turn closes with payloads=0 and the agent surfaces an error instead of a response.
This appears to be more pronounced on arm64 platforms (Raspberry Pi 5, Apple Silicon Mac), though the root cause is in the parser, not the architecture.
How to Confirm This Is Your Problem
# 1. Send a test message
openclaw agent --to self --message "hello"
# 2. Check OpenRouter dashboard at https://openrouter.ai/activity
# If tokens are showing up there but you got no reply → this bug
# 3. Check gateway logs
openclaw gateway logs | grep -E "(payloads=0|incomplete turn|openrouter)"
# You'll see: "incomplete turn detected: ... payloads=0"
The key indicator: OpenRouter shows usage, but your agent shows nothing. If OpenRouter shows zero usage, see the double-prefix post instead.
Fixes
Fix 1: Switch to a Non-Gemini Model via OpenRouter
OpenRouter routes many models. The parsing issue is most consistently reproduced with Gemini models. Switching to a different provider through OpenRouter often resolves it immediately:
# Edit your openclaw config
openclaw configure
# When prompted for model, try:
# openrouter/anthropic/claude-3.5-haiku
# openrouter/mistralai/mistral-7b-instruct
# openrouter/meta-llama/llama-3.1-8b-instruct:free
Fix 2: Configure the Provider Directly (Bypass OpenRouter)
If you're using Gemini specifically, configure it directly instead of routing through OpenRouter:
openclaw configure
# Select: google (Gemini)
# Enter your Google AI API key from https://aistudio.google.com/apikey
# Select model: gemini-2.5-flash
Direct Gemini integration doesn't hit this parser issue.
Fix 3: Use Anthropic Directly
If you have an Anthropic API key, Claude is unaffected by this bug:
openclaw configure
# Select: anthropic
# Enter your Claude API keyFix 4: Try 4.15-beta.1 (May or May Not Help)
This issue was reproduced on both 2026.4.14 stable and 4.15-beta.1, so upgrading to beta is unlikely to help. Skip this unless you need beta features for other reasons.
Long-Term
The fix requires OpenClaw to handle the Gemini-via-OpenRouter streaming format correctly. Track progress at issue #67575.
Raspberry Pi Users
Running OpenClaw on a Pi 5? The local Ollama route completely sidesteps this — no external API, no parsing issues. A Pi 5 8GB can run qwen2.5:7b or llama3.1:8b comfortably. If you want help setting up Ollama on your Pi as a fallback, ClawReady's setup service covers it.