What version of Kimi Code is running?
Kimi Work desktop for Windows (win32-x64): app 3.1.5 (NSIS, Kimi-Setup-3.1.5.exe), daimon bundle 0.5.49 (release manifest createdAt 2026-07-24T10:43:06Z), vendored kimi-code runtime 0.15.3 @ f17a6ecb. First affected version observed: daimon 0.5.47, shipped with app 3.1.4.
Which open platform/subscription were you using?
Vivace (upgraded from Moderato on 2026-07-23, ~1:13 AM EDT). All behavior in this report — including the pre-update swarm session later that morning and everything after the 0.5.47 install that afternoon — occurred on Vivace.
Which model were you using?
k3-agent-swarm
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Since daimon bundle 0.5.47, the Kimi Work desktop runtime's shipped system prompt contains a constraint that flips the documented default for sub-agent use:
# Constraints
- You MUST NOT use the Agent tool (subagent/sub-agent) under any circumstances unless the user explicitly requests it.
Shipped at:
%APPDATA%\kimi-desktop\daimon-bundle\app\daimon\dist\src\core\runtime\system-prompt\prompts\_common\constraints.md
and confirmed present in the actual system prompt sent to the model (session wire.jsonl, config.update for the daimon profile).
This directly contradicts the current documentation (Agents and Sub-Agents, archived 2026-07-26; same text in the repo at docs/en/customization/agents.md@f17a6ecb, L17/L36):
"Sub-agents are scheduled automatically by the main Agent — based on task complexity, context consumption, and sub-task independence, they are dispatched at the right moment without the user having to specify one."
"The Agent tool itself is allowed by default, enabling the main Agent to delegate multiple times without interrupting the user."
No release notes or changelog documents this change. The kimi-code changelog for the same window (0.25.0→0.29.1, Jul 16–24) describes subagent expansion, and there is no public changelog for the desktop bundle at all.
Timeline from local artifacts on one machine:
| Date |
Bundle |
Evidence |
| Jul 19–23 |
0.5.45, 0.5.46 |
Session wire logs: # Constraints block present in system prompt without the Agent-tool rule (all config.update snapshots checked across four sessions, incl. one that ran a 9-worker AgentSwarm review — 10 subagent instances total with a follow-up worker — on Jul 23 10:40–13:30Z) |
| Jul 23 16:03:57 EDT (20:03:57Z) |
0.5.47 installed (with app 3.1.4) |
main.log DaimonExtract/DaimonProvision entries (log timestamps are local time) |
| Jul 24 01:53:22Z |
0.5.47 |
First captured session after the update: rule present in the daimon-profile system prompt from the first request |
| Jul 24 13:46 EDT (17:46:38Z) |
0.5.49 installed |
Rule persists; current constraints.md first bullet (SHA-256 a61a65e7…9e3e1c) |
The old constraints block and the new one are otherwise identical — the diff is exactly this one added bullet.
What steps can reproduce the bug?
- Kimi Work desktop on Windows with daimon bundle ≥ 0.5.47.
- Open the file at the path above — the first bullet is the rule.
- Start a new conversation (any mode, including Agent Swarm selected) and give a large, naturally parallelizable research task without using words like "subagents"/"swarm".
- Observe the task runs inline, with no Agent tool calls. Confirm the rule reached the model: per the docs' own description of session storage, open the session's
agents/main/wire.jsonl and inspect the config.update event (profileName: "daimon") — its systemPrompt contains the rule. The Agent and AgentSwarm tools are still registered in tools.set_active_tools — only the prompt forbids their use.
Asking the identical task with an explicit "use subagents" produces delegation — consistent with the rule, and confirming the tools themselves still work.
Session ID 586109a7-94b0-4e32-b3d3-717ee47ab8f4
What is the expected behavior?
Either the documented behavior (Agent tool allowed by default, automatic dispatch), or documentation/changelog reflecting the new default and, ideally, a user-visible setting. If this is a temporary capacity mitigation (it landed four days after the Jul 19 subscription pause), saying so in release notes would have avoided this report.
Additional information
Impact:
- Paid Agent Swarm–tier sessions behave as single-agent by default (see companion issue about swarm-mode propagation — filed separately: the two changes shipped the same day but are mechanically independent).
- Users diagnosing "why didn't it parallelize" cannot discover the cause without extracting the app bundle; the agent itself, when asked, cannot date or explain the rule.
- Docs and shipped behavior now disagree, which undermines the docs as a reference.
Notes:
What version of Kimi Code is running?
Kimi Work desktop for Windows (win32-x64): app 3.1.5 (NSIS,
Kimi-Setup-3.1.5.exe), daimon bundle 0.5.49 (release manifestcreatedAt 2026-07-24T10:43:06Z), vendored kimi-code runtime 0.15.3 @f17a6ecb. First affected version observed: daimon 0.5.47, shipped with app 3.1.4.Which open platform/subscription were you using?
Vivace (upgraded from Moderato on 2026-07-23, ~1:13 AM EDT). All behavior in this report — including the pre-update swarm session later that morning and everything after the 0.5.47 install that afternoon — occurred on Vivace.
Which model were you using?
k3-agent-swarm
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Since daimon bundle 0.5.47, the Kimi Work desktop runtime's shipped system prompt contains a constraint that flips the documented default for sub-agent use:
Shipped at:
and confirmed present in the actual system prompt sent to the model (session
wire.jsonl,config.updatefor thedaimonprofile).This directly contradicts the current documentation (Agents and Sub-Agents, archived 2026-07-26; same text in the repo at docs/en/customization/agents.md@f17a6ecb, L17/L36):
No release notes or changelog documents this change. The kimi-code changelog for the same window (0.25.0→0.29.1, Jul 16–24) describes subagent expansion, and there is no public changelog for the desktop bundle at all.
Timeline from local artifacts on one machine:
# Constraintsblock present in system prompt without the Agent-tool rule (allconfig.updatesnapshots checked across four sessions, incl. one that ran a 9-worker AgentSwarm review — 10 subagent instances total with a follow-up worker — on Jul 23 10:40–13:30Z)main.logDaimonExtract/DaimonProvisionentries (log timestamps are local time)daimon-profile system prompt from the first requestconstraints.mdfirst bullet (SHA-256a61a65e7…9e3e1c)The old constraints block and the new one are otherwise identical — the diff is exactly this one added bullet.
What steps can reproduce the bug?
agents/main/wire.jsonland inspect theconfig.updateevent (profileName: "daimon") — itssystemPromptcontains the rule. TheAgentandAgentSwarmtools are still registered intools.set_active_tools— only the prompt forbids their use.Asking the identical task with an explicit "use subagents" produces delegation — consistent with the rule, and confirming the tools themselves still work.
Session ID 586109a7-94b0-4e32-b3d3-717ee47ab8f4
What is the expected behavior?
Either the documented behavior (Agent tool allowed by default, automatic dispatch), or documentation/changelog reflecting the new default and, ideally, a user-visible setting. If this is a temporary capacity mitigation (it landed four days after the Jul 19 subscription pause), saying so in release notes would have avoided this report.
Additional information
Impact:
Notes: