MoonshotAI/kimi-code

Kimi Code CLI is worth a look if you want a terminal-first coding agent bound to Moonshot's Kimi models without setting up a Node toolchain; the catch is that its most distinctive features (video input, plugins, subagents, hooks) take time to evaluate and the README says little about their limits.

The problem

You want an agent that can read a repository, edit files, run shell commands, search and fetch pages, then decide its next step from tool output, all inside the terminal you already work in. The usual friction is setup: installing a runtime, managing global modules, keeping PATH sane, then configuring an API provider before the first useful prompt. Here the first step changes: you run an install script, launch kimi in the project directory, and authenticate once with /login via Kimi Code OAuth or a Moonshot AI Open Platform API key project instructions. The result is an interactive session that can start from a question like explaining the project's main directories.

What's different

The packaging is the main differentiator. It ships as a single binary, so users do not need Node.js to install it, and the project claims millisecond TUI startup project instructions. That matters for people who open and close agent sessions many times a day.

The feature set goes beyond chat-in-terminal in ways that need hands-on evaluation. Video input lets you drop in a screen recording or demo clip and have the agent work from it. /mcp-config adds, edits and authenticates Model Context Protocol servers conversationally instead of by hand-editing JSON, and a plugin marketplace installs skills, MCP servers and data sources with trust level shown up front. Built-in coder, explore and plan subagents run in isolated contexts to keep the main conversation clean, and lifecycle hooks can gate risky tool calls. ACP support means editors such as Zed and JetBrains can drive a session over stdio. The trade-off is breadth: each of these surfaces carries its own configuration and trust decisions, and the README does not detail how permissions, hooks and plugin trust interact in practice.

Who should try it

Good fit: a developer already working in Kimi models who lives in the terminal and wants editor integration through ACP without a second login. It also suits teams that want to start with the built-in subagents and grow into MCP servers and hooks later.

Poor fit: a developer whose main agent workflow already runs inside an IDE, or who needs to swap between many model providers and wants that as the primary supported path; the README presents Kimi as the out-of-box default and other compatible providers as configuration. Anyone relying on careful audit of every tool call should plan to study the interaction and approvals guide before delegating risky work.

Requirements and limitations

On macOS and Linux the official script is the simple path installer. Windows requires Git for Windows before first launch because the CLI uses bundled Git Bash as its shell; a custom Git Bash location needs KIMI_SHELL_PATH set to the absolute bash.exe path project instructions. Building from source is a separate, heavier path: Node.js ≥ 24.15.0 and pnpm 10.33.0.

Ongoing upkeep centers on authentication, provider configuration where you deviate from Kimi defaults, and the trust level of each marketplace or GitHub plugin. The configuration reference and command reference are the places to check before relying on hooks or ACP capability claims. The README's feature list is broad but does not spell out model compatibility or plugin sandboxing in detail.

HotRepo's take

HotRepo's only dated observation is 2026-10-25, when the repository had 8,008 stars and appeared on the daily board with +18 stars that day; with one recorded day, persistence of interest cannot be judged. The repository is 156 days old, so the feature set is young. Before adopting, verify in the configuration docs how provider overrides interact with the built-in Kimi default, since that determines whether the CLI fits your existing model setup.