Kimi Code repeats the same layout - an orchestrator and subagents - but in its own CLI shell rather than on top of someone else's host. Environment settings live in ~/.kimi/config.toml, agent instructions separately in AGENTS.md, and the built-in subagents are named directly for their roles: explore reads the code, plan handles architecture, coder does the implementation. Each of them works in a context isolated from the others, and only its summary, not the full chain of reasoning, comes back up into main. The product repositories to check for details of a specific build are kimi-cli and kimi-code.

What sets this environment apart from the rest is the stated Agent Swarm: a mode in which several subagents are spun up at once for a large task, working in parallel rather than one after another as in most other environments. This is not a replacement for the explore - plan - coder pipeline but an extension of it, for cases where a task can and should be parallelized rather than run strictly in sequence.

Behind the environment stands the company's own model, and here it is worth stepping for a moment from settings to architecture: Kimi K2 is an MoE-type model with a trillion parameters in total and thirty-two billion active per token, with 384 experts and training through the Muon optimizer. This is already the level of facts from the model card rather than from user settings, and it is useful chiefly for understanding why the environment behaves the way it does on long and varied tasks.

The official resources in this section cover both sides of the question: the CLI repository on GitHub and the kimi.com/code product page speak to the shell itself and its commands, the subagents docs speak to how to tune the explore, plan and coder roles for a specific project, and the Kimi K2 card speaks to the model and architecture that drives all of it.

The meta-prompt asks the agent to first read the Kimi Code CLI documentation, then check exactly which build is in use - kimi-cli or kimi-code, since the config paths can differ - and only then configure ~/.kimi/config.toml together with AGENTS.md: pinning down the orchestrator role, the delegation rules and the requirement to return a summary rather than a full dump.

From there the pipeline itself runs - explore, then plan, then coder, each in an isolated context - while on large tasks Agent Swarm switches on in place of a sequential pass, with subagents running in parallel; and, as everywhere in this reference, the plan is shown before changes are made.