Feature: Add Kimi Coding Provider Support

[traceless929]

Is your feature request related to a problem?

PicoClaw currently only supports Moonshot provider (api.moonshot.cn/v1) for Kimi models. However, Kimi Code Plan uses a separate endpoint (api.kimi.com/coding/v1) with different API keys and potentially different capabilities.

Proposed Solution

Add a dedicated kimi-coding provider:

Config	Value
Provider name	kimi-coding
Endpoint	https://api.kimi.com/coding/v1
API Key env	KIMI_API_KEY or PICOCLAW_PROVIDERS_KIMI_CODING_API_KEY
Model ref format	kimi-coding/k2p5

Configuration Example

{
  "providers": {
    "kimi-coding": {
      "api_key": "sk-xxx",
      "api_base": "https://api.kimi.com/coding/v1"
    }
  },
  "agents": {
    "defaults": {
      "model": "kimi-coding/k2p5"
    }
  }
}

Alternatives Considered

Tried overriding MOONSHOT_API_BASE to Kimi Coding endpoint, but compatibility is uncertain due to potential differences in API behavior and model IDs.

References

• OpenClaw Kimi Coding docs: https://github.com/openclaw/openclaw/blob/main/docs/providers/moonshot.md
• Kimi Code CLI: https://github.com/MoonshotAI/kimi-cli
• Kimi Code API endpoint: https://api.kimi.com/coding/v1

Use Case

Users who have Kimi Code Plan subscription want to use PicoClaw with Kimi Coding API instead of Moonshot API, leveraging Kimi Code's search and fetch capabilities.

[nikolasdehor]

The good news is that PicoClaw's OpenAI-compatible provider (pkg/providers/openai_compat/provider.go) should already work with Kimi Coding's endpoint since it follows the OpenAI v1/chat/completions format.

You can configure it today using the existing model_list approach in config.json:

{
  "model_list": [
    {
      "model_name": "kimi-k2p5",
      "model": "k2p5",
      "api_base": "https://api.kimi.com/coding/v1",
      "api_key": "sk-xxx"
    }
  ],
  "agents": {
    "defaults": {
      "model": "kimi-k2p5"
    }
  }
}

This is resolved by pkg/providers/factory.go which builds an openai_compat provider from model_list entries with custom api_base. No dedicated provider implementation is needed as long as the Kimi Coding endpoint is OpenAI-compatible.

If there are differences in the API format (non-standard fields, different auth headers, etc.), then a dedicated provider might be warranted — but I'd suggest trying the model_list approach first and reporting any incompatibilities.

The MOONSHOT_API_BASE override approach you mentioned wouldn't work cleanly because it would also affect regular Moonshot models. Using model_list entries with distinct api_base values keeps them properly isolated.

[sipeed-bot]

@traceless929 Hi! This issue has had no activity for over 2 weeks, so I'm closing it for now to keep things tidy. If it's still relevant, feel free to reopen it anytime and we'll pick it back up.