OpenRouter API calls return 500

[nocturne moon]

I have just installed my OpenClaw instance and after configuring the models it shows rather strange behavior. Were some message get sent after a while while other requrest streight up time out.
This is how it looks like in log:

2026-05-16T13:59:08.569+00:00 [agent/embedded] embedded run failover decision: runId=8c0b26a7-4fe1-4579-98a6-02fac0dc1a8f stage=assistant decision=surface_error reason=timeout from=openrouter/z-ai/glm-5.1 profile=- rawError=500 Internal Server Error

2026-05-16T13:59:08.575+00:00 [diagnostic] lane task error: lane=main durationMs=59886 error="FailoverError: HTTP 500: Internal Server Error"

2026-05-16T13:59:08.579+00:00 [diagnostic] lane task error: lane=session:agent:main:dashboard:5db00de3-403c-4bec-8d25-3fe585b9d35d durationMs=59891 error="FailoverError: HTTP 500: Internal Server Error"

2026-05-16T13:59:08.592+00:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openrouter/z-ai/glm-5.1 candidate=openrouter/z-ai/glm-5.1 reason=timeout next=none detail=500 Internal Server Error

2026-05-16T13:59:08.595+00:00 Transient HTTP provider error before reply (HTTP 500: Internal Server Error). Retrying once in 2500ms.

2026-05-16T13:59:33.844+00:00 [agent/embedded] embedded run agent end: runId=8c0b26a7-4fe1-4579-98a6-02fac0dc1a8f isError=true model=z-ai/glm-5.1 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error

[shadow falcon]

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

[median hedge]

This looks like OpenRouter/upstream model instability, not a Discord issue. The key clue is:

requested=openrouter/z-ai/glm-5.1 ... rawError=500 Internal Server Error
and then:
next=none

So OpenClaw tried that one OpenRouter model, treated the 500/timeout as transient, retried once, then had no fallback model configured.

First thing: please paste your openclaw --version so we can rule out version-specific behavior.

Then I’d check these:

openclaw models status
openclaw models status --probe
openclaw status --all

[median hedge]

Practical fixes:

1. Add at least one fallback model so a flaky OpenRouter route doesn’t kill the whole run:

openclaw models fallbacks add <provider/model>
openclaw models fallbacks list

2. If you specifically want GLM, consider using the native Z.AI provider instead of the OpenRouter route, assuming you have a Z.AI key configured. OpenRouter is a proxy, so a 500 can come from either OpenRouter or the upstream provider.

3. If you want to stay on OpenRouter, use:

openclaw models scan

to probe candidates instead of picking a route that may be slow/flaky.

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

[median hedge]

https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/help/faq-models

The timeout-ish behavior you’re seeing matches the retry/failover path: OpenClaw waits around a minute, retries once, then fails because there’s no next fallback.

[nocturne moon]

Currently running version is OpenClaw 2026.5.12. Just to be sure about OpenRouter availibility, I have tried calling their API from outside OpenClaw which worked well. After running openclaw models status --prope everything reports as OK.

[median hedge]

Thanks, that narrows it down.

Small typo check first: the command is openclaw models status --probe, not --prope. Assuming you did run --probe: a green probe means auth/basic provider reachability is OK. It does not prove that the same OpenRouter route will survive a full OpenClaw agent turn with the larger prompt, tool schemas, streaming, and model-specific request shaping.

The outside-OpenRouter test also only proves OpenRouter can answer that request. Your log is specifically failing the full OpenClaw request against:

openrouter/z-ai/glm-5.1

That can still fail if that OpenRouter route has trouble with the full agent payload or tool calling.

I’d test it in two steps:

openclaw agent --agent main --model openrouter/z-ai/glm-5.1 --message "Reply with one short sentence." --timeout 120

If that works, try a tool-ish request:

[median hedge]

openclaw agent --agent main --model openrouter/z-ai/glm-5.1 --message "What tools are available? Keep it short." --timeout 120

If the simple one works but normal chat fails, it’s likely payload/tool/schema/context related rather than OpenRouter auth.

Two practical mitigations:

• Add configured fallbacks, because your original log says next=none.
• For real OpenClaw tool use, use a model/provider that is known to handle agent/tool payloads well. For current model picks, #models is the better place; docs are here: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Relevant docs:
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/cli/agent
https://docs.openclaw.ai/providers/openrouter

[nocturne moon]

Yea, those both fail to GatewayClientRequestError: FailoverError: HTTP 500: Internal Server Error

[median hedge]

That points pretty strongly at the openrouter/z-ai/glm-5.1 route failing for OpenClaw-style chat completions, even for a tiny agent turn. Since models status --probe passes, auth is probably fine; the failing part is the actual generation request path.

Next isolation steps:

openclaw agent --agent main --model openrouter/auto --message "Reply with one short sentence." --timeout 120

Then try any other concrete OpenRouter chat model you have configured:

openclaw agent --agent main --model openrouter/<provider>/<model> --message "Reply with one short sentence." --timeout 120

If other OpenRouter models work, avoid openrouter/z-ai/glm-5.1 and add a fallback:

[median hedge]

openclaw models fallbacks add openrouter/auto
openclaw models fallbacks list

If all OpenRouter agent turns fail while probes pass, please run:

openclaw status --all
openclaw logs --since 10m

and file a GitHub issue with the redacted output plus the exact model refs tested: https://github.com/openclaw/openclaw/issues

My current read: this is not general OpenRouter availability. It is either that specific routed model returning 500 for OpenClaw’s agent request shape, or a 2026.5.12 OpenRouter-provider edge case that needs a maintainer-visible issue.

[nocturne moon]

that one throws GatewayClientRequestError: Error: Model override "openrouter/openrouter/auto" is not allowed for agent "main"

[median hedge]

Got it. That one didn’t reach OpenRouter either: it was rejected locally because the agent only allows models listed in its configured model set.

For this isolation test, don’t use openrouter/auto unless it appears in your allowed list. Pick one exact ref from:

openclaw models list --plain

Then test that exact value:

openclaw agent --agent main --model <exact-ref-from-list> --message "Reply with one short sentence." --timeout 120

If you want to allow openrouter/auto, add it to the agent’s configured models first. The docs show the shape as:

[median hedge]

{
  agents: {
    defaults: {
      models: {
        "openrouter/auto": {}
      },
      model: {
        primary: "openrouter/auto"
      }
    }
  }
}

Then restart/reload the gateway if needed and re-run:

[median hedge]

openclaw models status
openclaw agent --agent main --model openrouter/auto --message "Reply with one short sentence." --timeout 120

But the main useful next check is simpler: test any other already-allowed OpenRouter model from models list --plain. If those work and openrouter/z-ai/glm-5.1 fails, it’s that route/model. If every allowed OpenRouter model fails on openclaw agent, that’s issue-worthy with openclaw status --all and recent logs.

Docs for the allowlist/config shape: https://docs.openclaw.ai/gateway/config-agents#agentsdefaultsmodel

[nocturne moon]

After running with specific model exactly

node@90b80860ba1e:/app$ openclaw agent --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

it returned as

GatewayClientRequestError: FailoverError: HTTP 500: Internal Server Error

[median hedge]

Thanks, that’s enough to stop treating this as a single flaky model. Two different concrete OpenRouter models failing on a one-sentence openclaw agent turn means the failing path is likely OpenClaw’s OpenRouter agent-generation request path on 2026.5.12, not basic OpenRouter auth or general API availability.

One last useful split:

openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

If --local also fails with the same 500, it’s very likely provider/request-shaping rather than Gateway routing. If --local works, then it’s Gateway/runtime specific.

Either way, I’d file this now with the repro. Include:

openclaw --version
openclaw models status --probe
openclaw models list --plain

[median hedge]

openclaw status --all
openclaw logs --limit 500 --plain

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

Please redact API keys/tokens before posting logs. The minimal repro is strong:

openclaw agent --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

Workaround for now: switch the agent primary to a non-OpenRouter provider if you have one, or avoid OpenRouter for agent turns until this is fixed.

[nocturne moon]

Failed as well

16:20:56 [agent/embedded] [trace:embedded-run] startup stages: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c sessionId=39e52ca9-4b93-4100-95dd-96eebca9da6c phase=attempt-dispatch totalMs=11534 stages=workspace:1ms@1ms,runtime-plugins:10566ms@10567ms,hooks:1ms@10568ms,model-resolution:363ms@10931ms,auth:584ms@11515ms,context-engine:2ms@11517ms,attempt-dispatch:17ms@11534ms
16:21:02 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:21:06 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:21:12 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:21:22 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:21:23 [agent/embedded] embedded run failover decision: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c stage=assistant decision=fallback_model reason=timeout from=openrouter/moonshotai/kimi-k2.6 profile=- rawError=500 Internal Server Error
16:21:23 [diagnostic] lane task error: lane=main durationMs=38537 error="FailoverError: HTTP 500: Internal Server Error"
16:21:23 [diagnostic] lane task error: lane=session:agent:main:main durationMs=38550 error="FailoverError: HTTP 500: Internal Server Error"
16:21:23 [model-fallback/decision] model fallback decision: decision=candidate_failed

[median hedge]

Yep, that confirms it: --local fails too, so this is not Gateway routing. It’s the embedded provider request path to OpenRouter returning 500.

The repeated embedded run agent end lines look like retries of the same provider request, then OpenClaw classifies it as a failover-worthy timeout. Since both openrouter/z-ai/glm-5.1 and openrouter/moonshotai/kimi-k2.6 fail on a tiny prompt, this is now issue-worthy.

One optional workaround/test before filing: disable the OpenClaw tool schema surface for that model and retry. This reduces agent capability, but it tests whether OpenRouter/the route is choking on tool payloads:

openclaw config set agents.defaults.models '{"openrouter/moonshotai/kimi-k2.6":{"compat":{"supportsTools":false}}}' --strict-json --merge
openclaw gateway restart
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

If that works, mention it in the issue: “works with compat.supportsTools=false, fails with tools enabled.” That’s a very useful signal.

If it still fails, file with:

[median hedge]

openclaw --version
openclaw models status --probe
openclaw models list --plain
openclaw status --all
openclaw logs --limit 500 --plain

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

Docs for the relevant config area: https://docs.openclaw.ai/gateway/config-agents#agentsdefaultsmodel

[nocturne moon]

The config update fail as well

Error: Config validation failed: agents.defaults.models.openrouter/moonshotai/kimi-k2.6: Unrecognized key: "compat"

[median hedge]

You’re right, and that one is on me. Your 2026.5.12 config schema does not accept compat under agents.defaults.models, so don’t keep fighting that command.

Use this cleaner split instead, which avoids editing config:

openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json

If that fails with 500 too, then even the minimal OpenClaw provider call to OpenRouter is failing.

If that succeeds but openclaw agent --local ... fails, then it’s specifically the full agent request shape: system/context/tool schema/etc. That is the most useful distinction for the GitHub issue.

I’d stop trying config workarounds for now and file it with these exact results. Include the failed config validation too, because it shows the compat.supportsTools workaround is not available in your installed version/schema.

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

Relevant minimal repro set:

[median hedge]

openclaw --version
openclaw models status --probe
openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120
openclaw logs --limit 500 --plain

Redact tokens/API keys before posting logs.

[nocturne moon]

that one ran well

node@90b80860ba1e:/app$ openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json
{
  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openrouter",
  "model": "moonshotai/kimi-k2.6",
  "attempts": [],
  "outputs": [
    {
      "text": "pong",
      "mediaUrl": null
    }
  ]
}

[median hedge]

Great, that’s the clean split:

• openclaw infer model run --local ... succeeds
• openclaw agent --local ... fails

So OpenRouter auth/basic generation is fine. The failure is specific to the full agent request shape: larger system/context payload and/or tool schemas.

Try the smaller agent tool surface next:

openclaw config set agents.defaults.experimental.localModelLean true --strict-json
openclaw config validate
openclaw gateway restart
openclaw status --deep
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

[median hedge]

localModelLean removes the heaviest default tools from the prompt surface. If that makes the agent call work, it strongly suggests OpenRouter or that model route is choking on OpenClaw’s full default tool schema/payload.

If it still fails, I’d file the issue with exactly this summary:

OpenClaw 2026.5.12
OpenRouter model.run succeeds:
openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json

But embedded agent turn fails with HTTP 500:
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

Docs for the lean-mode knob: https://docs.openclaw.ai/concepts/experimental-features#local-model-lean-mode

[nocturne moon]

And here goes one more fail

16:33:07 [agent/embedded] [trace:embedded-run] startup stages: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c sessionId=39e52ca9-4b93-4100-95dd-96eebca9da6c phase=attempt-dispatch totalMs=11323 stages=workspace:2ms@2ms,runtime-plugins:10434ms@10436ms,hooks:2ms@10438ms,model-resolution:299ms@10737ms,auth:572ms@11309ms,context-engine:3ms@11312ms,attempt-dispatch:10ms@11322ms
16:33:13 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:33:17 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:33:23 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:33:33 [agent/embedded] embedded run agent end: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:33:33 [agent/embedded] embedded run failover decision: runId=39e52ca9-4b93-4100-95dd-96eebca9da6c stage=assistant decision=fallback_model reason=timeout from=openrouter/moonshotai/kimi-k2.6 profile=- rawError=500 Internal Server Error
16:33:33 [diagnostic] lane task error: lane=main durationMs=37515 error="FailoverError: HTTP 500: Internal Server Error"
16:33:33 [diagnostic] lane task error: lane=session:agent:main:main durationMs=37524 error="FailoverError: HTTP 500: Internal Server Error"

[median hedge]

That’s the final useful data point. Lean mode did not change it, while infer model run still works, so this is very likely an OpenClaw agent-request/OpenRouter compatibility bug in 2026.5.12 rather than your API key, OpenRouter account, or the specific model.

I’d stop poking it locally and file the issue now. The repro is clean enough for maintainers:

Version: OpenClaw 2026.5.12

Works:
openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json

Fails:
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

Also fails after:
openclaw config set agents.defaults.experimental.localModelLean true --strict-json
openclaw gateway restart

[median hedge]

Attach:

openclaw models status --probe
openclaw status --all
openclaw logs --limit 500 --plain

Redact tokens/API keys before posting. Issue tracker: https://github.com/openclaw/openclaw/issues

Workaround for now: use a non-OpenRouter provider for agent turns, or keep OpenRouter only for direct infer model run-style calls until this is fixed.

[nocturne moon]

Can you file that issue on github for me?

[median hedge]

I can’t file GitHub issues on behalf of users, but here’s a ready-to-paste issue body:

## Summary

OpenRouter direct model inference works, but OpenClaw embedded agent turns fail with HTTP 500 on OpenClaw 2026.5.12.

## Version

OpenClaw 2026.5.12

## Provider / models tested

- openrouter/moonshotai/kimi-k2.6
- openrouter/z-ai/glm-5.1

[median hedge]

## What works

```bash
openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json

Result:

{
  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openrouter",
  "model": "moonshotai/kimi-k2.6",
  "attempts": [],

[median hedge]

"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}

## What fails

```bash
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

Error/log excerpt:

[median hedge]

```text
embedded run agent end ... isError=true model=moonshotai/kimi-k2.6 provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
embedded run failover decision ... decision=fallback_model reason=timeout from=openrouter/moonshotai/kimi-k2.6 rawError=500 Internal Server Error
lane task error ... error="FailoverError: HTTP 500: Internal Server Error"

Additional checks

• OpenRouter API works outside OpenClaw.
• openclaw models status --probe reports OK.
• openclaw agent --agent main --model openrouter/z-ai/glm-5.1 ... also fails with HTTP 500.
• openclaw agent --agent main --model openrouter/moonshotai/kimi-k2.6 ... fails through Gateway.
• openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 ... also fails, so this does not appear to be Gateway transport.
• Tried agents.defaults.experimental.localModelLean=true; agent turn still fails.

[median hedge]

- Tried setting `agents.defaults.models["openrouter/moonshotai/kimi-k2.6"].compat.supportsTools=false`, but 2026.5.12 config validation rejected `compat` there.

## Expected behavior

If direct OpenRouter `model.run` succeeds, a minimal embedded agent turn against the same model should either succeed or return a more specific provider/request-shape error.

## Requested help

Please check whether the OpenRouter agent-generation request shape in 2026.5.12 is sending something that OpenRouter rejects with a generic 500 for these routes.

File it here: https://github.com/openclaw/openclaw/issues

Before posting, attach redacted output from:

[median hedge]

openclaw models status --probe
openclaw status --all
openclaw logs --limit 500 --plain

Make sure API keys/tokens are removed.

[nocturne moon]

What would be an ideal title for issue like that?

[median hedge]

Use this:

OpenRouter model.run succeeds but embedded agent turns fail with HTTP 500 on 2026.5.12

It’s specific, includes the useful contrast, and gives maintainers the version right in the title.

[nocturne moon]

Can you post the issue into an attached markdown file insted of that beeing directly in discord message?

[compact talon]

I was receiving this error as well. Updated to 2026.5.16-beta2 and it solved it

[median hedge]

That’s a useful data point, thanks. Sounds like this is already fixed after 2026.5.12.

For xGlc: if you’re comfortable moving to beta, try updating to 2026.5.16-beta2 and rerun the same minimal check:

openclaw --version
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

If that fixes it, please right-click obfusko’s message or the fix confirmation message → Apps → ✅ Mark Solution so Answer Overflow indexes the working version note.

[compact talon]

hmm..i may be wrong. it was working just fine for several hours but now I get the 500 errors again

[median hedge]

Thanks for correcting that. Then I’d treat this as intermittent, not solved by 2026.5.16-beta2.

The useful distinction is still:

openclaw infer model run --local --model openrouter/moonshotai/kimi-k2.6 --prompt "Reply with exactly: pong" --json
openclaw agent --local --agent main --model openrouter/moonshotai/kimi-k2.6 --message "Reply with one short sentence." --timeout 120

If infer model run works while agent --local fails, the bug report remains: OpenRouter basic generation is fine, but full agent request shape intermittently gets 500s.

For the issue, include:

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

[median hedge]

openclaw logs --limit 500 --plain

Also mention that it can work for hours and then start returning 500 again. That makes it look like either an OpenRouter/provider-side instability triggered by agent-shaped payloads, or a state/request-shape edge case in OpenClaw. Definitely don’t mark this solved yet.

[mellow ice]

I'm having the exact same issue, also use OpenRouter. Calls for sonnet 4.6 seem to always fail. Opus as well. I set my fallback to "auto" and it sometimes works, sometimes hits the same failure.

[median hedge]

Thanks, that matches the pattern from this thread. Since Sonnet/Opus through OpenRouter fail too, this is not looking model-specific anymore; it’s more likely OpenRouter + OpenClaw agent-shaped requests intermittently failing with 500s.

Useful repro to add to the issue:

openclaw --version
openclaw infer model run --local --model openrouter/anthropic/claude-sonnet-4-6 --prompt "Reply with exactly: pong" --json
openclaw agent --local --agent main --model openrouter/anthropic/claude-sonnet-4-6 --message "Reply with one short sentence." --timeout 120
openclaw models status --probe
openclaw logs --limit 500 --plain

If infer model run succeeds but agent --local fails, that’s the same core signal: basic OpenRouter generation works, full OpenClaw agent turn fails. Please redact tokens/API keys before posting logs.

Workaround-wise, openrouter/auto being flaky makes sense here: it may route to a backend that accepts the request shape sometimes, then another that 500s later. A non-OpenRouter provider is probably the only reliable workaround until this gets fixed or narrowed down upstream.

[mellow ice]

It looks like the model it's routing me to almost every time is gpt-oss-120b, sometimes works, sometimes doesn't

[median hedge]

That’s a strong clue. If openrouter/auto is usually landing on gpt-oss-120b, then auto is not really a reliability fallback here; it’s mostly sending you back to the same flaky route.

I’d avoid openrouter/auto for the fallback chain and pin explicit OpenRouter models that you have actually tested with:

openclaw infer model run --local --model <exact-openrouter-ref> --prompt "Reply with exactly: pong" --json
openclaw agent --local --agent main --model <exact-openrouter-ref> --message "Reply with one short sentence." --timeout 120

Only add a model to fallbacks if both pass consistently:

openclaw models fallbacks add <exact-openrouter-ref>
openclaw models fallbacks list

For the issue, mention that openrouter/auto commonly routes to gpt-oss-120b and that route is intermittent. That may help distinguish “OpenRouter auto picked a bad upstream” from “all OpenRouter agent requests fail.”

[arctic drift]

Oh I have this also and have bene beating the crap out of myself about it for days! https://discord.com/channels/1456350064065904867/1505282237342683156

[median hedge]

Yeah, at this point it’s pretty clearly not “you configured something silly.” Multiple people are seeing the same OpenRouter 500 pattern.

Best signal to add to the GitHub issue/thread is the same split test:

openclaw --version
openclaw infer model run --local --model <your-openrouter-model> --prompt "Reply with exactly: pong" --json
openclaw agent --local --agent main --model <your-openrouter-model> --message "Reply with one short sentence." --timeout 120
openclaw logs --limit 500 --plain

If infer model run works but agent --local fails, that’s the useful repro: basic OpenRouter generation works, OpenClaw’s full agent-shaped request gets 500s. Redact tokens/API keys before posting logs.

And yeah, please don’t keep burning days on it locally. The evidence now points to an OpenRouter/OpenClaw agent request compatibility or upstream routing issue, not user error.

[mellow ice]

I've seen posts on Reddit claiming it's an OpenRouter issue, but I honestly don't think it is. My OpenClaw was like a month behind in updates (I can look up exact version if needed) and was fine. The instant I moved to 2026.5.12 last night, my problem started.

[median hedge]

That’s actually a very useful clue. If it was stable on an older OpenClaw and started immediately after moving to 2026.5.12, then yes, this should be framed as a likely OpenClaw regression or request-shape change, not just “OpenRouter is down.”

If you can find the exact previous version, add it to the issue as:

Regression signal:
- Worked on: OpenClaw <old version>
- Started failing after upgrade to: OpenClaw 2026.5.12
- Same OpenRouter account/key/models

Even an approximate “worked on a late April / early May build” is useful, but exact is better.

The strongest repro remains:

[median hedge]

openclaw infer model run --local --model <openrouter-model> --prompt "Reply with exactly: pong" --json
openclaw agent --local --agent main --model <openrouter-model> --message "Reply with one short sentence." --timeout 120

If the first succeeds and the second fails after the upgrade, that points at something OpenClaw changed in agent request construction, tool schema, provider wrapping, or retry/failover handling.

[mellow ice]

I was on 2026.4.22

[median hedge]

Perfect, that’s exactly the kind of regression marker maintainers need.

Add this near the top of the issue:

Regression:
OpenRouter agent turns worked on OpenClaw 2026.4.22.
After upgrading to OpenClaw 2026.5.12, the same OpenRouter account/models started failing with HTTP 500 during agent turns.
Direct model inference still works:
openclaw infer model run --local --model <model> --prompt "Reply with exactly: pong" --json

That narrows the suspect window a lot: changes between 2026.4.22 and 2026.5.12, especially OpenRouter provider wrapping, OpenAI-compatible request shaping, tool schema payloads, or agent runtime construction.

[arctic drift]

I had the problem 1-2 days before upgrade, whatever the previous official release had been.

[mellow ice]

When I did the upgrade and it all started failing, I assumed it was that I jumped too many versions at once and missed some incremental change that was needed, so I full uninstalled/reinstalled today and copied my workspace back in and instantly went back to issue.

[arctic drift]

it worked before you added your custom stuff back?

[mellow ice]

For the like 3 messages I sent it, yeah. I did basic onboarding and made sure basics were there (it was on openrouter/auto at the time), then I copied my workspace in and updated the openclaw.config to what I actually want to use and instant died.

[arctic drift]

Yeah that's been my experience that I can make it work for 1-2 queries only. I'd not tried swapping workspace out. I did wipe the model & auth config and set that back up fresh (as noted in the thread I posted above). But that did not help. I was going to do new workspace next but now that I know others having same problem, I don't think I'll bother.

If you enable input/output logging in openrouter (https://openrouter.ai/workspaces/default/observability), and then look at the logs (https://openrouter.ai/logs), you'll see the "unsuccessful" queries are all seen and to some extent, acted on by openrouter. But something changed x days ago, which seems to break some, but not all of us.

[wintry shale]

Tested yesterday: regression appears after upgrading to 2026.5.12; works fine on 2026.5.7.

Regression:
OpenRouter agent turns worked on OpenClaw 2026.5.7.
After upgrading to OpenClaw 2026.5.12, the same OpenRouter account/models started failing with HTTP 500 during agent turns.
Direct model inference still works:
openclaw infer model run --local --model <model> --prompt "Reply with exactly: pong" --json

Suspect window: changes between 2026.5.7 → 2026.5.12, likely OpenRouter wrapping, OpenAI request shaping, tool schema, or agent runtime.

[median hedge]

I checked the current source/docs and this does look like a real OpenClaw regression, not an OpenRouter auth/model problem.

The key signal is: openclaw infer model run --local ... works, but full agent turns fail. That points away from the API key/model and toward the agent request shape: messages + tool schemas + streaming transport.

Between v2026.5.7 and v2026.5.12, the suspicious changes I found are:

• 325d9ca7cb - “add strict OpenAI-compatible message key mode”
• 798ba972ea - “normalize array tool schemas”
• a large OpenAI-compatible transport/debugging change around openai-transport-stream.ts

For now I’d treat 2026.5.7 as the practical workaround if OpenRouter is your main provider. If someone can reproduce on 2026.5.12, the most useful next artifact is a redacted agent payload/log comparison, not another auth reset.

Useful repro bundle:

openclaw --version
openclaw status --all
OPENCLAW_DEBUG_MODEL_PAYLOAD=summary OPENCLAW_DEBUG_MODEL_TRANSPORT=1 openclaw logs --follow