loading
loading
Moonshot's Kimi Code Stops Spawning Parallel AI Agents Without Permission Moonshot flipped the default so Kimi Code tackles work solo, with multi-agent swarms now strictly opt-in across CLI and Desktop. - Kimi Code CLI 2.3.2 and Desktop v1.1.3 make subagent delegation opt-in on K3.1 Pro. - The agent handles tasks solo by default instead of proactively launching subagents. - Swarm mode only runs when explicitly enabled by the user. - AgentSwarm can no longer self-trigger, removing swarms from kimi -p and ACP clients like Zed. - Delegation can still be requested via prompt, AGENTS.md, a skill, or multi-agent mode. - Built-in coder, explore, and plan sub-agents remain available on demand. Moonshot has changed the default orchestration behavior of Kimi Code on its K3.1 Pro model. Kimi Code CLI 2.3.2 and Desktop 1.1.3 now handle tasks with a single agent unless the user explicitly requests delegation or enables a multi-agent mode. Delegation now requires a trigger Earlier versions could create subagents or start swarm mode whenever the orchestrator judged a task suitable for parallel work. The new releases require one of four triggers: - A prompt instruction: Ask the agent to delegate work. - An AGENTS.md rule: Define delegation behavior in the repository’s agent instructions. - A skill: Invoke a skill configured to use subagents. - A multi-agent mode: Enable swarm mode directly. A subagent is a delegated worker assigned part of a task. Swarm mode coordinates multiple such workers in parallel, then combines their output through an orchestrator. Headless runs lose automatic swarms Desktop 1.1.3 follows the same single-agent default and starts a swarm only after the user enables it. The agent can no longer launch AgentSwarm on its own. That restriction makes swarms unavailable in headless kimi -p runs and Agent Client Protocol clients such as Zed. Those interfaces lack an interactive control for enabling swarm mode, while automatic activation has been removed. Why Moonshot pulled back Moonshot has promoted parallel orchestration as a central Kimi Code capability. K3.1 Pro, the first model in the K3.1 series, has a 1-million-token context window for processing large codebases and document collections. Earlier K2.6 and K2.7 Code releases supported as many as 300 parallel subagents, with an orchestrator trained to divide work automatically. Automatic fan-out also turned a single prompt into many concurrent model calls. That behavior could increase token consumption, exhaust quotas, complicate failure recovery, and make a run harder to reproduce. Requiring explicit activation gives developers control over when those costs and operational risks are appropriate. What developers need to change - Existing prompts: Add an explicit delegation request when parallel execution is required. - Repository configuration: Record recurring delegation rules in AGENTS.md. - CLI workflows: Use /swarm <task> for work that benefits from coordinated parallel agents. - Desktop workflows: Enable swarm mode before starting the task. - Automated integrations: Expect kimi -p and ACP clients to remain single-agent under the current controls. The CLI still includes the built-in coder, explore, and plan subagents. Its default delegation allowlist limits which agents may create additional workers, reducing recursive spawning unless the user opts in. Where swarms still fit Parallel agents remain useful when work separates cleanly into independent units, including large codebase audits, multi-module refactors, broad test generation, and research across many sources. In those cases, explicit swarm activation lets the orchestrator distribute tasks and merge the results. Routine coding tasks now stay within one agent, producing more predictable token use and a simpler execution trail. Moonshot’s change places orchestration policy under developer control while preserving multi-agent capacity for workloads designed to use it.
document fetched 2026-10-26 02:56