Feature request: first-class Kimi support — kimi-cli provider (reuse Kimi Code login) + official Kimi/Moonshot recipe

[StarChen-Cycler]

Motivation

Kimi/Moonshot is one of the most common vision-capable providers for Chinese users, but the only path today is the generic openai provider, and users who already pay for Kimi Code (the agentic CLI, installed and signed in) cannot reuse that login the way claude-cli / codex / opencode / pi / grok reuse works. #19 asked how to use kimi-k2.5; the answer there was dsh-side modality config or the families workaround. This request is about making Kimi a first-class citizen instead.

Part A — kimi-cli provider (reuse Kimi Code subscription login)

Kimi Code CLI facts (observed on a signed-in Windows install):

• binary: kimi (a real .exe on Windows, so no .cmd spawn issue like Windows 下 claude-cli 提供方无法启动（spawn EINVAL / claude not found） #31/Windows: claude-cli fallback and opencode reuse probing fail with spawn EINVAL (.CMD shims) #43)
• config ~/.kimi/config.toml declares:
  [providers."managed:kimi-code"] with type = "kimi", base_url = "https://api.kimi.com/coding/v1", OAuth token stored at ~/.kimi/credentials/kimi-code.json (file storage)
• its model (kimi-for-coding, display name "K2.7 Code") declares capabilities ["video_in", "thinking", "image_in"] — image input is available

Mirroring the claude-cli provider shape (spawn the CLI, one-shot "read this image" turn) would give subscribed users a zero-key path, and kimi could join the reuse harness list (reuse.kimi) alongside the existing ones.

Part B — official Kimi/Moonshot recipe for the openai provider

Worth a section in references/configure.md:

• baseUrl: https://api.moonshot.cn/v1 (China) / https://api.moonshot.ai/v1 (global)
• vision-capable models: kimi-k3, kimi-k2.7-code / kimi-k2.7-code-highspeed, kimi-k2.6, kimi-k2.5, moonshot-v1-{8k,32k,128k}-vision-preview
• constraints worth documenting: URL-format images are unsupported (base64 only — modlens already inlines base64, so this works); SVG input rejected; thinking knobs per model: k2.5/k2.6 accept thinking.type: "disabled", k2.7-code always thinks (cannot be disabled), k3 uses top-level reasoning_effort

Part C — benchmark data (one test image, multiple runs, 3.16.4, api.moonshot.cn)

model	wall time	reasoning tokens	stability
kimi-k2.7-code-highspeed	3.9–6.9s	92–467	⚠️ occasionally truncates JSON (~1/6 runs; persists with max_tokens: 8192)
moonshot-v1-32k-vision-preview	5.5–7.2s	0	✅ 9/9
moonshot-v1-128k-vision-preview	~6.5s	0	✅
moonshot-v1-8k-vision-preview	~6.6s	0	✅
kimi-k2.7-code	~15.3s	151	✅
kimi-k2.5	~27s	926	✅
kimi-k3	~39s	729	✅
kimi-k2.6	~43s	1169	✅
kimi-k2.6 + thinking.type: disabled	~13s	—	❌ 3/3 non-JSON output

Suggestion for the recipe's recommended default: moonshot-v1-32k-vision-preview (fastest of the stable set, zero reasoning tokens), with a note about the highspeed variant's truncation caveat.