Title card reading Kimi K3.1 Pro in Kimi Code CLI with the subhead install, login, and the Windows trap, and three stat chips reading one install command, one login screen, one PATH entry
Guides & Insights

Getting Kimi K3.1 Pro into Kimi Code CLI: Install, Login, and the Windows Trap

Author

Rowan Sterling

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

Kimi Code CLI is Moonshot's terminal coding agent, and it is the one client where Kimi K3.1 Pro is not a third-party integration but the default. The setup is shorter than the Claude Code or Codex routes — one install script, one /login, one platform choice — because the client and the model come from the same company. The catch is platform-specific: on Windows, the CLI runs inside the Git Bash it bundles, and if that shell is not where the installer expects it, the tool starts and then fails in ways that look like model errors.

This is the sequence that works, checked against Moonshot's documentation on 24 October 2026, with the failure modes called out where they actually occur.

Card headed Three steps to a working session with three numbered rows: install with one script and no runtime, login with /login and choose the API-key platform, and run by opening the project and picking the model, with a note to install Git for Windows first

Install

macOS and Linux take one line: curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash. Windows PowerShell takes one line as well: irm https://code.kimi.com/kimi-code/install.ps1 | iex. The script downloads the latest release, verifies its checksum, and puts the kimi executable on your PATH. No Node.js or Python runtime is required.

Windows has one prerequisite that is easy to miss: install Git for Windows first. Kimi Code CLI uses the bundled Git Bash as its shell environment. If Git Bash lives somewhere non-standard, set the KIMI_SHELL_PATH environment variable to the absolute path of bash.exe before launching — otherwise the agent starts but every shell command it tries to run fails.

Log in with an API key

Start the CLI inside the project directory you want to work in:

• Run kimi to open the interactive interface.

• Type /login. Kimi Code CLI opens a platform selector.

• Choose Kimi Platform (API key · platform.kimi.ai). This is the option for a key created on the open platform; the others correspond to different account surfaces.

• Paste the key. Create one at platform.kimi.ai under API Keys if you do not have it. The CLI stores it locally, so treat the config directory like a credential store.

That is the whole connection. The model selector inside the CLI lists the current Kimi models, and Kimi K3.1 Pro and its high-speed variant are the two that matter for agentic work.

Switching an existing setup, and replacing a key

Two migrations are common, and both go through the same screen. If Kimi Code CLI is already logged in through a subscription rather than an API key, running /login again and selecting the API-key platform switches it without reinstalling. If you are rotating a key — because it leaked, or because a project needs its own billing — the same flow replaces the stored credential.

The one thing not to do is edit the stored config by hand while the CLI is running; the process reads credentials at startup and a mid-session edit is overwritten on exit.

What the agent actually does

Kimi Code CLI is not a chat window in a terminal. It reads and edits code, searches the repository, runs commands and reads the results, and can pull in web content or search when a task needs something outside the project. Moonshot describes it as a coding agent that runs on your own machine with the model doing the planning — the same shape as Claude Code or Codex, with the same implications for permissions: an agent that can run shell commands should be started in a directory you are willing to let it modify, and reviewed before anything is pushed.

Two billing models meet in this client. The Kimi Code app is sold as a subscription with plan tiers, and the CLI can use that subscription or an API key from the open platform. The API-key path is the one that gives you the per-token economics — $2.00 and $10.00 per million tokens for K3.1 Pro, $4.00 and $20.00 for the high-speed variant — while the subscription is a flat fee with quota. For a team already paying for API usage elsewhere, the key path keeps the spend in one place; for an individual who codes all day, the subscription is usually cheaper and the CLI is the same download either way.

Picking the model and the effort

Kimi K3.1 Pro always reasons, and effort is set with a top-level field that accepts low, high and max, defaulting to max. Kimi Code CLI exposes the model; the effort default is the expensive one, so a session that feels slow is usually a session running at max rather than a broken connection. The high-speed variant trades latency for price — $4.00 and $20.00 per million tokens instead of $2.00 and $10.00 — and is the sensible default for interactive work where the model is waiting on a human anyway.

Two constraints follow the model into any client: sampling parameters are fixed (temperature 1.0, top-p 0.95, n at 1), and changing effort mid-conversation invalidates prefix-cache hits. Decide the level at the start of a session.

Kimi Code product page describing Kimi Code as an AI coding agent and CLI tool available on desktop, terminal and IDE plugins, titled Kimi Code with Kimi K3

How this route compares to Claude Code and Codex

The three clients use three different protocols to reach the same model, and the choice is mostly about which interface your team already lives in. Kimi Code CLI is the least configuration: no environment block, no TOML file, and the vendor maintains both ends. Claude Code needs the Anthropic-compatible endpoint and four model-tier variables set correctly, and Codex needs a provider block with wire_api = "responses", but both then work against any provider that speaks those protocols — including a gateway that also serves other vendors' models.

The practical split: use Kimi Code CLI when Kimi is the only model you need and you want the shortest path; use Claude Code or Codex when the same session has to switch between vendors, or when your team's tooling, permissions and skills already live in those clients.

Kimi Code CLI getting-started documentation page showing the install and login instructions for the terminal agent

A troubleshooting order that saves time

• The CLI starts but no shell command runs — check Git Bash and KIMI_SHELL_PATH first, before blaming the model.

• Authentication errors after a working setup — re-run /login and confirm the platform option matches where the key was created; keys from different surfaces are not interchangeable.

• Sessions that feel slow — check the effort default before changing models; max is expensive in both latency and tokens.

• Model-not-found after an update — the CLI lists what the platform serves; if K3.1 Pro is missing, the client is pointed at a surface that has not been updated.

Kimi K3.1 Pro on the platform is $2.00 per million input tokens and $10.00 per million output, with a 1M-token context and up to 943,718 output tokens. If you would rather reach it through the API your other tools already use, OrcaRouter serves the same model as kimi/kimi-k3.1-pro at the provider's list price with no markup added — the config for that route is covered in the Claude Code and Codex guide.