Support Kimi Code CLI as a built-in provider

[maiconfontana]

Summary

Request to add Kimi Code CLI as an optional first-class provider in T3 Code, in the same “bring your own CLI” style as Codex / Claude / Cursor / Grok / OpenCode.

Why

Kimi Code CLI is a terminal coding agent with official ACP support (kimi acp). That matches T3’s architecture for Cursor/Grok-style adapters and would let users who already pay for / use Kimi drive it from the same web/desktop/mobile surface.

Proposed integration (high level)

• Spawn kimi acp (stdio JSON-RPC) for sessions, prompts, cancel, permissions, resume
• Auth via Kimi’s advertised ACP method (login after local /login or equivalent)
• Model catalog from ACP config options / session setup, using full ids such as:
  • kimi-code/kimi-for-coding
  • kimi-code/kimi-for-coding-highspeed
  • kimi-code/k3
  • kimi-code/k3-256k
• Surface thinking effort (low / high / max) when Kimi exposes it as a session config option
• Stream agent_message_chunk as assistant text; optionally project agent_thought_chunk into thinking UI/worklog
• Settings: binary path + enable/disable instance, same multi-instance pattern as other drivers

Scope / product fit

This would be an optional provider (no default dependency on Kimi being installed). Users without the CLI would just see the usual “not installed / not on PATH” health state.

Per CONTRIBUTING.md, this is non-trivial feature work. Opening an issue first so maintainers can accept/reject the direction before any further PR process.

Prior art / draft implementation

A full draft implementation exists on a fork and was opened as a large external PR for visibility:

• PR: feat(server): add Kimi Code CLI provider over ACP #5243

Happy to close or rewrite that PR in smaller slices if the direction is wanted (e.g. server adapter only → models/settings → web chrome → docs).

How maintainers could validate later

1. Install Kimi Code CLI and complete /login
2. Point T3 at kimi (PATH or binary path setting)
3. Start a thread, confirm models + prompt/interrupt/approvals
4. Confirm streaming behavior and thinking projection if that surface is in scope

Open questions for maintainers

1. Is Kimi in-scope as a built-in driver, or should it stay fork-only / plugin-shaped later?
2. If in-scope, preferred split for review (adapter-only first vs full surface)?
3. Any product constraints on Early Access labeling, default enable, or model defaults?