-
-
Notifications
You must be signed in to change notification settings - Fork 52.6k
Description
Problem
Kimi (Moonshot AI) local API integration via OpenClaw is unreliable and has never worked consistently as a custom provider. The user has kimi-coding configured as a custom OpenAI-compatible provider pointing at https://api.kimi.com/coding/v1, but:
Issues encountered:
-
401 auth rejections — Kimi's API rejects requests from non-whitelisted clients. It only allows known coding CLIs (Kimi CLI, Claude Code, etc.) via User-Agent sniffing. We had to add a
User-Agent: kimi-cli/1.0header hack to work around this. -
Token/JWT auth complexity — Kimi uses short-lived JWTs that auto-refresh via the Kimi CLI (
~/.kimi/credentials/kimi-code.json). The API key in openclaw.json goes stale. The env var approach$(cat ~/.kimi/credentials/kimi-code.json | jq -r '.access_token')is fragile. -
CLI backend as workaround — We set up a
cliBackends.kimientry that shells out tokimi --print -y -p, but this is a hacky workaround, not a real integration. It doesn't support streaming, tool use, or proper session management. -
Model picker confusion — When searching for 'kimi' in
/model, the user gets 296 models including dozens of Kimi variants from OpenRouter/groq/etc that aren't configured. The one that IS configured (kimi-coding/k2p5) is buried. (Separate issue filed: TUI model picker shows all 296 provider models instead of only user-configured ones #18816) -
Agent spawning fails — Spawning a Kimi sub-agent via
sessions_spawnwith the API provider consistently fails with 401s. Only the CLI backend works, and only in non-interactive mode.
What would help:
- First-class Kimi provider support in OpenClaw (like Anthropic/OpenAI have), handling JWT refresh automatically
- Or better CLI backend integration — proper streaming, tool passthrough, session support for CLI-wrapped models
- Auth profile support for providers with rotating tokens (not just static API keys)
- Provider health checks — if a configured provider is returning 401s, surface that clearly instead of silent failures
Current workaround:
User runs kimi CLI directly in terminal. The OpenClaw integration has never reliably completed a request through the agent system.
Environment
- OpenClaw with custom
kimi-codingprovider - Kimi CLI installed at
~/.local/bin/kimi - macOS, Asia/Bangkok timezone