Model error

[rancid ember]

I'm getting a lot of "Unexpected end of JSON input" and also errors about whitespace. I'm using the Nvidia kimi k2.5 model. I don't get this from kimi code provider using the the same model. It happens mid coding task.

[shrewd briar]

Those errors almost always mean OpenClaw tried to JSON.parse(...) something that was supposed to be valid JSON (usually tool-call arguments) but the provider/model returned truncated or “decorated” JSON instead.

• “Unexpected end of JSON input” ⇒ the JSON string got cut off mid-object/array (common if the provider stops early, hits an output limit, or streaming tool-call deltas are buggy).
• “whitespace” / “unexpected token” style errors ⇒ the model often wrapped the JSON in extra text (e.g. ```json fences, trailing commentary), or emitted something JSON5-ish. (Plain JSON allows whitespace, so “whitespace” errors typically mean “there was non-JSON content where JSON was required”.)

Why you see it with “Nvidia kimi k2.5” but not “Kimi Code provider” even with the “same model”: different providers vary a lot in tool-calling correctness and streaming behavior. One endpoint may enforce/repair structured outputs; another may just stream raw tokens and occasionally break JSON.

What I’d try / what to paste so we can confirm:

1. openclaw --version
2. openclaw status --all (safe-ish to share; redacts secrets)
3. A log snippet around the failure showing which tool it was trying to call when JSON parsing blew up (openclaw logs --follow and grab ~30-50 lines around the error).

Docs for the quick triage loop:

• https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken
• https://docs.openclaw.ai/gateway/troubleshooting

If it’s blocking you right now: the pragmatic workaround is to run tool-heavy coding tasks on a provider/model combo that’s known to be strict about tool-call JSON (some providers are just flaky here), and keep Nvidia/Kimi for pure text where tool calls aren’t required.

[rancid ember]

C:\Users\Tom>openclaw logs --follow

🦞 OpenClaw 2026.2.1 (ed4529e) — Ah, the fruit tree company! 🍎

Log file: \tmp\openclaw\openclaw-2026-02-07.log
05:19:41 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
05:20:52 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
05:20:52 info nvidia/moonshotai/kimi-k2.5
05:22:00 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
05:40:22 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
05:42:30 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)

[shrewd briar]

That log snippet doesn’t include the actual failure yet — it’s just the CLI/plugin init noise + the model banner (info nvidia/moonshotai/kimi-k2.5). To diagnose the JSON parse problem we need the stack / error block around “Unexpected end of JSON input” (and the few lines above it that usually mention which tool call it was parsing).

Can you grab one of these and paste the output?

Option A (quick, in-terminal):

openclaw logs --limit 500 | findstr /n /i "Unexpected end of JSON input whitespace JSON.parse tool tool_use"

Option B (search the log file directly):

Select-String -Path "\tmp\openclaw\openclaw-2026-02-07.log" `
-Pattern "Unexpected end of JSON input|whitespace|JSON.parse|tool_use|tool" `
-Context 5,10

Also helpful (it includes a safe log tail + config/runtime summary):

openclaw status --all

If the error still doesn’t show up in the file logs, paste the exact console error text you see when it happens (sometimes it’s thrown client-side during tool parsing).

If we can capture one full error block, we can tell whether this is:

• provider streaming truncation (common cause of “Unexpected end…”), or
• the model emitting non-JSON around tool args (common cause of “whitespace/unexpected token…”),
  and then decide on the best workaround / whether it’s a GitHub-issue-worthy provider bug.

[rancid ember]

10:2026-02-07T05:50:41.974Z error [tools] exec failed: At line:1 char:51
15: + FullyQualifiedErrorId : InvalidEndOfLine
18:2026-02-07T05:51:26.913Z error [tools] exec failed: Command exited with code 1
19:2026-02-07T05:54:05.611Z error [tools] exec failed: FINDSTR: Cannot open makefile
22:2026-02-07T05:54:17.578Z error [tools] exec failed: At line:1 char:51
27: + FullyQualifiedErrorId : InvalidEndOfLine
30:2026-02-07T05:56:07.247Z error [tools] exec failed: At line:1 char:59
35: + FullyQualifiedErrorId : InvalidEndOfLine
38:2026-02-07T05:56:46.714Z error [tools] exec failed: CppAutoVara.exe : The term 'CppAutoVara.exe' is not recognized as the name of a cmdlet, function, script file, or
39:operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try

[shrewd briar]

Those log lines aren’t the “Unexpected end of JSON input” issue — they show [tools] exec successfully ran, but then the command failed inside PowerShell / Windows.

A few key bits:

• FullyQualifiedErrorId : InvalidEndOfLine = PowerShell parser error. This usually happens when the model generated a command with broken quoting or bash-style line continuations (like trailing \) that PowerShell can’t parse.
• CppAutoVara.exe … not recognized = PowerShell won’t run executables from the current directory unless you prefix them with .\
  → should be .\CppAutoVara.exe (and the file must actually exist).
• FINDSTR: Cannot open makefile = it tried to search a file literally named makefile in the current dir, but it isn’t there (or wrong working dir).

Can you paste the full PowerShell error block for one of the InvalidEndOfLine entries? Specifically the lines PowerShell prints between:
At line:1 char:51 and FullyQualifiedErrorId : InvalidEndOfLine
(that block normally includes the exact command text + the ~ underline). Without the exact command, we can’t tell what syntax the model emitted.

Immediate workaround you can add to your prompt/system for that model:

• “You are on Windows PowerShell (not bash). Don’t use \ line continuations. Keep commands single-line. To run a local exe, use .\Name.exe.”

Exec tool doc (for context): https://docs.openclaw.ai/tools/exec

If you’re still also seeing the JSON parse errors, grab ~20 lines around the first occurrence of “Unexpected end of JSON input” from the log file — that’s a separate failure mode and we can tackle it next.

[rancid ember]

Why can't i switch to openrouter auto mode?
Models (openrouter) — showing 1-5 of 5 (page 1/1)

• openrouter/auto
• openrouter/google/gemma-3-27b-it:free
• openrouter/nvidia/nemotron-3-nano-30b-a3b:free
• openrouter/qwen/qwen3-coder:free
• openrouter/z-ai/glm-4.5-air:free

Switch: /model <provider/model>
All: /models openrouter all

Model "openrouter/auto" is not allowed. Use /models to list providers, or /models <provider> to list models.

[shrewd briar]

That error means you have a model allowlist configured, and openrouter/auto isn’t in it.

In OpenClaw, agents.defaults.models acts as the allowlist for /model (and /models), so anything not listed there will fail with:

Model "provider/model" is not allowed

Docs: https://docs.openclaw.ai/help/troubleshooting#model-says-model-not-allowed

What to do

On the gateway host, check your allowlist:

openclaw config get agents.defaults.models

If it’s non-empty, either:

A) Add OpenRouter auto to the allowlist

openclaw config set 'agents.defaults.models["openrouter/auto"]' '{}' --json
openclaw gateway restart

B) Or remove/clear the allowlist (then you can pick any discovered model)

openclaw config unset agents.defaults.models
openclaw gateway restart

Why it’s not enabled by default

openrouter/auto is a router entry (it can route to different underlying models), so the wizard commonly doesn’t include it in agents.defaults.models unless you opt in manually.

If you paste the output of openclaw config get agents.defaults.models I can tell you exactly which path (A or B) is cleaner for your setup.

[rancid ember]

{
"openrouter/auto": {
"alias": "OpenRouter"
},
"openrouter/z-ai/glm-4.5-air:free": {
"alias": "glm-free"
},
"openrouter/nvidia/nemotron-3-nano-30b-a3b:free": {
"alias": "nano-free"
},
"openrouter/google/gemma-3-27b-it:free": {
"alias": "gemma-free"
},
"openrouter/qwen/qwen3-coder:free": {
"alias": "qwen"
},
"kimi-coding/k2p5": {
"alias": "Kimi K2.5"
},
"nvidia/moonshotai/kimi-k2.5": {
"alias": "nvidia-kimi"
}
}

[shrewd briar]

Yeah — with that config, openrouter/auto should be allowed. When it still says “not allowed”, it’s usually because the running agent config can’t resolve OpenRouter at runtime, so the allowlist gets filtered down.

OpenClaw’s allowlist logic isn’t “keys in agents.defaults.models = allowed”; it only keeps an allowlisted model if either:

• it exists in the discovered model catalog, or
• the provider is configured under models.providers (or is otherwise recognized as configured).

So the next thing to check is: is OpenRouter actually configured/visible to the Gateway process?

1) Check OpenRouter auth/config state

Run and paste the non-secret parts:

openclaw models status

You’re looking for whether OpenRouter shows up as configured/authenticated.

If you haven’t configured it yet, the docs-supported way is:

• put OPENROUTER_API_KEY in your OpenClaw config env, or

• onboard it via CLI.

Docs: https://docs.openclaw.ai/providers/openrouter

2) Also verify you’re editing the same config the Gateway is using

This catches the “CLI config vs service config” mismatch:

openclaw gateway status

If it shows different Config (cli) vs Config (service), you’re editing one file and the service is running another.

If you paste openclaw models status + openclaw gateway status output, I can tell you exactly which of the two it is.

[rancid ember]

C:\Users\Tom>openclaw models status

🦞 OpenClaw 2026.2.1 (ed4529e) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Config : C:\Users\Tom.openclaw\openclaw.json
Agent dir : C:\Users\Tom.openclaw\agents\main\agent
Default : nvidia/moonshotai/kimi-k2.5
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (7) : opfree -> openrouter/free, glm-free -> openrouter/z-ai/glm-4.5-air:free, nano-free -> openrouter/nvidia/nemotron-3-nano-30b-a3b:free, gemma-free -> openrouter/google/gemma-3-27b-it:free, qwen -> openrouter/qwen/qwen3-coder:free, Kimi K2.5 -> kimi-coding/k2p5, nvidia-kimi -> nvidia/moonshotai/kimi-k2.5
Configured models (7): openrouter/free, openrouter/z-ai/glm-4.5-air:free, openrouter/nvidia/nemotron-3-nano-30b-a3b:free, openrouter/google/gemma-3-27b-it:free, openrouter/qwen/qwen3-coder:free, kimi-coding/k2p5, nvidia/moonshotai/kimi-k2.5

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

• google effective=profiles:C:\Users\Tom.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | google:default=AIzaSyDA...O-4GpYHo
• kimi-coding effective=profiles:C:\Users\Tom.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kimi-coding:default=sk-kimi-...CnwDxhlR
• moonshot effective=profiles:C:\Users\Tom.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | moonshot:default=sk-MSc8M...ZIcGFDKj
• nvidia effective=profiles:C:\Users\Tom.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nvidia:default=nvapi-Tm...9asKQcTH
• openrouter effective=profiles:C:\Users\Tom.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...5652e66a

OAuth/token status

• none

[shrewd briar]

Your models status output is the clue:

• You do have OpenRouter creds (openrouter:default=sk-or-…)
• But your effective allowed catalog (what /model can switch to) is the “Configured models (7)” list — and it does not include openrouter/auto.

This happens because openrouter/auto is a “router” pseudo-model and often isn’t present in the discovered model catalog, so when agents.defaults.models is used as an allowlist, OpenClaw filters it out unless it can prove it’s a valid/catalog model.

Workarounds

Option 1 (simplest): make it the default model

openclaw config set agents.defaults.model.primary "openrouter/auto"
openclaw gateway restart

Once it’s the default, it’s treated as allowed and you can still switch away per-session.

Option 2: remove the allowlist

openclaw config unset agents.defaults.models
openclaw gateway restart

(Then /model openrouter/auto won’t be blocked by allowlist enforcement.)

If you want, paste openclaw config get agents.defaults.model and openclaw gateway status and I’ll tell you which option is cleaner for your setup (and whether you’ve got any config/service mismatch going on).

[rancid ember]

Now why does my agent always stop mid way a task. It doesn't continue it's task until i say something again. Even my heartbeat config is telling them to test model, respond and continue task. The bot will just say heart beat ok then does nothing until i say something again. My context is below 50%. I have tried many different free model on openrouter and they all eventually stall.

[shrewd briar]

Two different things can look like “it stalled”, so first we need to separate them:

1) “It stopped because OpenClaw is turn-based” (normal)

OpenClaw doesn’t run an autonomous loop. It does one agent turn per trigger (an inbound message, a cron job, or a heartbeat tick), then it stops.

Heartbeat is not “continue my coding task until done” — it’s a periodic check-in. If the heartbeat run returns HEARTBEAT_OK, OpenClaw treats that as “nothing to report” and it won’t magically keep working on your last coding task. That’s by design (see docs: https://docs.openclaw.ai/gateway/heartbeat and https://docs.openclaw.ai/automation/cron-vs-heartbeat).

If you want “keep going without me typing”, you need something that triggers more turns, e.g.:

• a cron job (isolated) that says “continue working on X” every N minutes, or
• a workflow tool (Lobster), or
• run the actual coding work in a dedicated coding agent (Claude Code/Codex) and let OpenClaw just orchestrate.

2) “It stopped because the run got aborted / timed out / provider stream died” (bug/ops issue)

This is common with free OpenRouter models: they can silently drop/timeout mid-stream, or break tool-call JSON, and the gateway ends the run. Then it only “continues” when you send a new message (because that starts a new run).

What to check when it happens:

A) Look for timeout/abort in logs

Run:

openclaw logs --follow

…and when it stalls, paste the first error/warn block around it (you’re looking for words like timeout, aborted, disconnect, 429, All models failed, Unexpected end of JSON input, etc.).

B) Increase the agent reply timeout (if you do long tasks)

Default is 30 min. You can bump it:

openclaw config set reply.timeoutSeconds 3600 --json
openclaw gateway restart

(Docs: https://docs.openclaw.ai/gateway/troubleshooting#agent-timing-out)

C) Check if it’s “waiting on a tool” vs actually dead

When it “stalls”, try sending /status in the chat. If it says it’s still running, it’s not stalled — it’s busy (often on exec or a provider call). If it’s idle, the run ended.

---

If you paste a log snippet from the moment it stalls (20–50 lines around the first real error), I can tell you which bucket you’re in and what the next fix is.

[rancid ember]

16:57:37 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a3674dc2-4cb1-4526-9a62-18a8d04cfe71 tool=process toolCallId=call_452cd0d5a6b241fd95f4dad7
16:57:37 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=a3674dc2-4cb1-4526-9a62-18a8d04cfe71 tool=process toolCallId=call_452cd0d5a6b241fd95f4dad7
16:57:44 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a3674dc2-4cb1-4526-9a62-18a8d04cfe71 tool=process toolCallId=call_2166fff980494eabb8ca845b
16:57:44 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=a3674dc2-4cb1-4526-9a62-18a8d04cfe71 tool=process toolCallId=call_2166fff980494eabb8ca845b
16:57:51 debug agent/embedded {"subsystem":"agent/embedded"} embedded run tool start: runId=a3674dc2-4cb1-4526-9a62-18a8d04cfe71 tool=process toolCallId=call_6e6bdd3c10c849f5a1583e1e

[shrewd briar]

That snippet is actually useful: it shows the agent didn’t “go idle” — it got stuck mid-run inside a tool call:

• you have tool start: tool=process …
• but for the last one (call_6e6bdd…) there’s no corresponding “tool end” in what you pasted

So the run is blocked waiting for the process tool to return (or the Gateway died right after starting it). That’s why you don’t get a final assistant message until you poke it again (new message → new run).

The two most common causes

1) Agent run timeout (very common with slow/free models)

In 2026.2.x the agent runtime timeout defaults to 600s (10 minutes) (agents.defaults.timeoutSeconds). Free OpenRouter models are often slow enough that tool-heavy runs hit this.

Check and bump it:

openclaw config get agents.defaults.timeoutSeconds

openclaw config set agents.defaults.timeoutSeconds 1800 --json
openclaw gateway restart

Docs: https://docs.openclaw.ai/concepts/agent-loop (timeouts) and https://docs.openclaw.ai/gateway/troubleshooting#agent-timing-out

2) Background process / exec is hung (waiting for input, interactive prompt, etc.)

When an exec gets backgrounded, the model often goes into a process poll loop. If the underlying command is stuck (prompting, waiting for stdin, etc.), you’ll see endless process activity or a hang.

Two mitigations:

• avoid interactive commands (add --yes, CI=1, etc.)
• if you need interactivity, run exec with pty: true (so it behaves like a real terminal)

Docs: https://docs.openclaw.ai/gateway/background-process and https://docs.openclaw.ai/tools/exec

What I need to confirm which one it is