Some of the OpenRouter models not working

[fierce jetty]

Although some of the free models namely Nemotron 12B, 9B, kimi 2.5, glm 4.5, etc. have great up-time and perform great, only openrouter/elephant is working for me thus far.

I tested with curl, it works. I tested with openclaw models scan, it did ping all of the best free models successfully. But when I actually use the models themself, I get

[agent/embedded] incomplete turn detected: runId=4f470e7f-bbbc-4329-aed9-7bd01618996f sessionId=f59454d0-03f1-43e4-aa4e-411dc19a16ef stopReason=stop payloads=0 — surfacing error to user

How should I address this issue?

[supple thicket]

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

[fierce jetty]

openrouter/free doesnt work

but openrouter/elephant works

strange

I've spent 4 hours with Gemini and Grok they cant help me with this.

[astral herald]

I’m checking the docs and the code path for that exact error so I don’t guess.

I found the exact code path. That message means OpenClaw got a clean stop from the model, but zero user-visible output back, so it surfaced an “incomplete turn” instead of pretending success. Now I’m checking whether docs already call out OpenRouter model reliability/tool issues.

That warning means the model stopped normally, but OpenClaw got zero user-visible payloads back, so it surfaced an incomplete turn instead of pretending success.

Given your tests, I’d read it like this:

• curl working = auth/endpoint is probably fine
• openclaw models scan passing = the model passed a tiny probe
• normal agent turns failing = the model is likely not reliable with OpenClaw’s full runtime (longer prompt, session context, tool schema, reasoning blocks, etc.)

One important detail: models scan --probe is not a full agent-turn test. In source, it basically does a tiny forced ping-tool check, not a real embedded-agent run.

I’d check these next, in order:

openclaw --version
openclaw status --all
openclaw infer model run --model openrouter/<exact-model-id> --prompt "Reply with exactly: smoke-ok" --json

openclaw logs --follow

Then inspect a few lines above the warning in the logs. OpenClaw usually logs which class of failure it saw first:

• reasoning-only assistant turn detected
• empty response detected

That distinction matters.

Practical read on outcomes:

• If infer model run fails too, that model is not stable enough for OpenClaw runtime, even if raw curl/scan work.
• If infer model run works but normal chat turns fail, it is usually prompt/tool/session pressure from the full agent loop.

So the likely fixes are:

1. Check/update your OpenClaw version first
2. Validate models with infer model run, not just models scan
3. For flaky free OpenRouter models, use them as fallbacks, not your main agent model

Docs:

• https://docs.openclaw.ai/cli/infer
• https://docs.openclaw.ai/help/troubleshooting
• https://docs.openclaw.ai/concepts/models#scanning-openrouter-free-models

If you paste:

• openclaw --version
• the infer model run output
• 10 to 20 log lines around that warning

I can help pin down whether this is empty-response, reasoning-only, or tool-schema weirdness.

Yeah, that tracks.

Short version, I would not treat OpenRouter free models as reliable primary agent models for OpenClaw right now. They can pass curl and even pass models scan, then still fall over on a real embedded-agent turn.

Why this happens:

• models scan is only a small probe
• normal OpenClaw runs are a bigger runtime shape (prompting, session context, tool schema, retries, reasoning handling)

So the practical advice is:

1. Do not use OpenRouter free as your main model
2. Use it only for experiments or fallback
3. Validate candidates with:

   openclaw infer model run --model openrouter/<model> --prompt "Reply with exactly: smoke-ok" --json
   

   not just openclaw models scan

If you want the boring-but-working route, use a more reliable primary provider/model and keep OpenRouter free behind it.

Docs:

• https://docs.openclaw.ai/cli/infer
• https://docs.openclaw.ai/concepts/models
• https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

If you paste openclaw --version, I can tell you whether you’re also hitting a version-specific bug or just general free-model flakiness.

Yep, and that’s actually a useful clue.

If openrouter/elephant works, then:

• your OpenRouter auth is fine
• your OpenClaw setup is basically fine
• the problem is model/route-specific, not “OpenRouter is broken”

So I’d read this as:

• Elephant returns a proper visible answer in OpenClaw’s agent loop
• those other free routes are stopping with no usable final payload

In other words, this is mostly a compatibility/reliability issue with specific free models, not your config.

So the practical move is:

1. keep openrouter/elephant as primary
2. treat the flaky free models as experimental only
3. test candidates with openclaw infer model run, one by one, before trusting them in normal agent use

If you want, paste your openclaw --version and I can tell you whether there’s also a recent bug in the mix, but the Elephant datapoint makes me think your setup is fundamentally okay.

Yeah, a bit 😅

But it does happen with proxy providers. Same provider, same key, different routes can behave very differently once the full agent runtime is involved.

So the weird part is real, but the diagnosis is still pretty clean:

• not an auth problem
• not “OpenRouter is totally broken”
• yes, likely a specific-model/runtime compatibility issue

I’d honestly just treat the flaky ones as bad candidates for OpenClaw for now.

If you want to dig one level deeper, the next useful thing is:

openclaw --version

openclaw infer model run --model openrouter/<one-bad-model> --prompt "Reply with exactly: smoke-ok" --json
openclaw logs --follow

That’ll tell us if it’s just free-model flakiness, or a version-specific bug too.

[fierce jetty]

OpenClaw 2026.4.15 (041266a)

[astral herald]

Oof, that’s frustrating. I don’t think this is user error.

At this point I would stop asking general models to reason about it and get one concrete repro from OpenClaw itself. Otherwise it’s just guesswork.

Please run exactly these:

openclaw --version
openclaw infer model run --model openrouter/<one failing model> --prompt "Reply with exactly: smoke-ok" --json
openclaw logs --follow

Then paste:

• the version
• the full infer model run output
• ~15 lines around the failure in the log

Why this matters:

• if infer model run fails too, the model is just not compatible enough with OpenClaw’s runtime
• if infer model run works but normal chat fails, then it’s session/tool/prompt pressure
• if elephant works and the others don’t, your config and key are probably fine

Honestly, if you’ve already burned 4 hours on this, my practical recommendation is:

• use openrouter/elephant for now
• stop treating the other free routes as trustworthy until one passes infer model run

If you paste those outputs, I’ll help you narrow it fast.

Nice, thanks, that’s recent enough that I wouldn’t blame an old OpenClaw build first.

So the most likely read is still:

• your setup is basically okay
• openrouter/elephant working proves the pipeline can work
• the failing OpenRouter free routes are returning something OpenClaw can’t turn into a visible final reply

Next step, one bad model only:

openclaw infer model run --model openrouter/<failing-model> --prompt "Reply with exactly: smoke-ok" --json
openclaw logs --follow

Then paste:

• the full infer model run output
• about 10 to 20 log lines around the failure

What I’m looking for in the logs is whether OpenClaw says:

• reasoning-only assistant turn detected, or
• empty response detected

That’ll tell us if this is a weird reasoning-only finish vs a true empty-output model failure.

Based on what you’ve shared so far, I’m leaning toward specific free-model incompatibility, not a broken install.

[fierce jetty]

(base) PS C:\Users\admin> openclaw infer model run --model openrouter/free --prompt "Reply with exactly: smoke-ok" --json
02:24:45 [agent/embedded] incomplete turn detected: runId=f59454d0-03f1-43e4-aa4e-411dc19a16ef sessionId=f59454d0-03f1-43e4-aa4e-411dc19a16ef 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
}
]
}

(base) PS C:\Users\admin> openclaw infer model run --model openrouter/openrouter/free --prompt "Reply with exactly: smoke-ok" --json
02:26:40 [agent/embedded] incomplete turn detected: runId=f59454d0-03f1-43e4-aa4e-411dc19a16ef sessionId=f59454d0-03f1-43e4-aa4e-411dc19a16ef 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
}
]
}

(base) PS C:\Users\admin> openclaw infer model run --model openrouter/nvidia/nemotron-nano-9b-v2:free --prompt "Reply with exactly: smoke-ok" --json
02:28:23 [agent/embedded] incomplete turn detected: runId=f59454d0-03f1-43e4-aa4e-411dc19a16ef sessionId=f59454d0-03f1-43e4-aa4e-411dc19a16ef stopReason=stop payloads=0 — surfacing error to user
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openrouter",
"model": "nvidia/nemotron-nano-9b-v2:free",
"attempts": [],
"outputs": [
{
"text": "⚠️ Agent couldn't generate a response. Please try again.",
"mediaUrl": null
}
]
}
(base) PS C:\Users\admin>

[astral herald]

I’ve got enough signal now. I’m just checking one detail about openrouter/free vs explicit model refs so I don’t tell you the wrong thing.

Perfect, this is actually enough to narrow it down.

That repro tells us:

• it fails in openclaw infer model run
• so it is not a Discord/thread/session-routing problem
• it is not an auth problem either, because openrouter/elephant works
• it is very likely a specific OpenRouter free model compatibility issue with OpenClaw’s embedded runtime

Also, this explains the confusing part:

• openclaw models scan passing does not prove normal agent turns will work
• the scan only does a small probe
• your infer model run test is much closer to real usage, and it fails consistently

So my honest recommendation is:

1. Stop debugging your install
2. Do not use openrouter/free as your primary model
3. Use a concrete model that passes for you, like openrouter/elephant
4. Treat the failing free models as unsupported/flaky for now

If you want to take it further, this is now good GitHub issue material. Include:

• OpenClaw 2026.4.15 (041266a)
• the exact infer model run commands
• the exact JSON outputs
• the stopReason=stop payloads=0 log line

Issue tracker:
https://github.com/openclaw/openclaw/issues

I’m glad we got to a real answer here, because I don’t think another 4 hours of poking at config is going to pay off.