Kimi Code CLI
Subagents in disposable contexts
Prerequisites
- Agentic Coding Basics
What You'll Learn
- Explain subagent dispatch and context isolation
- Compare Kimi Code subagents with Claude Code tasks
- Know where Kimi K3 fits in the loop
Kimi Code at a Glance
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bashFacts verified against the Kimi Code repository as of August 2026. The CLI itself is MIT-licensed and installs as a single binary; hosted Kimi models require a Moonshot account or API key.
Subagents, Precisely
Kimi Code CLI ships three built-in subagents — coder, explore, and plan — each dispatched into an isolated context so the main session never inherits their reading.
The main session writes a task brief — the goal, the constraints, what the answer should look like. That brief is the only thing that crosses the boundary.
The subagent works in its own fresh context. Every file it reads, every command it runs, every dead end it hits accumulates there — and nowhere else.
When the subagent finishes, its entire working context is discarded. The 300k tokens of reading it did are gone — you never carry them.
Only the summary enters the main context: a conclusion, a diff, a plan. The main session stays slim enough to keep orchestrating for hours.
This is the same economics The Duel teaches in 90 seconds: one orchestrator keeps a slim context while workers absorb the token burn in contexts that get thrown away. Kimi Code builds that pattern into the harness as three named roles.
Kimi Code vs Claude Code: Two Takes on Dispatch
Both harnesses land on the same core design — the main session orchestrates, subagents absorb the reading, only summaries return. They differ in how the roles are defined.
| Kimi Code CLI | Claude Code | |
|---|---|---|
| Subagent roles | Three built in — coder, explore, plan — fixed roles, ready out of the box (as of August 2026) | One general Task mechanism, plus custom agents you define yourself with their own prompts and tool sets |
| Context isolation | Each subagent runs in an isolated context; the main session never inherits its reading | Same model — a Task runs in its own context and reports back a summary |
| What returns | A summary; the working context is discarded | A final report; the Task's context is discarded |
| Trade-off | Zero setup, less flexibility — the three roles cover most work but are what they are | More setup, more shape — you can encode team-specific roles, at the cost of writing them |
For a deeper look at how Claude Code's version works, see the subagents guide.
When to Dispatch vs Do It In-Session
✓ Dispatch a subagent
- •Broad codebase surveys — you need the conclusion, not the file dumps
- •Questions that mean reading many files to answer one thing
- •Self-contained fix loops — run tests, patch, repeat until green
- •Drafting a plan before committing the main session to an approach
- •Anything whose intermediate reading you will never need again
✗ Stay in-session
- •You will edit the file you are about to read — the detail is the point
- •Small, single-file questions — dispatch overhead exceeds the savings
- •Tight interactive back-and-forth where you steer every step
- •Work where a summary would lose information you need verbatim
The heuristic: dispatch when the reading is disposable, stay when the reading is the work. Even a 1M tokens window fills — the question is never whether you have room, it is whether you want to keep paying for what fills it.
💡 Pro Tips
- 1.Let reads run. The gate only interrupts on writes and shell commands — save your attention for reviewing diffs, not approving file reads.
- 2.Chain explore into coder: survey with an explore subagent first, then hand its summary to coder as a tight brief. Two slim dispatches beat one bloated session.
- 3.Treat the summary as a contract. Say what the return should contain — file paths, a decision, a diff — because everything else the subagent learned is discarded.
- 4.Set up MCP servers by describing them in
/mcp-configinstead of hunting for a config file, and use the Agent Client Protocol to drive the same agent from your IDE. - 5.Do not let the 1M tokens window make you lazy. Headroom is for the orchestrator's long sessions — disposable reading still belongs in a subagent.
The walkthrough, as text
-
1. The Confirmation Gate
Kimi Code splits every tool call into two lanes. Write operations and shell commands are confirmation-gated; read-only operations run automatically. You review the diff or the command before anything touches your machine.
-
2. The Main-Session Problem
Everything a session reads stays in its context for the rest of the session. Ten files explored to answer one question keep costing tokens on every later turn — context only grows.
-
3. Subagent Dispatch
Kimi Code CLI ships three built-in subagents — coder, explore, and plan — each dispatched into an isolated context so the main session never inherits their reading. You hand each one a task brief; it starts from a clean slate.
-
4. Isolation Pays
The subagent's context balloons as it reads — and none of it lands in yours. When it finishes, its whole working context is thrown away and only a short summary returns to the main session.
-
5. Kimi K3, the Engine
Its flagship model as of August 2026 is Kimi K3, with a 1M-token context window. A huge window buys headroom, not immunity — isolation is still what keeps the main session cheap.
-
6. Config Without Friction
MCP servers are configured conversationally through /mcp-config — no JSON editing — and IDE integration uses the Agent Client Protocol. The CLI itself is MIT-licensed and installs as a single binary; hosted Kimi models require a Moonshot account or API key.
Facts verified against the Kimi Code CLI repository and official docs, as of August 2026.
New lessons, straight to your inbox
5 more harness deep dives are on the roadmap. Subscribers read them first — free.
Check your inbox to confirm.