What version of Kimi Code is running?
Kimi Work desktop for Windows (win32-x64): app 3.1.5 (Kimi-Setup-3.1.5.exe), daimon bundle 0.5.49, vendored kimi-code runtime 0.15.3 @ f17a6ecb. Regression window: app 3.1.3 → 3.1.4 (installed 2026-07-23 16:02–16:04 EDT, i.e., 20:02–20:04Z; main.log timestamps are local time).
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?
Selecting Swarm mode in the Kimi Work UI used to reach the runtime as an instruction; since app 3.1.4 it no longer does, while the session still runs — and presumably bills — on the swarm model tier.
Before (app 3.1.3, Jul 23 10:40–13:30Z, observed in session wire logs): with Swarm selected, the conversation carried swarm_mode.enter / swarm_mode.exit wire events wrapping each turn, and each swarm turn's prompt was preceded by the enter-reminder from packages/agent-core/src/agent/swarm/enter-reminder.md:
You are now in "agent swarm" mode. The user may send tasks that require a large number of parallel subagents. …
All llm.request events used model k3-agent-swarm, and the session dispatched 10 parallel subagents. This matches the behavior described on the Agent Swarm help page (archived): "Deploy up to 300 Subagent instances simultaneously… automatically coordinate large-scale AI Subagent collaboration."
After (app 3.1.4/3.1.5, sessions of Jul 24 and Jul 25): with the same Swarm mode selected in the UI —
- the Electron client still records
agent_mode: "agent-swarm" for every message in its telemetry (kimi_work_send_message events in %APPDATA%\kimi-desktop\logs\main.log);
- every
llm.request still uses model k3-agent-swarm;
- the
AgentSwarm and Agent tools are still registered and active in tools.set_active_tools;
- but there are zero
swarm_mode.enter/exit events and zero injections of the enter-reminder across entire sessions (checked line-by-line in wire.jsonl for two full multi-turn sessions).
The runtime is never told the user chose swarm mode. Combined with the new default-deny prompt rule (companion issue: #2197), the observable result is that swarm-tier sessions run inline unless the user spells out "use subagents" in the task text.
What steps can reproduce the bug?
- Kimi Work desktop ≥ app 3.1.4 on Windows, membership tier with Agent Swarm access, Swarm mode selected in the UI.
- Run a multi-turn session; then open the session's
agents/main/wire.jsonl (location per the Agents docs, "Storage Location in the Session Directory").
grep for swarm_mode and for "You are now in" → 0 hits. grep the same file for "model" → k3-agent-swarm on every request.
- Compare with any pre-3.1.4 swarm session's
wire.jsonl (if retained): swarm_mode.enter events and the enter-reminder text are present there.
What is the expected behavior?
Either (a) the mode selection propagates to the runtime as before (swarm_mode.enter + reminder), or (b) if swarm entry is now intentionally deferred/queued (e.g., for capacity reasons), the UI should say so instead of silently accepting the selection — and the change should appear in release notes. Users on swarm-eligible paid tiers currently get single-agent behavior by default from a session that runs on the swarm model.
Additional information
Impact
-
Behavior/billing mismatch: sessions are served by k3-agent-swarm while the mechanism that produces swarm behavior is disconnected.
-
Silent regression: no error, no UI change, no changelog — only wire-log archaeology reveals it. The desktop bundle has no public changelog at all.
-
Support burden: the agent itself, asked why it didn't swarm, cannot see that the mode was selected ("nothing in my runtime context told me swarm behavior was expected" — which the wire logs confirm is literally true post-3.1.4).
Notes
What version of Kimi Code is running?
Kimi Work desktop for Windows (win32-x64): app 3.1.5 (
Kimi-Setup-3.1.5.exe), daimon bundle 0.5.49, vendored kimi-code runtime 0.15.3 @f17a6ecb. Regression window: app 3.1.3 → 3.1.4 (installed 2026-07-23 16:02–16:04 EDT, i.e., 20:02–20:04Z;main.logtimestamps are local time).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?
Selecting Swarm mode in the Kimi Work UI used to reach the runtime as an instruction; since app 3.1.4 it no longer does, while the session still runs — and presumably bills — on the swarm model tier.
Before (app 3.1.3, Jul 23 10:40–13:30Z, observed in session wire logs): with Swarm selected, the conversation carried
swarm_mode.enter/swarm_mode.exitwire events wrapping each turn, and each swarm turn's prompt was preceded by the enter-reminder frompackages/agent-core/src/agent/swarm/enter-reminder.md:All
llm.requestevents used modelk3-agent-swarm, and the session dispatched 10 parallel subagents. This matches the behavior described on the Agent Swarm help page (archived): "Deploy up to 300 Subagent instances simultaneously… automatically coordinate large-scale AI Subagent collaboration."After (app 3.1.4/3.1.5, sessions of Jul 24 and Jul 25): with the same Swarm mode selected in the UI —
agent_mode: "agent-swarm"for every message in its telemetry (kimi_work_send_messageevents in%APPDATA%\kimi-desktop\logs\main.log);llm.requeststill uses modelk3-agent-swarm;AgentSwarmandAgenttools are still registered and active intools.set_active_tools;swarm_mode.enter/exitevents and zero injections of the enter-reminder across entire sessions (checked line-by-line inwire.jsonlfor two full multi-turn sessions).The runtime is never told the user chose swarm mode. Combined with the new default-deny prompt rule (companion issue: #2197), the observable result is that swarm-tier sessions run inline unless the user spells out "use subagents" in the task text.
What steps can reproduce the bug?
agents/main/wire.jsonl(location per the Agents docs, "Storage Location in the Session Directory").grepforswarm_modeand for "You are now in" → 0 hits.grepthe same file for"model"→k3-agent-swarmon every request.wire.jsonl(if retained):swarm_mode.enterevents and the enter-reminder text are present there.What is the expected behavior?
Either (a) the mode selection propagates to the runtime as before (
swarm_mode.enter+ reminder), or (b) if swarm entry is now intentionally deferred/queued (e.g., for capacity reasons), the UI should say so instead of silently accepting the selection — and the change should appear in release notes. Users on swarm-eligible paid tiers currently get single-agent behavior by default from a session that runs on the swarm model.Additional information
Impact
Behavior/billing mismatch: sessions are served by
k3-agent-swarmwhile the mechanism that produces swarm behavior is disconnected.Silent regression: no error, no UI change, no changelog — only wire-log archaeology reveals it. The desktop bundle has no public changelog at all.
Support burden: the agent itself, asked why it didn't swarm, cannot see that the mode was selected ("nothing in my runtime context told me swarm behavior was expected" — which the wire logs confirm is literally true post-3.1.4).
Notes
Timeline context: this landed the same day (Jul 23) as the new prompt-level Agent-tool restriction (
[Bug] Kimi Work desktop ships a system-prompt rule disabling the Agent tool by default (daimon 0.5.47+) — contradicts documented behavior, no changelog entry#2197) and four days after the Jul 19 pause of new subscriptions for capacity reasons; if both are deliberate load-shedding, documenting them would let users make informed use of their credits.Related (not duplicates): Feature request: configurable default swarm mode #720 (configurable default swarm mode), Swarm无法查看进度 #1957 (swarm progress visibility).
Wire/log excerpts above are redacted per the docs' guidance on wire files; fuller redacted excerpts (timestamps, event sequences) available on request.