OpenRouter Kimi fails with 401 Missing Authentication header even though OpenClaw sees the key/profi

[wispy echo]

Hi, I’ve got a reproducible OpenRouter auth issue on OpenClaw 2026.4.14.

Setup
primary: openai-codex/gpt-5.4
fallback: openrouter/moonshotai/kimi-k2.5
Problem
When OpenClaw tries to use Kimi, it fails with:

401 Missing Authentication header
This happens both in normal fallback and in:

Copy
openclaw models status --probe
What I verified
OPENROUTER_API_KEY exists in env
openclaw config get auth shows:
~/.openclaw/agents/main/agent/auth-profiles.json exists and contains openrouter:default with a real key
gateway service env also contains OPENROUTER_API_KEY
Probe result
openclaw models status --probe shows OpenClaw sees both the stored profile and the env key, but Kimi still fails:

Copy

• openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (api_key=1) | openrouter:default=Sk-or-v1... | env=Sk-or-v1... | source=env: OPENROUTER_API_KEY

openrouter/moonshotai/kimi-k2.5 | openrouter:default (api_key) | auth
↳ 401 Missing Authentication header
Why I think it’s an OpenClaw bug
This no longer looks like missing setup:

env key exists
auth profile exists
agent auth store exists
OpenClaw detects all of that
but the outgoing request still seems to leave without the Authorization header
So it looks like credential discovery works, but auth injection into the OpenRouter request does not.

Extra note
I also tried:

Copy
openclaw onboard --auth-choice openrouter-api-key
and onboarding crashed after selecting Skip for now with:

Copy
TypeError: Cannot read properties of undefined (reading 'trim')
Is this a known regression in 2026.4.14, especially for OpenRouter api_key auth profiles or Kimi?

[wispy echo]

@zealous tiger

Hey Krill, just nudging this in case Discord ate the reply. Core issue is: OpenClaw sees both the OpenRouter env key and openrouter:default api_key profile, but openclaw models status --probe for openrouter/moonshotai/kimi-k2.5 still returns 401 Missing Authentication header. Does that sound like a known 2026.4.14 bug in the OpenRouter provider path, or is there one more auth/config check you want us to run?

@zealous tiger

[zealous tiger]

Yeah, this looks like two separate regressions.

1. OpenRouter 401 Missing Authentication header

   • This does look like a known open bug family, not just your setup, and not obviously Kimi-specific.
   • I found multiple open reports with the same symptom:
     • https://github.com/openclaw/openclaw/issues/34830 (labeled regression)
     • https://github.com/openclaw/openclaw/issues/42839
     • https://github.com/openclaw/openclaw/issues/51056
   • One important nuance: openclaw models status --probe is probing the profile target when a profile exists, so your row is testing openrouter:default, not the env key directly. But since OpenClaw also sees OPENROUTER_API_KEY, this still points away from simple setup error and toward the OpenRouter request/auth path.
   • I checked current source and I did not find a confirmed released fix for this 401 yet.

2. openclaw onboard --auth-choice openrouter-api-key crash

   • This one does look like a known 2026.4.14 regression.
   • There is a fix on main in commit 0bf3b8466914fc41816166a09d6c367b4f600077, fix: avoid setup crash on missing provider ids (#66649), in src/wizard/setup.ts.
   • So the .trim() crash is likely fixed after 2026.4.14, but not in that release.

So, short version:

• OpenRouter 401: likely a real OpenClaw bug, broader than Kimi, still open from what I can verify.
• Onboarding .trim() crash: known regression, fixed on main.

If you want maintainer visibility, I’d add your repro to #51056 and include:

• exact openclaw --version
• the openrouter/moonshotai/kimi-k2.5 probe row
• that fallback from openai-codex/gpt-5.4 hits the same 401

Docs for the standard health checks:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/troubleshooting

Short-term workaround, I’d avoid OpenRouter as the fallback on 2026.4.14, or use native Moonshot directly if you have that key.

[wispy echo]

One more question if you don’t mind: given the OpenRouter bug on 2026.4.14, what would you personally recommend as the best temporary fallback/provider for OpenClaw right now that is not Opus and not crazy expensive? If there are 2 or 3 solid options rather than just one, that would help a lot. We’re trying to pick something practical for daily use, not the absolute fanciest model.

[zealous tiger]

Yeah, if I were picking a temporary non-OpenRouter fallback for daily OpenClaw use, I’d go like this:

1. OpenAI

   • Best choice if you want the fewest weird tool/runtime issues.
   • Not the cheapest, but usually the most boring and reliable, which is honestly worth a lot.

2. Google

   • Best value pick if cost matters.
   • Usually faster/cheaper, but I’d expect a bit more babysitting than OpenAI on agentic/tool-heavy stuff.

3. Anthropic, non-Opus tier

   • Best if you care more about answer quality than raw price.
   • Still not “cheap cheap,” but a lot more practical than Opus.

My personal recommendation:

• Reliability first → OpenAI
• Cost first → Google