Skip to content

Kimi (Moonshot) local API integration unreliable — needs first-class provider support #18822

@fwends

Description

@fwends

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:

  1. 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.0 header hack to work around this.

  2. 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.

  3. CLI backend as workaround — We set up a cliBackends.kimi entry that shells out to kimi --print -y -p, but this is a hacky workaround, not a real integration. It doesn't support streaming, tool use, or proper session management.

  4. 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)

  5. Agent spawning fails — Spawning a Kimi sub-agent via sessions_spawn with 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-coding provider
  • Kimi CLI installed at ~/.local/bin/kimi
  • macOS, Asia/Bangkok timezone

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions