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-codingkimi-code/kimi-for-coding-highspeedkimi-code/k3kimi-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:
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
- Install Kimi Code CLI and complete
/login
- Point T3 at
kimi (PATH or binary path setting)
- Start a thread, confirm models + prompt/interrupt/approvals
- Confirm streaming behavior and thinking projection if that surface is in scope
Open questions for maintainers
- Is Kimi in-scope as a built-in driver, or should it stay fork-only / plugin-shaped later?
- If in-scope, preferred split for review (adapter-only first vs full surface)?
- Any product constraints on Early Access labeling, default enable, or model defaults?
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)
kimi acp(stdio JSON-RPC) for sessions, prompts, cancel, permissions, resumeloginafter local/loginor equivalent)kimi-code/kimi-for-codingkimi-code/kimi-for-coding-highspeedkimi-code/k3kimi-code/k3-256klow/high/max) when Kimi exposes it as a session config optionagent_message_chunkas assistant text; optionally projectagent_thought_chunkinto thinking UI/worklogScope / 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:
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
/loginkimi(PATH or binary path setting)Open questions for maintainers