[branding] "Kimi CLI" → "Kimi Code" migration is half-done — downstream references are wildly inconsistent across the ecosystem

[counterfactual5]

中文摘要：Kimi CLI → Kimi Code 的品牌迁移只做了一半。仓库描述、README、Zed 扩展、VS Code 扩展、SDK、二进制路径、PyPI 包名各跑各的，至少四套名字同时在生态里。#2376 已经处理了文档站的 banner，但其他下游出口全部未跟进。这个 issue 用作 tracking，把整个生态的命名分裂一次性列清楚。

Background

#2381 raised the strategic concern about the kimi-cli / kimi-code split. This issue focuses on a narrower, actionable engineering problem: the rebrand execution is only half done, and downstream references across the ecosystem are wildly out of sync.

Concrete evidence:

• MoonshotAI/kimi-cli repo description says "Kimi Code CLI is your next CLI agent."
• But README title is still # Kimi CLI
• README has an IMPORTANT banner: "Kimi CLI is evolving into Kimi Code CLI... This project will be gradually wound down"
• Meanwhile the CHANGELOG is still being actively updated (latest commits 2026-07-01) — no sign of actual wind-down
• [Docs] Add deprecation banner on GitHub Pages: redirect users to kimi-code (TypeScript rewrite) #2376 already fixed the GitHub Pages deprecation banner, but every other downstream surface was left untouched
• VS Code extension on the marketplace is already moonshot-ai.kimi-code (Kimi Code), but the Zed extension from the same team is still "Kimi CLI" — two IDE surfaces don't even agree with each other

Inconsistency inventory

Surface	Current	Status
kimi-cli repo description	Kimi Code CLI	✅ done
kimi-cli README title	# Kimi CLI	❌
kimi-cli README ACP config example	"Kimi CLI" as agent_servers key, kimi acp	❌ unclear if command survives the rebrand
kimi-code-zed-extension extension.toml	id="kimi-cli", name="Kimi CLI"	❌ repo dir name is kimi-code, content is kimi-cli
kimi-code-zed-extension README	"Kimi CLI Zed Extension"	❌
zsh-kimi-cli repo	zsh-kimi-cli	❌
kimi-agent-sdk description	"...interact with the Kimi CLI"	❌
kimi-agent-rs description	"Kimi Code CLI Wire mode-compatible"	✅ done (but inconsistent with SDK)
VS Code extension (marketplace)	Kimi Code	✅ done
PyPI package	kimi-cli and kimi-code coexist, with kimi-code depending on kimi-cli; PyPI version is also stale (#1219)	❌ messy
Binary / command	Binary is still named kimi, but install path moved from ~/.kimi/ to ~/.kimi-code/bin/; release artifact renamed from kimi-X.Y.Z-*.tar.gz to kimi-code-linux-x64	❌ half-migrated

User-visible impact

1. Search doesn't find it: searching "Kimi Code" in the Zed extension marketplace returns nothing (only "Kimi CLI" exists)
2. ACP config may break: new users follow the README banner to install Kimi Code (MoonshotAI/kimi-code), then try to configure ACP using the main README example (kimi acp) — whether that command/path is correct for the new install location is unclear
3. Trust erosion: combined with the anxiety expressed in 为什么抛弃kimi-cli重做kimi code?老的没做好还要分裂社区？ || Why abandon kimi-cli and redo kimi code? The old one didn't do a good job and still divides the community? #2381 about "split / abandoned", four coexisting names is actively confirming the community's worst fear

Questions that need an official answer

1. Fate of kimi-cli: README says "gradually wound down" but commits continue. Which repo is the current product? Wind-down timeline?
2. Binary path migration: user installations now live at ~/.kimi-code/bin/kimi (new) vs ~/.kimi/ (old). Do config files (mcp.json, sessions/) auto-migrate? The README IMPORTANT mentions "Installing Kimi Code CLI automatically migrates your configuration and sessions", but ~/.kimi/ and ~/.kimi-code/ look like independent directories — is the migration reliable?
3. PyPI dual-package confusion: kimi-cli and kimi-code coexist on PyPI, with kimi-code depending on kimi-cli, and the PyPI version lags behind the install.sh version (feat: implement retryable chat provider interface and recovery mechanism #1219). What is the official install path? Should pip install kimi-code be deprecated?
4. ACP config compatibility: if the agent_servers key changes from "Kimi CLI" to "Kimi Code", how do existing user settings.json files remain compatible?
5. Zed extension id migration: if extension.toml id="kimi-cli" is renamed, Zed will treat old and new ids as two different extensions — how do already-installed users migrate smoothly?

Proposal

1. Publish an official "Kimi CLI → Kimi Code migration matrix" clarifying: repo, command, extension id, package name, config key — and the migration path for each
2. Fix the remaining surfaces as sub-tasks (suggested as a tracking checklist):

• kimi-cli README: title, body, ACP config example
• kimi-code-zed-extension: extension.toml (mind the id-change compatibility) and README
• zsh-kimi-cli: repo description and README
• kimi-agent-sdk / kimi-agent-rs: align descriptions
• pykaos: topics
• docs site (moonshotai.github.io/kimi-cli): title, URL path
• Final decision on PyPI package name / binary name and migration path

Willing to help

I'm willing to submit PRs for the documentation/metadata surfaces listed above (README fixes, extension.toml metadata, repo description text). I'll wait for official guidance on the direction first, then start with the smallest/safest one (e.g. kimi-cli README title + ACP config example).

Related: #2381, #2376.

[counterfactual5]

After reviewing PR #2431 (merged on 2026-06-05), I now understand the official product strategy:

• kimi-cli (Python) will remain as "Kimi CLI"
• kimi-code (TypeScript rewrite) will be "Kimi Code CLI"
• These are two distinct, parallel products with clear separation

The inconsistency table in this issue was based on an incorrect assumption that a full "Kimi CLI → Kimi Code" rebrand was intended. Since the official strategy is parallel products (not rebrand), most of the listed inconsistencies are actually correct implementations of that strategy.

I'm closing this issue because the core premise ("brand migration is half-done") is incorrect. The one genuine inconsistency remains in the kimi-code-zed-extension repository, where the extension naming doesn't clearly align with either product identity. I'll submit a separate, more focused issue about that specific confusion.

Thanks to @RealKai42 for the clarification in #2431.