Kimi CLI: a terminal coding agent that is being wound down in favour of Kimi Code CLI

What Kimi CLI does, and the wind-down notice sitting above it

Kimi CLI is an AI agent that runs in the terminal. The README describes it as helping with software development tasks and terminal operations: it can read and edit code, execute shell commands, search and fetch web pages, and plan and adjust actions while it runs. That is the same promise every terminal coding agent makes, so the differentiating details are elsewhere: a shell command mode toggled with `Ctrl-X`, an Agent Client Protocol server, MCP tool support, and a Zsh plugin.

The first thing a reader sees in the README is a notice, not a feature list. It states that Kimi CLI is evolving into Kimi Code CLI, that installing Kimi Code CLI automatically migrates configuration and sessions, and that this project will be gradually wound down while the docs and existing installations remain available. The repository is not archived and the last push was on 2026-07-16, which is roughly two months before the date of writing. So the code is not abandoned, but the direction of travel is stated by the maintainers themselves. Anyone choosing between the two should read that notice as the primary fact about the project, not as a footnote.

How the agent is put together: Python 3.12, a workspace of packages, and an ACP server

The package metadata tells you more about the architecture than the README does. `pyproject.toml` declares `requires-python = ">=3.12"` and pins almost every dependency to an exact version: `agent-client-protocol==0.8.0`, `typer==0.21.1`, `prompt-toolkit==3.0.52`, `rich==14.2.0`, `fastmcp==3.2.4`, `pydantic==2.12.5`, `trafilatura==2.0.0` with `lxml==6.0.2`, and `httpx[socks]==0.28.1`. There is a conditional dependency, `batrachian-toad==0.5.23; python_version >= "3.14"`, and a comment explaining that `loguru` is held below 0.8 because that package caps it at `<=0.6.0` on 3.14 and above. That comment is a useful signal: the maintainers are tracking interpreter-version breakage in public.

The project is a uv workspace, not a single package. `[tool.uv.workspace]` lists `packages/kosong`, `packages/kaos`, `packages/kimi-code` and `sdks/kimi-sdk`, and the Makefile has separate test targets for `test-kimi-cli`, `test-kosong` and `test-pykaos`. The build backend is `uv_build`. The dependency list also includes `fastapi`, `uvicorn[standard]`, `scalar-fastapi` and `websockets`, and the Makefile exposes `make web-back`, which starts a web backend with `uvicorn kimi_cli.web.app:create_app --factory --reload --port 5494`, plus `make vis-back` on port 5495. So the terminal agent ships with a web surface and a separate visualisation surface, both part of the same repository.

The ACP path is the one most likely to matter to an editor user. The README says to run Kimi CLI in the terminal and send `/login` first, then configure the editor to start `kimi acp` as an agent server. For Zed the configuration goes in `~/.config/zed/settings.json`; for JetBrains it goes in `~/.jetbrains/acp.json`.

Installing Kimi CLI and a first real session

The README does not carry install commands. It points to a Getting Started page in the documentation, and the badges show a PyPI package named `kimi-cli`. The repository's own development instructions start from a clone and `make prepare`, which is the contributor path rather than the user path. If you are installing as a user, follow the Getting Started page; the commands below are the developer path the README does document.

Cloning and preparing the development environment is the sequence the README gives. `make prepare` depends on `download-deps` and `install-prek`, and the Makefile shows it syncing every workspace package with `uv sync --frozen --all-extras --all-packages`.

git clone https://github.com/MoonshotAI/kimi-cli.git
cd kimi-cli
make prepare

After that, the README says to run the CLI through uv. This is the command you use while working on the project, and it starts the terminal agent against your checkout.

uv run kimi

A first real use that exercises a feature rather than the chat loop is MCP. The README gives a streamable HTTP example with an API key header, and the same sub-command group handles stdio servers and OAuth. Adding a server writes it into your configuration; `kimi mcp list` should then show it.

kimi mcp add --transport http context7 https://mcp.context7.com/mcp --header "CONTEXT7_API_KEY: ctx7sk-your-key"
kimi mcp list

If you would rather not persist a server, the README documents an ad-hoc option that takes a well-known MCP config file. The file uses the standard `mcpServers` key, and the CLI flag is `--mcp-config-file`.

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp",
      "headers": {
        "CONTEXT7_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

kimi --mcp-config-file /path/to/mcp.json

For editor use, the README's Zed example starts `kimi` with the single argument `acp` and an empty `env` object. Note the ordering constraint: the README says to complete `/login` in the terminal before pointing an ACP client at the server.

Where it gets in the way: shell mode gaps, the migration, and the licence

The shell command mode has a documented hole. The README states that built-in shell commands like `cd` are not supported yet. For an agent that advertises itself as both a coding agent and a shell, that is a real limitation rather than a nicety: you cannot change directory from inside the mode, so any workflow that depends on moving around the filesystem has to leave it. The README does not document rollback for the migration to Kimi Code CLI either, which is the more consequential gap. It says configuration and sessions are migrated automatically when you install Kimi Code CLI. It does not say what happens to an existing Kimi CLI installation afterwards, or how to reverse the migration.

The dependency pinning is a second practical constraint. Exact pins on `aiohttp`, `pydantic`, `fastmcp`, `lxml` and others mean the project is reproducible, but they also mean the package will not resolve against a newer version of a shared library in your environment without an override. The `loguru` comment shows the maintainers are already working around a transitive cap. If you vendor this into a larger Python environment, expect to reconcile pins.

The licence is Apache-2.0, and the repository carries a `NOTICE` file alongside `LICENSE`. Apache-2.0 includes an explicit patent grant and requires that notices be preserved; if you redistribute a modified build, the NOTICE file is part of what you carry. That is a description of the licence text, not legal advice, and a project that is being wound down raises a separate question the licence does not answer: for how long the pinned dependencies will keep receiving bumps.

Kimi CLI versus Claude Code and Codex: the difference is the protocol surface

The searches that bring people here are comparisons: kimi cli vs claude code, kimi cli vs codex. The honest answer from the repository's own documentation is that the three overlap heavily on the core loop. All of them read and edit code and run commands from a terminal. What distinguishes Kimi CLI in its own documentation is the protocol surface rather than the agent loop.

ACP support is the clearest example. The README says Kimi CLI supports the Agent Client Protocol out of the box and can be used with any ACP-compatible editor or IDE, with Zed and JetBrains given as worked configurations. That is a different integration strategy from a vendor-specific extension: the editor talks to a generic agent server, and the agent is one process you can also run by hand. The VS Code path goes the other way, through a published extension named `moonshot-ai.kimi-code`.

The second difference is packaging. Kimi CLI is a Python package with an exact-pinned dependency tree and a uv workspace containing `kosong`, `kaos` and `kimi-sdk`. That matters if you want to embed or extend it, and it matters against it if you want a single static binary on a machine without a Python 3.12 runtime. The README does document `make build-bin` for a standalone binary, so the option exists, but it is a build target rather than the default install path.

Who should install it, and what to check before you do

Adopt Kimi CLI if you specifically want an ACP agent server you can point an editor at, or you want to manage MCP servers from a sub-command group rather than hand-editing a config file, and you are comfortable running a Python 3.12 toolchain with pinned dependencies. The MCP sub-command group is genuinely convenient: `kimi mcp add`, `kimi mcp list`, `kimi mcp remove` and `kimi mcp auth` cover the lifecycle, including OAuth, which is more than many agents expose on the command line.

Do not adopt it if you are starting fresh and have no reason to prefer this package over its successor. The README is explicit that Kimi CLI is evolving into Kimi Code CLI and will be gradually wound down, and that installing the successor migrates configuration and sessions. Choosing the older package to avoid a migration is choosing the migration later, with less documentation around it. Likewise, skip it if your workflow depends on `cd` inside the agent's shell mode, or if you need a stable single binary on a host where you cannot control the Python version.

Before installing, verify three things. First, confirm from the Getting Started page which install path applies to your platform, since the README itself does not carry install commands and the Windows installation path is not documented in the repository files. Second, if you plan to use ACP, confirm your editor accepts a custom agent server entry and that `/login` has been completed in the terminal first. Third, check that the MCP servers you intend to add are reachable from the machine running the agent, because the HTTP transport examples point at remote endpoints.

Editorial conclusion

Install Kimi CLI only if you need the ACP or MCP surface it already exposes and you accept that the README describes the project as being gradually wound down. New users should install Kimi Code CLI instead, since the README states that doing so migrates configuration and sessions automatically. Before committing, verify which package your platform resolves, whether your editor's ACP client accepts the kimi acp command as configured, and whether the MCP servers you depend on are reachable from the machine that runs the agent.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes